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 12:43:48 -0400

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.

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.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wing Cheong Lau
Sent: Monday, October 25, 2004 1:59 PM
To: Bernie Volz; 'Wing Cheong Lau'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and
RADIUS Attributes sub-option

At 10:11 AM 10/25/2004, Bernie Volz wrote:

BTW, we don't need a DHCPv6 version of
draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor
options can be used by the Relay Agent just fine. Again, it is WHERE these
options appear that indicates whether they are for the client (in the client
part of the message) or the relay, in the Relay-Forw or Relay-Reply part of
the message. That work is already done and is not needed!!
 
- Bernie

I see. However,  the use of such vendor-options by the Relay Agent is kind
of hidden/missing from the current text of RFC 3315.
For example, Sections  22.16 and 22.17 of RFC 3315 only describe the use of
such vendor options by the client and the server. The use of these options
by the relay agent are not mentioned at all. 

While it is true that the table in Appendix A of RFC3315
does say the possible inclusion of the vendor options in the
Relay-Forward/Relay-Reply message,  
the table in Appendix B seems to imply otherwise: 

In the table in Appendix B,  while there are  "*"'s  for the  Relay-Message
and Interface ID rows under
the Relay Forw./Relay Replay columns,  no "*"'s are found  for the Vendor
Class/Vendor Info rows for
the Relay Forw./Relay Replay columns. I think if Relay agent is allowed to
include those vendor options in the
Relay Forw/Replay messages, just like it includes the Interface option,  
the rows for the  Vendor options should look like the row of  the Interface
option.

Am I missing something ? or did I misunderstand the entire meaning of the
table in Appendix B ?
Actually, what does the "Option Field" column in the table mean ?

Also what's the "Note" below the table refers to ?

Would you share more clarification/ insights on this ?

Thanks a lot in advance.

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 11:38:12 -0700

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

>DHCP server needs to know possibly all vendor specific RADIUS attributes?
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.

>other parameters the authors have in mind.
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