Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02

["Bernie Volz (volz)" <[e-mail]>]

(WG co-chair hat off.)

There are multiple forms of DUID - two of which are not associated with link-layer addresses (DUID-EN and DUID-UUID). Cable Modems have been using the DUID-LL because that makes it easy as the mac-address has been used for V4 and it is easy enough to map this to the DUID-LL.

For RFC 5460, using the DUID seemed like a good approach - DHCPv6 was using DUID for clients and servers already, so why not relays. The recent proposal for DHCPv4 Relay ID (almost out as an RFC) is not as strict as RFC 5460.

I don't think we want to "replace" the existing v6 Relay-ID option with alternatives, but that it something that is always up to the WG. I think this would mean defining a new option as it would be bad to reuse this existing option for something that is clearly not a DUID (perhaps you can get a new DUID type defined that allows for an 'opaque' identifier - but I suspect that won't be easy as this would lead to the same issues as exist with the DHCPv4 "client-id" where two people can use the same identifier).

Again, if the Interface-ID is unique enough by other standards which would have to apply when prefix-pool is used, then there is no issue - but this would have to be a clear requirement of using prefix-pool. Personally, I think this will be missed and is not a good idea.

Whatever identifier is used is always problematic as replacing the hardware will likely require configuring the old identifier into that new hardware or updating the server's database. Using an address causes similar issues if renumbering were to occur. Also, an address may cause problems when there are multiple relays being used (yes, it is in the peer-address field) but depending on the 'next hop' destination address used by the relay, it may not be a GUA (the stack may pick a different source address).

The Interface-ID (if containing enough to make it 'unique' across devices, not just within a device) has these same issues - replacing the relay or renumbering may change the 'interface-id'.

I think you should just use the tools presently available (i.e., Relay ID & Interface ID options) as alternatives are unlikely to have sufficient benefits.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Leaf Yeh
Sent: Saturday, April 20, 2013 6:21 AM
To: Bernie Volz (volz); 'Tomek Mrugalski'
Cc: [e-mail]; 'Ted Lemon'
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02

The OPTION_RELAY_ID defined in RFC 5460 employs the DUID, which is associated with the hardware (or link-layer) address, time of generation or assigned to the DU at the time of manufacture, and has 3 formats (type 1-LTT, 2-EN, 3-LL) defined in RFC3315. These DUIDs sounds not easy to collect beforehand & unfriendly to read by the administrator, who need that to configure the binding relation with the prefix pools on the server for the right prefix delegation (or assignment).

Let's go back to the basic relay case of DHCPv6-PD without the mechanism introduced in this draft (OPTION_PREFIX_POOL), how to assign a prefix from a particular pool to the CE? I suppose the basic relay case has the same problem of the uniqueness. GUA(+interface-id) of relay sounds much easy & readable than DUID(+interface-id). 

Otherwise, could we update the format of OPTION_RELAY_ID defined in RFC5460 to be:


 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_RELAY_ID         |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            relay-ID                           .
.                        (variable length)                      .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code   OPTION_RELAY_ID.
option-len    Length of DUID in octets.
relay-ID      An opaque value of arbitrary length configured
              by the relay agent.

which sounds the same requirement on the administrative uniqueness as that of interface-id, but keep the interface-id to only have significance to the relay itself. 



Best Regards,
Leaf



-----Original Message-----
From: Bernie Volz (volz) [mailto:[e-mail]]
Sent: Friday, April 19, 2013 8:16 PM
To: Leaf Yeh
Cc: [e-mail]
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013

Yes, using relay-id should solve the problem of uniquess. Lacking that, perhaps GUA can be used but is not as good. 

Server does not echo back relay-id unless Relay asked it to using the ERO.

- Bernie

On Apr 18, 2013, at 11:20 PM, "Leaf Yeh" <[e-mail]> wrote:

