Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

From: [email-masked]
Date: Wed, 9 Sep 2020 11:28:56 +0200

Hi Bernie / Ole

Please see inline below. Where there is no additional comment, we’ve adopted Bernie’s suggestions.

Thanks,

> On 19. Aug 2020, at 00:15, Bernie Volz (volz) <volz=[email-masked]> wrote:
> 
> Thanks Ole ... I had also flagged that requirement as an issue in my shepherd review as it is not very clear.
> 
> I think the not configured on the relay means that the destination address hasn't been assigned as an address on one of the relay's interfaces.
> 
> I do wonder though what the "normal" router behavior would be - would it not just send the packet back and also send an ICMP redirect? And, why does this needs to be called out specially isn't clear?

[if - Yes, 

The requirement is intended to hand the case where, for whatever reason, the client’s routing traffic towards the delegating relay with a destination in the prefix that it’s been delegated. i.e. something’s wrong with the client’s routing. The obvious exception to this is if the link between the client and delegating relay has a prefix that is part of the delegation (e.g. the PD exclude case). 

The current wording is pretty unclear. How about:

old:
If the relay has an existing route for a delegated prefix via
 an interface, and receives ingress traffic on this interface
 with a destination address from the delegated prefix (not
configured on the relay), then it MUST be dropped.

new:
If the relay has learned a route for a delegated prefix via a given interface, and receives traffic
on this interface with a destination address within the
delegated prefix (but not directly connected to the relay),
then it MUST be dropped.  This is to prevent routing loops.

> 
> 
> Anyway, here's my comments for the shepherd review.
> 
> First, I do support this document moving forward.
> 
> Abstract:
> 
> "when the DHCPv6 relay function is not co-located with the DHCPv6 server function" is a bit weird as why would the relay even be needed in this case?

[if - The abstract is now Ted’s suggested wording:

This memo describes operational problems that are known to
    occur when using DHCPv6 relays with Prefix Delegation. These
    problems can prevent successful delegation and in result routing
    failures. To address these problems, this memo provides necessary
    functional requirements for operating DHCPv6 relays with Prefix
    Delegation.]

> 
> And, "time synchronization between DHCP functional elements" is really not covered much - it translate into O-3 as best I can gather? Just wondering if it is really worth mentioning in the abstract - but that leaves just "rejection of client's messages and other problems". Perhaps reworking this to provide a list of the main problems is worth considering? FYI  - you could add some kind of data recovery/persistence in case of 'crash'/restart?

[if - It did read ’timer syncronization’ - i.e. related to the times present in DHCP messages, but this text is no longer present.]

——

> 
> I'm not so clear why the last paragraph is important. And, it doesn't translate into a requirement? Perhaps one should be added if you think this is worth pointing out (over and above what RFC8415 has). Note that section 3.1 deals more with known messages and 'acting as a server’.

[if - Removed the last paragraph.]

-----

> 
> Would adding something about "or contains an unknown option" be useful to include here ... we don’t want relay's to not forward messages because they don't understand a "new" option? But this is already covered in Section 16 of RFC8415 (see below), so it may not be worth re-enforcing this as RFC8415 is already clear on this. I just raise it for your consideration (feel free to ignore).
> 
>   Clients, relay agents, and servers MUST NOT discard messages that
>   contain unknown options (or instances of vendor options with unknown
>   enterprise-number values).  These should be ignored as if they were
>   not present.  This is critical to provide for future extensions of
>   DHCP.
> 
> I might add that perhaps a new paragraph to this section that reads something like:
> 
> 	Relay implementers are reminded that RFC8415 makes it clear that relays MUST NOT drop
> 	(and hence not relay) packets that either contains message codes (Section 19 of RFC8415)
> 	it may not understand or contain options that it does not understand (Section 16 of RFC8415).
> 
> Or perhaps just add to General Requirements?

[if - removed this as requirement G-2, and now have your suggested ‘Relay implementors are reminded…’ text in the General Requirements intro.]

----

> 
> Section 4
> 
> Comment related to the requirements ... should these be tied back to the earlier sections? In some cases, it seems that requirements were added that aren't directly related to the earlier discussions? Should there be a "See section 3.x" added to identify where the requirement came from?
> 

[if - As the functionality of a delegating relay have not previously been defined, there isn’t a direct mapping between each of the requirements and a problem which has been observed in implementations.  The aim behind this draft is to resolve what we have seen, and hopefully pre-empt other undesirable behaviour.]

---

> 
> Section 4.2:
> I had issues with R-4 ... see Ole's discussion and the top of this message.

[if - See above]

> - Bernie
> 
> -----Original Message-----
> From: [email-masked] <[email-masked]> 
> Sent: Tuesday, August 18, 2020 3:24 AM
> To: Bernie Volz (volz) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
> 
> I have read through the document, reading section 4 thoroughly.
> I think it looks fine and ready to advance.
> 
> A comment:
> 
>   R-4:    If the relay has an existing route for a delegated prefix via
>           an interface, and receives ingress traffic on this interface
>           with a destination address from the delegated prefix (not
>           configured on the relay), then it MUST be dropped.
> 
> I struggle to understand what R-4 is trying to say.
> In one sentence it says it has a delegated prefix, then it says "not configured on the relay"...?
> 
> 
> Best regards,
> Ole
> 
> 
> 
>> On 17 Aug 2020, at 19:23, Bernie Volz (volz) <volz=[email-masked]> wrote:
>> 
>> Hi … just a friendly reminder. We’ve had very little input to the WGLC.
>> 
>> Tim and I will review the responses and evaluate the WGLC later this week (Friday), so you do have a few more days to respond.
>> 
>> 	• Bernie
>> 
>> From: dhcwg <[email-masked]> On Behalf Of Bernie Volz (volz)
>> Sent: Tuesday, August 11, 2020 8:20 AM
>> To: [email-masked]
>> Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
>> 
>> Hi … just a friendly reminder regarding this WGLC.
>> 
>> Thanks to Ted Lemon for reviewing and commenting!
>> 
>> 	• Bernie
>> 
>> From: Bernie Volz (volz) <[email-masked]> 
>> Sent: Saturday, August 1, 2020 11:07 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
>> 
>> Hi:
>> 
>> The authors believe this document is ready for WGLC. Therefore, the chairs are initiating a WGLC on this document.
>> 
>> Please review this document and provide your comments and whether you support this document moving forward or not by end of day on Monday, August 17th, 2020.
>> 
>> Please see https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-01.. This is a Standards Track document.
>> 
>> There are no IPR notices filed against this work (as of this writing).
>> 
>> Thank you!
>> 
>> 	• Tim & Bernie
>> 
>> --
>> 
>> From: Naveen Kottapalli <[email-masked]> 
>> Sent: Saturday, August 1, 2020 8:20 AM
>> To: [email-masked]; [email-masked]
>> Subject: Requesting a WGLC of draft-ietf-dhc-dhcpv6-pd-relay-requirements
>> 
>> Hello chairs,
>> 
>> We, as authors of the draft, are of the opinion that the draft is ready for WGLC.  Can you please check and initiate the same?
>> 
>> Yours,
>> Naveen.
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 9 Sep 2020 13:45:57 +0000

Hi:

Thanks.

Please see BV> below.

- Bernie

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, September 9, 2020 5:29 AM
To: Bernie Volz (volz) <[email-masked]>; Ole Troan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

Hi Bernie / Ole

Thanks,

[if - Yes, 

old:
If the relay has an existing route for a delegated prefix via  an interface, and receives ingress traffic on this interface  with a destination address from the delegated prefix (not configured on the relay), then it MUST be dropped.

new:
If the relay has learned a route for a delegated prefix via a given interface, and receives traffic on this interface with a destination address within the delegated prefix (but not directly connected to the relay), then it MUST be dropped.  This is to prevent routing loops.

BV> "(but not directly connected to the relay)" is a bit odd ... perhaps "where this address is not assigned to the relay" (remove the parentheses).
BV> Additional question ... RFC7084 has WPD-5 and they added an (a) about ICMPv6 Destination Unreachable ... do you want to say anything about whether to send ICMPv6 or not (probably not)?

BV> I think you want s/in result/result in/

BV> So, I'm not sure what the plan is with respect to this text? DHCP has a generic time synchronization problem in that everything is relative to when received (not necessarily transmitted) and resolution is seconds and no strong requirement for clocks to tic consistently. This is often why grace periods are applied to lease expiration times (though in most cases, this is probably also not necessary given that the client is probably not there as otherwise it would have renewed).

——

-----

----

BV> Perhaps text in 4.0 should say "To resolve the problems described in Section 3 and pre-empt other undesirable behavior, the following sections"? Or something like that?

---

[if - See above]

> Subject: Re: [dhcwg] WGLC for 
> draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 
> 2020
> 
>> Subject: Re: [dhcwg] WGLC for 
>> draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 
>> 2020
>> 
>> Subject: Requesting a WGLC of 
>> draft-ietf-dhc-dhcpv6-pd-relay-requirements
>> 
>> Hello chairs,
>>

---

From: [email-masked]
Date: Mon, 14 Sep 2020 13:40:42 +0200

Hi Bernie,

Thanks for your response. Please see inline below.

Thanks,
Ian

> BV> "(but not directly connected to the relay)" is a bit odd ... perhaps "where this address is not assigned to the relay" (remove the parentheses).

[if - I wondered about using something like this, but it only really makes sense if the client / relay are on a p-t-p link. If it’s a shared / NBMA link then other devices could be attached to segment and addressed from this prefix. Really, it’s an on-link prefix, so what about:

"and receives traffic on this interface with a destination address within the delegated prefix (that is not an on-link prefix for the relay), then it MUST be dropped."

> BV> Additional question ... RFC7084 has WPD-5 and they added an (a) about ICMPv6 Destination Unreachable ... do you want to say anything about whether to send ICMPv6 or not (probably not)?

[if - I think it makes sense. I’ve added the following to R-4:

An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject
route to destination) error message MAY be sent back to
the client.  The ICMP policy SHOULD be configurable.]

----

> BV> So, I'm not sure what the plan is with respect to this text? DHCP has a generic time synchronization problem in that everything is relative to when received (not necessarily transmitted) and re…

[if - I’m a little confused as to which text you’re referring to now. The original comment was related to the ‘..issues such as timer synchronization between..’ wording in the abstract. The abstract text has now been replaced using Ted’s suggested wording and does not mention timers at all. This is the current abstract wording:

    problems can prevent successful delegation and result in routing
    Delegation.

   It is recommended that any network operator that is using DHCPv6
    prefix delegation with relays should ensure that these requirements
    are followed on their networks.

Req G-8 is for DHCP lease timer synchronisation:

    G-8: The delegating relay MUST update the lease
    lifetimes based on the Client Reply messages it forwards to the
    client and only expire the delegated prefixes when the valid
    lifetime has elapsed.]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Sep 2020 13:35:35 +0000

Hi.

See below (BV2>).

  *   Bernie

From: [email-masked] <[email-masked]>
Sent: Monday, September 14, 2020 7:41 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Ole Troan <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

Hi Bernie,

Thanks,
Ian

On 19. Aug 2020, at 00:15, Bernie Volz (volz) <volz=[email-masked]<mailto:volz=[email-masked]>> wrote:

[if - Yes,

old:

new:

BV2> Hum … Perhaps Ole has some thought. Not sure that really covers it.

BV2> OK!
----

BV2> OK … Just wanted to make sure the ‘timer synchronization’ bit earlier in the document was either removed or expanded upon; removed is fine.

---

From: [email-masked]
Date: Tue, 15 Sep 2020 09:32:33 +0200

> BV2> Hum … Perhaps Ole has some thought. Not sure that really covers it.

OK, so here is the text again:

Two questions:

1) What is the case where this would triggered? That wouldn't be caught by uRPF (R-2)?
2) On a multi-access link, how should this even be implemented?
   drop if rx-interface == tx-interface and packet source mac == next-hop mac?

- Is it supposed to be a silent discard or should you send a destination unreachable?

Depending on the answers to the above I do wonder if this requirement is needed or not.

Cheers,
Ole

---

From: [email-masked]
Date: Tue, 15 Sep 2020 14:15:24 +0200

Hi Ole,

Please see inline below.

Thanks,
Ian

> On 15. Sep 2020, at 09:32, [email-masked] wrote:
> 
>> 

[if - There’s been quite a lot of iterations on this since -01. The current working version is:

R-4:
If the relay has learned a route for a
delegated prefix via a given interface, and receives traffic
on this interface with a destination address within the
delegated prefix (that is not an on-link prefix for the relay),
then it MUST be dropped.  This is to prevent routing loops.
An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject
route to destination) error message MAY be sent back to
the client.  The ICMP policy SHOULD be configurable.]

