Subject: RE: [dhcwg] Re: Last Call: 'DHCPv6 Relay Agent Remote ID Option' toProposed Standard

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 5 Oct 2005 08:41:35 -0400

Francis:

If this really is offensive, we can remove it -- there's little loss of
meaning.

But we must remember that this is NOT a means to communicate the RAS
user name! It is just an opaque identifier that the Relay Agent uses to
identify a port/circuit/etc. In section 5 it says "The remote-id SHOULD
be considered an opaque value, with policies based on exact string match
only; that is, the option SHOULD NOT be internally parsed by the
server."

Therefore, I don't see a conflict at all.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Francis Dupont
> Sent: Wednesday, October 05, 2005 4:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dhcwg] Re: Last Call: 'DHCPv6 Relay Agent Remote ID 
> Option' toProposed Standard 
> 
>  In your previous mail you wrote:
> 
>    The IESG has received a request from the Dynamic Host 
> Configuration WG to 
>    consider the following document:
>    
>    - 'DHCPv6 Relay Agent Remote ID Option '
>       <draft-ietf-dhc-dhcpv6-remoteid-00.txt> as a Proposed Standard
>    
> => I have a little concern about this I-D: one usage is to encode
> the '"user name" prompted for by a Remote Access Server' so it
> can conflict with draft-ietf-dhc-v6-relay-radius-01.txt when
> the RADIUS User-Name attribute can be transmitted to the 
> DHCPv6 server.
> 
> I don't believe this is a big issue but it should be clear in at least
> one of the two I-Ds what is the preferred way to transmit the NAS
> authentication to the DHCPv6 server. IMHO the RADIUS way is better
> when it is available, so this is what I implemented.
> 
> Regards
> 
> [email-masked]
> 
> PS: this issue doesn't exist for DHCPv4 because RFC 4014 is 
> an extension
> of RFC 3046.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Oct 2005 17:03:42 +0200

=> in fact I believe the change should be in the RRAO document.

   user name! ...
   
=> we need something to bind the NAS AAA and the DHCPv6 request in order
for instance to not assign a prefix owned by another user to someone
using a fake DUID. One only has to clarify this function is provided
by the RRAO: we seem to agree.

Regards

PS: RRAO = DHCPv6 Relay agent RADIUS Attribute Option.

---

From: John Schnizlein <[email-masked]>
Date: Thu, 6 Oct 2005 07:04:08 -0400

Why should the User-Name from an authorization of a person to access 
the network be bound to the Remote ID?  As should be clear from the 
list of example kinds of information the Remote ID can contain (copied 
below for convenience), there is no implication that this name has been 
authenticated.  The example that involves "user name" explicitly says 
"prompted for by a Remote Access Server" without any indication that 
the name had been authenticated.

I see no justification to create any linkage between these different 
names, and consider such linkage harmful, in this document or the RRAO.

 From draft-ietf-dhc-dhcpv6-remoteid-00.txt:
>
>    This option MAY be added by DHCPv6 relay agents which terminate
>    switched or permanent circuits and have mechanisms to identify the
>    remote host end of the circuit.  The remote-id field MAY be used to
>    encode, for instance:
>
>    o  a "caller ID" telephone number for dial-up connection
>    o  a "user name" prompted for by a Remote Access Server
>    o  a remote caller ATM address
>    o  a "modem ID" of a cable data modem
>    o  the remote IP address of a point-to-point link
>    o  a remote X.25 address for X.25 connections
>    o  an interface identity, which might be the switch's DUID [1]
>       suffixed by the interface-id from the DHCPv6 Interface-Id option.
>
>    The remote ID MUST be globally unique.

John

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Oct 2005 12:08:30 +0200

=> it seems we agree:
 - remote ID is not the proper way
 - RRAO is the proper way
 - remote ID document doesn't really need a clarification
 - RRAO document should be a bit clearer
So I transfer my concern to the RRAO document which is not yet in last call
(the clarification is just a short statement saying the same thing than
your message: the way to bind User-Name/authorization is to use the RRAO
to put the User-Name RADIUS attribute in messages to the server. BTW
I implemented it and it does exactly what is needed: I suggest to try
to advance the (improved) RRAO document ASAP).

Thanks