Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option an d RADIUS Attributes sub-option

From: "Kuntal Chowdhury" <[email-masked]>
Date: Fri, 29 Oct 2004 16:54:01 -0400

The intent in your draft i.e. configure MN with HA/HoA/HL information can be
achieved with:

http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-mip6-agentop-00.txt

Unlike your draft this draft:

1. Does not require the DHCP server to parse vendor-specific RADIUS
attributes.
2. Has no interdomain (ASP-MSP) tight coupling assumption.
3. Provides integrity and authenticity of the information that is exchanged.
4. It is AAA protocol agnostic, i.e. works for both RADIUS and DIAMETER.
5. Does not assume a 3GPP2 centric architecture. It is generic.

Regards,
Kuntal

>-----Original Message-----
>From: Wing Cheong Lau [mailto:[email-masked]] 
>Sent: Friday, October 29, 2004 2:44 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Wing Cheong Lau
>Cc: [email-masked]
>Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information 
>Option and RADIUS Attributes sub-option
>
>
>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:[email-masked]]
>>Sent: Friday, October 29, 2004 1:38 PM
>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>>Cc: [email-masked]
>>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
>
>
>

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Wing Cheong Lau <[email-masked]>
Date: Fri, 29 Oct 2004 15:06:05 -0700

Kuntal,

>http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-mip6-agentop-00.txt

Thanks for bringing to our attention the existence of this new draft. 
Somehow, I have not seen
its announcement before, at least not in the dhc or mip6 mailing list.

>1. Does not require the DHCP server to parse vendor-specific RADIUS

But it requires the DHCP relay-agent to parse and understand the newly 
defined, yet-to-be standardized RADIUS Attributes carrying 
HA/HoA/Home-link-prefix as described in
draft-chowdhury-mip6-bootstrap-radius-00.txt and similar yet-to-be
defined attributes if DIAMETER is used.

>Kuntal

I just did a quick pass thru it but did not find any description addressing 
the issue where
the NAS/DHCP relay-agent and the AAA belongs to a different domain and 
RADIUS is used as
the AAA protocol. (This is precisely the same issue you raised for the 
DHCPv6 Relay Information Option/RADIUS Attributes sub-option draft.). So, 
would you point to the specific text in the draft which substantiates your 
claims 2) and 4) simultaneously ?

Currently, the draft just conveniently states:
"The AAA procedures using RADIUS is defined in [MIP6-RADIUS]", but

    [MIP6-RADIUS]
               Chowdhury et. al., K., "RADIUS Attributes for Mobile IPv6
               bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01
               (work in progress), July 2004.

cannot be found in public (I meant -01 version cannot be found, only -00 is 
available).
On the other hand, I cannot see how the cross-domain scenario described 
in  -00 version of  draft-chowdhury-mip6-bootstrap-radius the draftis 
different than the one in draft-droms-dhc-v6-relayopt-00.txt.

Am I missing something here ?

I would also like to point out that the DHCPv6 Relay Info Option/ RADIUS 
Attribute sub-option actually addresses 2 level of  needs:

1. The ability of DHCPv6 Relay agent to tag along additional "info" as it 
forwards requests from the DHCP client to the DHCP server, regardless of 
the specific nature of the "info". This is a "general"
capability for the DHCPv6 Relay agent which is absent from the RFC 3315. It 
seems like both your
and our draft needs such capability. The main difference is that, in 
draft-chowdhury-dhc-mip6-agentop-00.txt, newly defined MIP6-bootstrapping 
options are relayed while in draft-droms-dhc-v6-relayopt-00.txt, the info 
got relayed are RADIUS attributes.

2. As for the relay-agent RADIUS option, it is a feature of its own right, 
the example given in our draft is just one of its use which can help 
address an immediate issue in 3GPP2 835D.

3. As stated in draft-droms-dhc-v6-relayopt-00.txt,
" This document uses 3GPP2 access authentication as an example to
    motivate the use of the Relay Agent Information option and the RADIUS
    Attributes sub-option by a NAS. The Relay Agent Information option is
    not limited to use in conjunction with RADIUS sub-option when other
    sub-options are defined in the future. The RADIUS Attributes sub-
    option for the Relay Agent Information option described in this
    document is not limited to use in conjunction with 3GPP2 and can be
    used to carry RADIUS attributes obtained by the relay agent for any
    reason.  That is, the sub-option is not limited to use with 3GPP2,
    but is constrained by RADIUS semantics."

Regards,

Wing