> 1) What is the case where this would triggered? That wouldn't be caught by uRPF (R-2)?

[if - The traffic is originated from a valid source prefix so uRPF (R-2) doesn't cover it. This requirement is concerned with the destination.]

>   drop if rx-interface == tx-interface and packet source mac == next-hop mac?

[if - That sounds like it would cover it.]

> - Is it supposed to be a silent discard or should you send a destination unreachable?

[if - Please see current text above.]

---

From: [email-masked]
Date: Tue, 15 Sep 2020 14:31:32 +0200

Ian,

> [if - The traffic is originated from a valid source prefix so uRPF (R-2) doesn't cover it. This requirement is concerned with the destination.]

Would you mind ellaborating on how exactly the setup (or attack) would be constructed for this to happen?

> [if - That sounds like it would cover it.]

I think it would be useful to get implementors to chime in how practical this is to implement.

> [if - Please see current text above.]

Ack.

Best regards,
Ole

---

From: [email-masked]
Date: Thu, 17 Sep 2020 17:16:59 +0200

Hi,

Please see inline.

Thanks,
Ian

> On 15. Sep 2020, at 14:31, [email-masked] wrote:
> 
> Ian,
> 

[if - The 2 cases would be a bug in the HGW (prefix delegated but routing table not updated so default route is still used), or an attack where rogue clients deliberately send this traffic.]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 17 Sep 2020 16:24:54 +0000

Hi:

One thing to ask is whether this issue is worth continuing debate on this document? Removing it would probably let the document move forward ...

Regarding your answer Ian: [if - The 2 cases would be a bug in the HGW (prefix delegated but routing table not updated so default route is still used), or an attack where rogue clients deliberately send this traffic.]

- An attacker could always send lots of traffic; sure if it is sent back by the relay router, it causes more traffic but eventually the hop limit will be hit and the packet will be dropped. Though wouldn't fixing this at the CPE router (which this document does not cover) be a better place to fix it?
- If there's a bug, perhaps better to learn about it earlier and get it fixed? Someone might notice if they see their throughput drop?

I'm still wondering what a normal router would do in this case and why this needs to be different than general router behavior? Also, could the CPE use this to test connectivity over the WAN link (i.e., send a packet to itself using an address in the PD expecting it to be looped back by the next hop (relay) router)?

And, is this something that someone has actually seen occur, or just a theoretical issue that could happen.

- Bernie

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Thursday, September 17, 2020 11:17 AM
To: Ole Troan <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

Hi,

Please see inline.

Thanks,
Ian

>> If the relay has learned a route for a delegated prefix via a given 
>> interface, and receives traffic on this interface with a destination 
>> address within the delegated prefix (that is not an on-link prefix 
>> for the relay), then it MUST be dropped.  This is to prevent routing 
>> loops.
>> An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to 
>> destination) error message MAY be sent back to the client.  The ICMP 
>> policy SHOULD be configurable.]
>> 
>>> 
>>> 
>>> Two questions:
>>> 
>> [if - The traffic is originated from a valid source prefix so uRPF 
>> (R-2) doesn't cover it. This requirement is concerned with the 
>> destination.]
>

