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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
