[dhcwg] RE: IESG Discusses/Comments on draft-ietf-dhc-dhcpv6-remoteid-00. txt

["Wijnen, Bert (Bert)" <[e-mail]>]

I am OK with your proposed path to address my DISCUSS.

Bert

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Bernie Volz (volz)
> Sent: Friday, January 20, 2006 17:59
> To: [e-mail]; [e-mail]
> Subject: IESG Discusses/Comments on
> draft-ietf-dhc-dhcpv6-remoteid-00.txt
> 
> 
> The following DISCUSSED and COMMENTS were raised during IESG review of
> draft-ietf-dhc-dhcpv6-remoteid-00.txt (see
> https://datatracker.ietf.org/public/pidtracker.cgi?command=pri
> nt_ballot&
> ballot_id=1835&filename=draft-ietf-dhc-dhcpv6-remoteid):
> 
> DISCUSSES AND COMMENTS:
> ======================
> Sam Hartman:
> 
> Discuss [2005-11-27]:
> The security considerations section does not appear to discuss the
> potential problems associated with trusting the remote ID.  For
> example, spoofing caller ID information is relativly easy; if DHCP
> selected which network to put a subscriber on based on caller id, then
> this might be subject to abuse.  I'm not asking for a prohibition of
> such uses simply a discussion of the implications.
> 
> ---
> MY RESPONSE:
> 
> Sam: This option is used between a relay agent and a DHCP 
> server (added
> by the relay agent when relaying the client's request to the 
> server). In
> most deployments, these devices are under the same 
> administrative domain
> and the communication can be secured as stated in section 
> 21.1, Security
> of Messages Sent Between Servers and Relay Agents, of RFC 3315 (ie,
> IPsec).
> 
> Thus, I don't see that this should be an issue.
> 
> ---
> 
> David Kessens:
> 
> Comment [2005-12-01]:
> I support Bert's DISCUSS:
> 
> Why does the DHC working group not standarize an option for 
> for example:
> 
>  a "caller ID" telephone number for dial-up connection
> 
> It is very hard to make something 'globally unique' if you don't know
> what it
> is exactly.
> 
> ---
> MY RESPONSE:
> 
> This draft was based on the text in RFC 3046 (for DHCPv4).
> 
> We could certainly propose yet another registry for a format type. Or,
> perhaps even better, change the format to include the enterprise-id,
> such as:
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
> 7 8 9 0 1
>        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |       OPTION_REMOTE_ID        |         option-len   
>          |
>        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                       enterprise-number              
>          |
>        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        .                                                      
>          .
>        .                           remote-id                  
>          .
>        .                                                      
>          .
>        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Then, the enterprise can take responsibility to assure that the
> remote-id is unique.
> 
> What do folks thing about this proposal?
> 
> ---
> 
> Bert Wijnen:
> 
> Discuss [2005-12-01]:
> 
> Looking at section 3:
> 
>    3.  The Relay Agent Remote-ID Option
> 
>    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.
> 
> Then I wonder:
> - the option MAY be added. So one cannot assume it will be added by
> anyone
> - the option MAY be used for many things, but one never knows if/how
>   the server is going to use it
> - the "remote ID MUST be globally unique", yet it can be as short as 1
>   octet. How is that "global uniqueness" guaranteed/administered?
> 
> The doc is targeted for standards track.
> But what/how does this option do to help STANDARDIZE any DHCP(v6) 
> behaviour?
>  
> Or am I just confused?
> 
> ---
> MY RESPONSE:
> 
> See my previous response above to David Kessens' comments.
> 
> ---
> 
> - Bernie
> 

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