---

From: Naveen Kottapalli <[email-masked]>
Date: Fri, 18 Sep 2020 22:37:47 +0530

Hello Bernie,

As suggested we are of opinion that the requirement will be dropped.

Yours,
Naveen.

On Thu, 17 Sep 2020 at 21:55, Bernie Volz (volz) <volz=
[email-masked]> wrote:

> Hi:
>
> One thing to ask is whether this issue is worth continuing debate on this
> document? Removing it would probably let the document move forward ...
>
> Regarding your answer Ian: [if - The 2 cases would be a bug in the HGW
> (prefix delegated but routing table not updated so default route is still
> used), or an attack where rogue clients deliberately send this traffic.]
>
> - An attacker could always send lots of traffic; sure if it is sent back
> by the relay router, it causes more traffic but eventually the hop limit
> will be hit and the packet will be dropped. Though wouldn't fixing this at
> the CPE router (which this document does not cover) be a better place to
> fix it?
> - If there's a bug, perhaps better to learn about it earlier and get it
> fixed? Someone might notice if they see their throughput drop?
>
> I'm still wondering what a normal router would do in this case and why
> this needs to be different than general router behavior? Also, could the
> CPE use this to test connectivity over the WAN link (i.e., send a packet to
> itself using an address in the PD expecting it to be looped back by the
> next hop (relay) router)?
>
> [if - The 2 cases would be a bug in the HGW (prefix delegated but routing
> table not updated so default route is still used), or an attack where rogue
> clients deliberately send this traffic.]
>
> >

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 18 Sep 2020 18:01:24 +0000