> BV> The interface id option can not be used to identify the relay. 
> BV> There is
> no requirement that the interface id is globally unique - it only has 
> significance to the relay itself.
> 
> If we decide to come back & comply with the exact language of IETF 
> defined before, how about to update the text in section 5 to be
> 
> "The relay agent SHOULD include the Relay ID option (OPTION_RELAY_ID,
> 53) or Interface ID option (OPTION_INTERFACE_ID, 18) so that the 
> server can identify the relay agent itself or its particular 
> customer-facing interface with which the prefix pool is associated, if 
> the server can not use the link-address field specified in the 
> encapsulation of the DHCPv6 RELAY-FORW message to identify the 
> interface of the link on which the clients are located."
> 
> and the text in section 6 to be
> 
> "The server MAY use the link-address specified in RELAY-FORW message 
> to identify the relay agent itself and its particular customer-facing 
> interface where the prefix pool is associated, but the server has to 
> maintain the binding data of prefix pools in association with these 
> link-addresses. To be more readable, the server can alternatively use 
> Relay-ID and Interface-ID option included in the RELAY-FORW message by 
> the relay agent to identify the relay agent itself and its particular 
> customer-facing interface where the prefix pool is associated. In 
> order to give a meaningful reply, the server has to maintain the 
> binding data of prefix pools in association with these Relay-ID and 
> Interface-ID. According to DHCPv6 [RFC3315], the server SHOULD copy 
> the Interface-ID option from the RELAY-FORW message into the 
> RELAY-REPL
message."
> 
> 
> Does the server need to copy Relay-ID from the RELAY-FORW into the 
> RELAY-REPL?
> 
> 
> Best Regards,
> Leaf
> 
> PS. Note that the Fig.1 & 2 in section 3 will be updated accordingly.
> 
> 
> 
> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[e-mail]]
> Sent: Wednesday, April 17, 2013 7:49 PM
> To: Leaf Yeh
> Cc: Tomek Mrugalski; [e-mail]
> Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - 
> Respond by April 8, 2013
> 
> Fyi -
>> To be more readable, the server can alternatively  use the Interface 
>> ID option included in the RELAY-FORW message by the  relay agent to 
>> identify the relay agent itself
> 
> The interface id option can not be used to identify the relay. There 
> is no requirement that the interface id is globally unique - it only 
> has significance to the relay itself.
> 
> - Bernie
> 
> On Apr 17, 2013, at 7:07 AM, "Leaf Yeh" <[e-mail]> wrote:
> 
>> Tomek - How about "Misconfigured or compromised DHCPv6 server can 
>> cause relays to start announcing arbitrary prefixes, including 
>> default routes, which could lead to traffic hijack."?
>> 
>> I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't 
>> bought in the part of 'Compromised DHCPv6 server'. I don't believe 
>> the ORO option included by the relay could compromise the DHCPv6 server.
> Right?
>> 
>> 
>>> Tomek - ...this draft repeats normative language from RFC3315 (e.g. 
>>> "The relay agent SHOULD include the Interface ID option")...
>> 
>> Section 6 of the draft (OPTION_PREFIX_POOL) has the following text:
>> "The server MAY use the link-address specified in RELAY-FORW message 
>> to identify the relay agent itself or its particular customer-facing 
>> interface where the prefix pool is associated, but the server has to 
>> maintain the binding data of prefix pools in association with these 
>> link-addresses.  To be more readable, the server can alternatively 
>> use the Interface ID option included in the RELAY-FORW message by the 
>> relay agent to identify the relay agent itself or its particular 
>> customer-facing interface where the prefix pool is associated.  In 
>> order to give a meaningful reply, the server has to maintain the 
>> binding data of prefix pools in association with the information 
>> derived from the Interface ID option."
>> The draft (OPTION_PREFIX_POOL) recommends to use interface-id for 
>> both use cases shown in section 3.
>> 
>> 
>> Tomek -RFC3315: relay MUST include interface-id if the link-address 
>> in server's response is not sufficient to select downlink interface.
>> prefix-pool-opt-02: relay SHOULD include interface-id, so the the 
>> server can identify the relay itself
>> (tomek: that's wrong. Interface-id is for interface or subnet 
>> identification, not relay identification. Relay-id is used for that 
>> purpose, see RFC5460, section 5.4.1)
>> 
>> There might be a small debate here. The question could be whether the 
>> server could identify the relay after receiving the interface-id of 
>> it. I guess our smart server already support that in the real 
>> deployment. [Pls. refer to 'Access Node identifier' in BBF TR-177 
>> (http://www.broadband-forum.org/technical/trlist.php ) and its R-30:
>> The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be 
>> able to use Option 18 in order to retrieve the Access Node identifier 
>> and access this table in order to identify the ad-hoc pool of 
>> prefixes or addresses.]
>> 
>> OTOH, I believe relay-id defined in RFC5460 can also be used in the 
>> case 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig.
>> 2); though if the mechanism of Bulk-Lease-Query is employed, the 
>> relay also need to include OPTION_ RELAY_ID in the relay-forward 
>> message for the basic operation of DHCPv6 prefix or address assignment.
>> 
>> 
>> Tomek - ... if the server would not like to use the link-address 
>> field specified in RELAY-FORW message
>> (tomek: that imprecise or wrong. The server is not at liberty to "not 
>> use link-address field". There's a specific algorithm defined in 
>> section 11 of
>> RFC3315 that the server must follow it).
>> 
>> Section 11 of RFC3315, Selecting Addresses for Assignment to an IA, 
>> has the following text:
>> " A server selects addresses to be assigned to an IA according to the 
>> address assignment policies determined by the server administrator 
>> and the specific information the server determines about the client 
>> from some combination of the following sources:
>>  -  The link to which the client is attached. ... If the server 
>> receives the message from a forwarding relay
>>        agent, then the client is on the same link as the one to which
>>        the interface, identified by the link-address field in the
>>        message from the relay agent, is attached...
>>  -  The DUID supplied by the client.
>>  -  Other information in options supplied by the client.
>>  -  Other information in options supplied by the relay agent."
>> The above text sounds not put link-address ahead of options supplied 
>> by the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF 
>> TR-177, its R-07,
>> R-08 & section6.6 (...In some deployments there is neither a need nor 
>> a desire to configure a global or unique local address to the 
>> interface on which the client messages are received. Such a 
>> deployment does not allow the BNG to insert an IPv6 address in the 
>> link-address field...).]
>> 
>> 
>> Best Regards,
>> Leaf
>> 
>> 
>> 
>> -----Original Message-----
>> From: Tomek Mrugalski [mailto:[e-mail]]
>> Sent: Sunday, April 14, 2013 8:26 PM
>> To: Leaf Yeh
>> Cc: [e-mail]
>> Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02
>> - Respond by April 8, 2013
>> 
>> On 13-04-12 03:15, Leaf Yeh wrote:
>>> Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? 
>>> Your relay will hijack the whole network? ...
>>> 
>>> The relay's behavior is still under control by the server. If it got 
>>> the wrong configuration, the server could also send out ::/0 in the 
>>> IA_PD. So this may sound an administration error. We just want the 
>>> prefix pools not configure to be ::/0 or any overlap between them. I 
>>> feel a little stuck on the exact text you want. How about 'The 
>>> administrator of the DHCPv6 server should pay more attention to the 
>>> configuration of the prefix pools, for examples, a. ::/0 may cause a 
>>> big routing problem in the whole ISP network; b. the configuration 
>>> of prefix pool should avoid overlap in the address plan, and etc.'
>>> ?  I am
>> not quite sure...
>> Administrator mistake is one concern, the other one is that DHCPv6 
>> server may become an attractive attack target when prefix-pool is
> deployed.
>> 
>> How about "Misconfigured or compromised DHCPv6 server can cause 
>> relays to start announcing arbitrary prefixes, including default 
>> routes, which could lead to traffic hijack."?
>> 
>>> Tomek - Bernie had this concern and I tend to agree with him... the 
>>> length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my 
>>> reply to Bernie's email. Thanks for your suggestion here. Do we need 
>>> more explanation on the mathematic function of floor() ? :-)
>> I don't think so. A potential implementor who doesn't know what
>> floor() function does should probably consider starting a career in 
>> some other industry. :-)
>> 
>>> Tomek - ...(I know that requestor in most cases is part of a relay, 
>>> but from protocol perspective these are separate entities)...Yes.
>>> Please split actions taken by requestor into separate section. It 
>>> can be subsection 5.1 if you like to.
>>> 
>>> Do you mean add section 5.1 "Leasequery Requestor Behavior" in the 
>>> section 5 "Relay Agent Behavior" (just for an editorial change)? Do 
>>> you want section
>>> 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"?
>> Yes to both.
>> 
>>> Tomek - ...this draft repeats normative language from RFC3315 (e.g. 
>>> "The relay agent SHOULD include the Interface ID option")...
>>> 
>>> After searching and reading, I still can't find this sentence in
RFC3315.
>> It is in prefix-pool-opt-02, section 5, second paragraph. Text from
>> prefix-pool-opt-02 is an imprecise subset of behaviour described in 
>> RFC3315, section 20.1.1, second paragraph. Here's the difference:
>> 
>> RFC3315: relay MUST include interface-id if the link-address in 
>> server's response is not sufficient to select downlink interface.
>> 
>> prefix-pool-opt-02: relay SHOULD include interface-id, so the the 
>> server can identify the relay itself (tomek: that's wrong.
>> Interface-id is for interface or subnet identification, not relay 
>> identification. Relay-id is used for that purpose, see RFC5460, 
>> section 5.4.1) if the server would not like to use the link-address 
>> field
> specified in RELAY-FORW message (tomek:
>> that imprecise or wrong. The server is not at liberty to "not use 
>> link-address field". There's a specific algorithm defined in section
>> 11 of
>> RFC3315 that the server must follow it).
>> 
>> Tomek
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg