Re: [v6ops] Secdir last call review of draft-ietf-v6ops-cpe-slaac-renum-04

[Christopher Wood <[e-mail]>]

On Wed, Sep 9, 2020, at 4:31 PM, Ted Lemon wrote:
> On Sep 9, 2020, at 7:16 PM, Christopher Wood via Datatracker 
> <[e-mail]> wrote:
> > - Section 3: is it possible for an attacker to send DHCPv6 Prefix Delegations
> > with lifetime=0 to CE routers that support LAN-side DHCPv6 and amplify
> > Reconfigure messages to supporting clients? (I don't know if this is a concern
> > or part of the threat model, but this did seem to be a case of possible
> > request/response asymmetry.) - Section 4: rationale for these default values,
> > if available, might be worth including. (Why not make them shorter? What are
> > the tradeoffs?) - Section 6: it might be worth noting what happens if stable
> > storage is unavailable or otherwise compromised when trying to store prefix
> > information. What happens if the "A" or "L" bits are modified? (I suspect
> > nothing dangerous, but it's not clear to me whether or not integrity is
> > important.)
> 
> The attacker on the southbound link would have to know the transaction 
> ID of the DHCP request/confirm/renew message, which is only sent on the 
> northbound interface, and would have to know the DUID and IAID used by 
> the client, again never seen on the southbound link, and would have to 
> know the server’s DUID, again only visible northbound. I don’t think 
> this is a feasible attack. It’s hard to see what the benefit of such an 
> attack would be—in order to effect this attack without knowledge of the 
> exchange on the northbound interface, the client would have to be 
> continuously spamming the southbound link with attempts, so that would 
> be a negative amplication factor of perhaps 2^256, perhaps less if the 
> identifiers can be predicted and renewal times can be predicted.
> 
> And this assumes that the DHCPv6 PD client on the CPE device will even 
> accept a DHCP Reply on its southbound interface.
> 
> :)

That makes sense -- thanks for clarifying!