In our co-chair call today, Tim and I dicussed this and he should be sending some comments which may help with the issue. Please wait for those before making changes.

- Bernie

On Sep 18, 2020, at 1:09 PM, Naveen Kottapalli <[email-masked]> wrote:

Hello Bernie,

Yours,
Naveen.

On Thu, 17 Sep 2020 at 21:55, Bernie Volz (volz) <volz=[email-masked]<mailto:[email-masked]>> wrote:
Hi:

- Bernie

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 17, 2020 11:17 AM
To: Ole Troan <[email-masked]<mailto:[email-masked]>>
Cc: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

Hi,

Please see inline.

Thanks,
Ian

> On 15. Sep 2020, at 14:31, [email-masked]<mailto:[email-masked]> wrote:
>
> Ian,
>

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Timothy Winters <[email-masked]>
Date: Mon, 21 Sep 2020 08:19:06 -0400

As Bernie mentioned we discussed this recently.  I was under the impression
that this requirement was to prevent a forwarding loop when the CPE/Relay
don't have the same information.  For example,

   1.  the CPE has forgotten or lost the PD given to it.
   2. The Relaying Router will continue to forward traffic to the CPE.
   3. Since the CPE doesn't have the PD it will use it's default route
   (Relay Router)
   4. Relay Router will forward the traffic back to the CPE.
   5. Forwarding Loop until PD happens.

