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

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

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=print_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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Jan 2006 14:21:43 -0500

>>>>> "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=print_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?