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

[Timothy Winters <[e-mail]>]

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=
[e-mail]> 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
>
> On Sep 18, 2020, at 1:09 PM, Naveen Kottapalli <[e-mail]>
> wrote:
>
> 
> 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=
> [e-mail]> 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)?
>>
>> And, is this something that someone has actually seen occur, or just a
>> theoretical issue that could happen.
>>
>> - Bernie
>>
>> -----Original Message-----
>> From: [e-mail] <[e-mail]>
>> Sent: Thursday, September 17, 2020 11:17 AM
>> To: Ole Troan <[e-mail]>
>> Cc: Bernie Volz (volz) <[e-mail]>; [e-mail]
>> 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, [e-mail] wrote:
>> >
>> > Ian,
>> >
>> >> [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.]
>> >>
>> >>>
>> >>>
>> >>> Two questions:
>> >>>
>> >>> 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.]
>> >
>> > Would you mind ellaborating on how exactly the setup (or attack) would
>> be constructed for this to happen?
>>
>> [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.]
>>
>> >
>> >>> 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?
>> >>
>> >> [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.
>> >
>> >>> - Is it supposed to be a silent discard or should you send a
>> destination unreachable?
>> >>
>> >> [if - Please see current text above.]
>> >
>> > Ack.
>> >
>> > Best regards,
>> > Ole
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>