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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 22 Jan 2006 18:41:09 -0500

So, perhaps the easiest solution is to remove it from the list of
possibilities.

- Bernie 

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Friday, January 20, 2006 4:59 PM
> To: Bernie Volz (volz)
> Cc: [email-masked]; [email-masked]
> Subject: Re: IESG Discusses/Comments on 
> draft-ietf-dhc-dhcpv6-remoteid-00.txt
> 
> >>>>> "Bernie" == Bernie Volz (volz) <[email-masked]> writes:
> 
>     Bernie> Sam:
>     >> Does this make sense?
> 
>     Bernie> No, it doesn't make sense.
> 
>     Bernie> The reference to caller id in the draft is:
> 
>     Bernie>    o a "caller ID" telephone number for dial-up connection
> 
>     Bernie> The model for this is that the relay agent terminates
>     Bernie> dial-up connections (from the PSTN). So, when a computer
>     Bernie> connected over that dial-up connection makes a DHCP
>     Bernie> request, the relay agent (which captured the caller id
>     Bernie> telephone number when the call was accepted), could add
>     Bernie> the caller ID in the relayed DHCP request.
> 
>     Bernie> We assume we trust the relay agent because it is in the
>     Bernie> same administrative domain as the server that will assign
>     Bernie> the address. 
> 
> Agreed.
> 
>     Bernie> If the caller id information can't be trusted
>     Bernie> from the PSTN, 
> 
> It cannot; that's most of my point.
> 
>     Bernie> then obviously this should not be used to
>     Bernie> add identity information that might be used by the DHCP
>     Bernie> server to provide addresses. (It might still be used by
>     Bernie> the server and relay for other purposes, such as aiding
>     Bernie> the relay to return the packet to the correct circuit;
>     Bernie> though the DHCPv6 interface-ID option is a much better
>     Bernie> mechanism for that purpose.)
> 
> It's this concern--and the general classes of concern that would arise
> if a relay agent used untrusted information to populate this option
> that I want documented in the security considerations section.
> 
>     Bernie> I'm not sure how VoIP enters into this picture? 
> 
> Originating a VOIP call through a PSTN gateway is one of the easiest
> ways of spoofing caller ID at the other end of the PSTN.  There are
> other ways but the general result is that caller ID cannot be trusted.
> 
> --Sam
> 

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

---

From: Sam Hartman <[email-masked]>
Date: Sun, 22 Jan 2006 19:13:58 -0500

>>>>> "Bernie" == Bernie Volz (volz) <[email-masked]> writes:

    Bernie> So, perhaps the easiest solution is to remove it from the
    Bernie> list of possibilities.

I'm not particularly happy with that because:

1) I actually suspect some sites will decide that the risks are worth
   it and will actually use caller ID.

2) I think other identifiers that people might use with these options
   may have similiar isues.

I'd suggest text like the following for security considerations:

Note that even if the DHCP server trusts the relay agent not to modify
information provided in this option, the confidence in that
information is no higher than the confidence that the relay agent has
in the information it puts in the option.  For example, in some
protocols it may be possible for a DHCP client to spoof or otherwise
choose port identifiers, caller ID information, or other information
carried in this option.  Sites should consider such possible spoofing
and how likely it is in their environment when deciding what uses of
this option are appropriate.