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

Sam:

> Does this make sense?

No, it doesn't make sense.

The reference to caller id in the draft is:

   o  a "caller ID" telephone number for dial-up connection

The model for this is that the relay agent terminates dial-up
connections (from the PSTN). So, when a computer connected over that
dial-up connection makes a DHCP request, the relay agent (which captured
the caller id telephone number when the call was accepted), could add
the caller ID in the relayed DHCP request.

We assume we trust the relay agent because it is in the same
administrative domain as the server that will assign the address. If the
caller id information can't be trusted from the PSTN, then obviously
this should not be used to add identity information that might be used
by the DHCP server to provide addresses. (It might still be used by the
server and relay for other purposes, such as aiding the relay to return
the packet to the correct circuit; though the DHCPv6 interface-ID option
is a much better mechanism for that purpose.)

I'm not sure how VoIP enters into this picture? I'd assume that once the
connection is established and the addresses assigned via DHCP, perhaps
the connection is used to place VoIP calls. But I don't see how the VoIP
interaction ever supplies the caller-id used (perhaps people are placing
dial-up calls over VoIP connections?)

- Bernie 

> -----Original Message-----
> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] 
> Sent: Friday, January 20, 2006 2:22 PM
> To: Bernie Volz (volz)
> Cc: iesg@ietf.org; dhcwg@ietf.org
> Subject: Re: IESG Discusses/Comments on 
> draft-ietf-dhc-dhcpv6-remoteid-00.txt
> 
> >>>>> "Bernie" == Bernie Volz (volz) <volz@cisco.com> writes:
> 
>     Bernie> The following DISCUSSED and COMMENTS were raised during
>     Bernie> IESG review of draft-ietf-dhc-dhcpv6-remoteid-00.txt (see
>     Bernie> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=pri
> nt_ballot&
>     Bernie> ballot_id=1835&filename=draft-ietf-dhc-dhcpv6-remoteid):
> 
>     Bernie> DISCUSSES AND COMMENTS: ====================== Sam
>     Bernie> Hartman:
> 
>     Bernie> Discuss [2005-11-27]: The security considerations section
>     Bernie> does not appear to discuss the potential problems
>     Bernie> associated with trusting the remote ID.  For example,
>     Bernie> spoofing caller ID information is relativly easy; if DHCP
>     Bernie> selected which network to put a subscriber on based on
>     Bernie> caller id, then this might be subject to abuse.  I'm not
>     Bernie> asking for a prohibition of such uses simply a discussion
>     Bernie> of the implications.
> 
>     Bernie> --- MY RESPONSE:
> 
>     Bernie> Sam: This option is used between a relay agent and a DHCP
>     Bernie> server (added by the relay agent when relaying the
>     Bernie> client's request to the server). In most deployments,
>     Bernie> these devices are under the same administrative domain and
>     Bernie> the communication can be secured as stated in section
>     Bernie> 21.1, Security of Messages Sent Between Servers and Relay
>     Bernie> Agents, of RFC 3315 (ie, IPsec).
> 
>     Bernie> Thus, I don't see that this should be an issue.
> 
>     Bernie> ---
> 
> The issue is not the security of the communication between the relay
> agent and the server, but the authenticity of the data the 
> relay agent gains.
> 
> The primary case I'm thinking of is caller ID data.  It is reasonably
> easy, particularly with VOIP, to claim whatever caller ID information
> you like when placing a call.  So, if the DHCP server trusts the
> caller ID information and for example bills a customer or chooses
> which network to attach the customer to based on this information,
> then an attacker may be attached to the wrong network or bill the
> wrong person.
> 
> Other information carried in this option may be similarly spoofable.
> 
> Does this make sense?
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg