Re: [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

[Erik Kline <[e-mail]>]

Actually, I'm wondering now if there's no good answer to problem of a
{moving client | client spoofed} that doesn't involve some other
trusted information coming to the rescue.

That could be client authentication of some kind, but it could also be
"infrastructure operational guarantees".

I read the revised existing paragraph as saying that the Relay
maintains state such that {interface, MAC, DUID} is the "unique key"
that can be used to identify the state/state machine for a given
client.  This is required to address the problem identified in
-00,S3.4, IIUC.

I think the proposed text clarifies the security risk of trying to
support a client that moved interfaces on the BNG, say (for whatever
reason).  If the relay moved the existing traffic to a new interface
wouldn't that allow a spoofer to hijack an otherwise legitimate
client's prefix?

I think addressing my prior comment might just end up making
everything worse.  It's probably more secure to force a renumbering if
the client moves relay interfaces.  In short, it might be best to
ignore me.  =)

On Tue, Apr 28, 2020 at 7:33 AM <[e-mail]> wrote:
>
> Hi Erik,
>
> I’m just going through the outstanding points on this draft and it seems your comment got overlooked. My apologies.
>
> There’s an change in the wording for G-5 (in response to a question from Bernie) that will be in the next update which might be relevant:
>
> If a device has multiple interfaces that implement
> a delegating relay function, the device SHOULD allow the same
> client identifier (DUID) to have active delegated prefix leases on
> more than one interface simultaneously, unless client DUID
> uniqueness is necessary for the functioning or security of the
> network.  This is to allow client devices with duplicate DUIDs to
> function on separate broadcast domains.
>
>
> To clear up your question, we could add the following new routing requirement:
>
> For devices with multiple interfaces implementing a delegating relay function:
> If a Relay-reply message is received containing an instance of OPTION_IAPREFIX with
> a prefix that already has an active lease /route on one interface, but with an
> interface identifier (e.g. the Link Address) that is for a different interface,
> then the relay should remove the existing lease / route and bind it to the
> new interface.
>
> Does that cover it for you?
>
> Thanks,
> Ian
>
> On 15. Jan 2020, at 02:03, Erik Kline <[e-mail]> wrote:
>
> I support adoption.
>
> I am confused about some things though.  Specifically related to 3.4 and 4.1 G-5.  Should the delegating relay support a client moving from one interface to another (presumably this just means honoring a request with previously allocated IA_PDs in it, updating the routes accordingly)?  I guess, what's the guidance for supporting a duplicate versus detecting a migration?
>
> [nits]
> S2.1: s/should be understand/should be understood/
>
> S2.1: s/specificcally/specifically/
>
> On Sun, Dec 29, 2019 at 8:03 AM Bernie Volz (volz) <[e-mail]> wrote:
>>
>> Hello:
>>
>>
>>
>> As follow up from the IETF-106 DHC WG meeting, we are initiating the WG call for adoption on https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/ (DHCPv6 Prefix Delegating Relay). This document was presented at IETF-106 – see https://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00.
>>
>>
>>
>> This starts the call for Adoption of this document. Please respond by January 14, 2020.
>>
>>
>>
>> Thanks in advance for your consideration of whether the WG should or should not adopt this document as a work item.
>>
>>
>>
>> And, Happy New Year!
>>
>>
>>
>> Tomek & Bernie
>>
>>
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>