List Info

Thread: IESG Discusses/Comments on draft-ietf-dhc-dhcpv6-remoteid-00.txt




IESG Discusses/Comments on draft-ietf-dhc-dhcpv6-remoteid-00.txt
user name
2006-01-22 23:41:09
So, perhaps the easiest solution is to remove it from the
list of
possibilities.

- Bernie 

> -----Original Message-----
> From: Sam Hartman [mailto:hartmans-ietfmit.edu] 
> Sent: Friday, January 20, 2006 4:59 PM
> To: Bernie Volz (volz)
> Cc: iesgietf.org; dhcwgietf.org
> Subject: Re: IESG Discusses/Comments on 
> draft-ietf-dhc-dhcpv6-remoteid-00.txt
> 
> >>>>> "Bernie" == Bernie Volz
(volz) <volzcisco.com> 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
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg
IESG Discusses/Comments on draft-ietf-dhc-dhcpv6-remoteid-00.txt
user name
2006-01-23 00:13:58
>>>>> "Bernie" == Bernie Volz
(volz) <volzcisco.com> 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.


_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg
[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )