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

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

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