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

[Christopher Wood <[e-mail]>]

On Wed, Sep 9, 2020, at 10:09 PM, Fernando Gont wrote:
> Hello, Chris,
> 
> Thanks a lot for your comments! In-line....
> 
> On 9/9/20 20:16, Christopher Wood via Datatracker wrote:
> > Reviewer: Christopher Wood
> > Review result: Has Nits
> > 
> > Summary: Has Nits
> > 
> > Comments:
> > 
> > - 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.)
> 
> Not sure what you mean. PDs with a lifetime of 0 are orthogonal to 
> Reconfigure messages.
> 
> If the client asked for reconfigure support, yes it will be accepting 
> server reconfigure messages.
> 
> However, Reconfigure messages are required to be unicasted (RFC8415, 
> Section 16.11), so there's no possibility for amplification (i.e., 
> single server packet triggering actions on multiple clients).

Got it. Thanks.

> > - Section 4: rationale for these default values,
> > if available, might be worth including. (Why not make them shorter? What are
> > the tradeoffs?)
> 
> I suggested to add this in response to Dale's comments:
> 
>   "  However, while the aforementioned values represent an improvement
>      over the default values specified in [RFC4861], they represent a 
> trade-off among a number of factors, including responsiveness, possible 
> impact on the battery life of connected devices [RFC7772], etc. Thus, 
> they may or may not provide sufficient mitigation to the problem 
> discussed in this document.
> "
> 
> ?

This seems reasonable to me.

> > - 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.)
> 
> Compromised as in "an attacked intentionally caused different bits to be 
> stored"?

Well, either maliciously or not, I suppose. I was just trying to learn if integrity is important. 

> If so, I'd say that's probably the least of your concerns. Since DHCPv6 
> exchanges are not encrypted or authenticated, your first concern would 
> be forged packets. If the attacker has essentially hacked the CE Router, 
> then all bets are off.
> 
> 
> 
> > Nits:
> > 
> > - In some places "\"Valid Lifetime\"" is written as "valid-lifetime" -- should
> > these be made consistent?
> 
> We use "Valid Lifetime" for SLAAC PIOs, and "valid-lifetime" for DHCPv6 
> options, since that's what the respective specs use. Please do let us 
> know if you think this should be clarified.

Ah! If that's well understood by others, then it's fine with me. (I wasn't aware of the difference.)

Thanks for following up. :-)

Best,
Chris