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

From: "Kuntal Chowdhury" <[email-masked]>
Date: Fri, 29 Oct 2004 15:04:24 -0400

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.

2. Vendor specific attribute parsing requirement on the DHCP server: It does
not scale.

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.

-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 12:44:17 -0700

Dear Kuntal,

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

>1. Reference to 3GPP2: because 3GPP2 does not use the scheme that you are

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
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 ?

>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