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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 Jan 2006 16:33:05 -0500

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:[email-masked]] 
> Sent: Friday, January 20, 2006 2:22 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> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Jan 2006 16:58:41 -0500

>> 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