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

["Leaf Yeh" <[e-mail]>]

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

Solution A - RFC 5460 may have no problem when relay-id uses DUID, because
the server seems only record the relay-id in the process of prefix
delegation, not use the relay-id for the client's prefix selecting &
assignment.

RFC5460 
<quote>
   This specification includes a new DHCPv6 option, the Relay-ID option.
   The option contains a DUID (DHCP Unique Identifier) identifying a
   DHCPv6 relay agent.  Relay agents can include this option in Relay-
   Forward messages they send.  Servers can retain the Relay-ID and
   associate it with bindings made on behalf of the relay's clients.  A
   relay can then recover binding information about downstream clients
   by using the Relay-ID in a LEASEQUERY message.
</quote>


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

Solution B - If GUA of the relay is used for the ID, then configure it into
that new hardware, but no need to update this part of the server's database.
I meant the IPv6 address plan has no change; the ID of the relay here need
be configurable & readable.


BV>Using an address causes similar issues if renumbering were to occur. 

If IPv6 address renumbering of the relay occurs, that sounds the address
plan has changed. We need re-configure the binding relationship (GUA of the
relay -> prefix Pool) in the server's database.


BV>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).

I wonder what kind of the ID for relay is used for the basic (or general)
case of DHCPv6-PD. GUA sounds a good choice for ID there, but the DUID might
not be so popular there. At least RFC3633 has not mentioned it.


BV>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'.

Solution C - If 'syntax' of the interface-id is independent with the
hardware of the relay, replacing the relay or (IPv6 address) renumbering the
relay may not change the interface-id. If the new & the old relay is the
same type, there could be no change in the interface-id; for example,
interface-id is only related with the location of the interface.

But if you really concern solution C (not a tool presently available ), I
would prefer solution B.


Best Regards,
Leaf



-----Original Message-----
From: Bernie Volz (volz) [mailto:[e-mail]] 
Sent: Saturday, April 20, 2013 11:15 PM
To: Leaf Yeh; 'Tomek Mrugalski'
Cc: [e-mail]; 'Ted Lemon'
Subject: RE: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02

(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