Dear Kuntal,

Thank you for your comments. My response is interlaced below:

At 12:04 PM 10/29/2004, Kuntal Chowdhury wrote:
>I don't see the need for the following in the draft:
>
>1. Reference to 3GPP2: because 3GPP2 does not use the scheme that you are
>proposing here.

I disagree. At a minimum, the proposed option will benefit  3GPP2  in the 
case where the RADIUS and DHCP service are all under the same domain.
In particular, the current way (835D) 3GPP2 uses RADIUS/DHCPv6.
for doing MIP6 bootstrapping requires the PDSN to act as a DHCPv6 server 
(to answer stateless
request for HA/HoA/HL info). On the other hand, there are also additional 
needs in 3GPP2 where the PDSN has to act as a relay-agent instead. Such 
dual role of PDSN is unnecessary and not desirable
because it forces the Mobile to issue multiple separate requests for 
different set of parameters, to be answered by different DHCP servers.

With the proposed option, the PDSN only needs to be serve as a relay-agent, 
and the mobile do not
need to issue separate requests the different parameters it requests.

>2. Vendor specific attribute parsing requirement on the DHCP server: It does
>not scale.
I do not see your point. It option is used as a "hint", if the DHCP server 
does not understand a specific
vendor attribute, it can just ignore it while making it's assignment. 
What's the scalability issue here ?

>3. The requirement of other parameter (non IP address) assignment by the
>DHCP server: because the examples you give viz. HA, HoA, Home Link prefix
>etc. are not something that the local domain (ASP) control as per MIP6.
>These are controlled by the Home/Serving MSP.

Sorry, I do not get your point. If the proposed option is deemed to be 
useful for a cross-domain
RADIUS envirnoment, then, the HA/HoA/Home-link prefix, will be coming from 
the Home MSP,
via  RADIUS 3GPP VSA's, while the DHCPv6 relay-agent (PDSN) and the 
corresponding DHCPv6 server is under the control of the local domain ASP. 
This does not contradict your statement above.

I do agree that it is valid to debate whether one should allow the Home MSP 
to push HA/HoA/HL info to its own DHCPv6 server. But regardless of the 
answer to this question, as I explain above, the proposed option do have 
value for the single-domain case where the RADIUS service and the DHCP
servers/relay-agents are belonging to the same domain.

Regards,

Wing

>-Kuntal
>
>
>-----Original Message-----
>From: Wing Cheong Lau [mailto:lau <at> qualcomm.com]
>Sent: Friday, October 29, 2004 1:38 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>Cc: dhcwg <at> ietf.org
>Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and
>RADIUS Attributes sub-option
>
>
>At 09:43 AM 10/29/2004, you wrote:
>
>A few questions on this draft:
>
>1. The primary motivation seems to be 3GPP2's network, but fact of the
>matter is, 3GPP2 NAS (PDSN) does not push information received from a
>different domain into the DHCP server in the local domain.
>
>Yes. That is the status quo. But the intent of the internet draft is to keep
>
>the possibility of such protocol support for roaming mobile scenario in the
>future.
>Of course, as clearly stated in the current draft regarding it's
>applicability and
>security implication need to be considered. In particular:
>
>"The scope of applicability of this specification is such that the NAS
>    (which acts as a DHCP relay agent), any other participating DHCP
>    relay agent, the DHCP server and DHCP client should be within the
>    same administrative domain while the RADIUS service involved may span
>    multiple administrative domains. See the Section 5 for details of
>    security considerations when this specification is deployed with
>    RADIUS service operating across multiple administrative domains.
>    Global interoperability of this specification, across arbitrary
>    administrative domains, is not supported. "
>
>and
>
>"The RADIUS protocol [6] was designed for intra-domain use, where the
>    NAS, proxy, and home server exist within a single administrative
>    domain, and proxies may be considered a trusted component. However,
>    under roaming situation, the NAS, proxies, and home server will
>    typically be managed by different administrative entities. As a
>    result, inter-domain RADIUS operations are inherently required for
>    roaming applications, and proxies cannot necessarily be trusted.
>    Refer to Section 7 of RFC 2609 for a detailed security threat
>    analysis, limitations and precautions of operating RADIUS in a inter-
>    domain environment. In general, robust and secure operations of
>    RADIUS across multiple administrative domains require pre-established
>    agreement, mutual trust, and secure communications channel amongst
>    all the participating domains."
>
>Inter-domain RADIUS operations have its well-known
>set of risks and limitations and any future applications of the proposed
>options
>in an cross-domain environment would be subjected to such considerations.
>
>
>
>
>2. The draft allows vendor specific RADIUS attributes to be pushed to the
>DHCP server potentially from different domains. How does the DHCP sever
>parse these vendor specific RADIUS attributes? Is it the assumption that the
>DHCP server needs to know possibly all vendor specific RADIUS attributes?
>This does not scale.
>
>In general, as specified in the draft, the DHCP server "MAY" use the
>information carried in the proposed option as a HINT to make the subsequent
>assignment. If  the DHCP server does not
>understand a particular vendor-specific option/VSA, it is free to ignore it
>when making its
>assignment. On the other hand, given a specific deployment environment, it
>is not unreasonable to
>assume the DHCP server would understand a particular set of vendor-specific,
>e.g. 3GPP2, RADIUS VSA's. After all, as stated in the applicability
>statement above, we are not talking about cross-domain RADIUS services over
>any arbitrary domain, but only over those which have some sort of
>pre-established roaming agreements.
>
>
>
>3. It says that the DHCP server uses this RADIUS info to do IP address
>allocation and other parameter allocation. It would be nice to know what
>other parameters the authors have in mind.
>
>Regards,
>Kuntal
>
>Parameters under considerations included Home Agent address, (for dynamic HA
>assignment),
>Home Address (HoA) and/or Home-link prefix, etc.
>
>In fact, my understanding is that, for a single
>domain environment, RADIUS 3GPP2 VSA's have already been defined for these
>set of
>parameters to enable MIP6 bootstrapping  via RADIUS/DHCPv6 within a single
>domain.
>
>If the risks/limitations of cross-domain RADIUS service stated above  are
>deemed to be acceptable,
>there is a possibility that such bootstrapping scheme can be extended across
>providers with
>pre-established roaming agreements.
>
>Regards,
>
>Wing