If this is what we are trying to prevent I think we might want to keep this
in.  I have seen situations were the CPE can't get a PD due to network
congestion in this state.

~Tim

On Fri, Sep 18, 2020 at 2:02 PM Bernie Volz (volz) <volz=
[email-masked]> wrote:

> In our co-chair call today, Tim and I dicussed this and he should be
> sending some comments which may help with the issue. Please wait for those
> before making changes.
>
> - Bernie
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 21 Sep 2020 13:13:41 +0000

Hi:

If that’s indeed the situation to be addressed, adding a section 3.5 or similar to document this issue would be really useful.

If Ole’s happy with the most recent proposed R-4 requirement text and this new detail is added, it would address my concerns.

  *   Bernie

From: Timothy Winters <[email-masked]>
Sent: Monday, September 21, 2020 8:19 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Naveen Kottapalli <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

As Bernie mentioned we discussed this recently.  I was under the impression that this requirement was to prevent a forwarding loop when the CPE/Relay don't have the same information.  For example,

  1.   the CPE has forgotten or lost the PD given to it.
  2.  The Relaying Router will continue to forward traffic to the CPE.
  3.  Since the CPE doesn't have the PD it will use it's default route (Relay Router)
  4.  Relay Router will forward the traffic back to the CPE.
  5.  Forwarding Loop until PD happens.
If this is what we are trying to prevent I think we might want to keep this in.  I have seen situations were the CPE can't get a PD due to network congestion in this state.

~Tim

---

From: [email-masked]
Date: Mon, 21 Sep 2020 15:18:24 +0200

> If Ole’s happy with the most recent proposed R-4 requirement text and this new detail is added, it would address my concerns.

And I would also be happy if we could have some implementors chime in with a "we are happy and able to implement this requirement".

Best regards,
Ole