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

[Naveen Kottapalli <[e-mail]>]

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
>