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

[[e-mail]]

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