Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-conditional-ras-06: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Thanks for the updates, Jen.  [inline]

On Thu, Aug 02, 2018 at 12:50:46PM +1000, Jen Linkova wrote:
> Hi Benjamin,
> 
> > I'll echo Mirja and Spencer's question about the "empty" security
> > considerations.  (I actually don't much care for the "This memo introduces no
> > new security considerations" formulation in general, unless it's literally the
> > only content of the section -- it's either followed by new security
> > considerations, in which it's just wrong, or followed by calling out specific
> > portions of the referenced security considerations that are particularly
> > relevant.  In the latter case, it seems useful to provide more of a lead-in
> > like "The general security considerations of [X] and[Y] apply, and in
> > particular [...]".)
> 
> The most recent version (-06) submitted yesterday now has some text in
> the Security Considerations section:
> 
> https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-5
> 
> I hope it addresses your question.

Oh! I was actually looking at the -06, but hadn't noticed how new it was
(and thus that the previous comments referred to a much more empty security
considerations section).

I'd suggest dropping "This memo introduces no new security considerations."
and starting off with something like "This memo describes a way to use
existing Router Advertisements ([RFC4861]) and SLAAC ([RFC4862]
mechansisms, and the security considerations for those technologies
continue to apply.  The types of message flows described in this memo could
allow an attacker who is able to send a rogue RA to deprecate IPv6
addresses on hosts or [...]".

> > Unfortunately, I don't seem to be in a good position to comment on actual
> > additions to the security considerations section, since I don't have a clear
> > picture of what the proposal in this document actually changes when compared to
> > current/normal practices.  This is presumably just a matter of my lacking the
> > appropriate background knowledge for the routing bits, but in a scenario like
> > Figure 3, with distinct edge and first-hop routers, what kind of RAs would the
> > first-hop routers normally be sending?  Would they be announcing the routes in
> > question here just without the PIO markings, or not advertising anything at
> > all, or something else?
> 
> Normally the first-hop routers are sending RAs which contain PIOs for
> the prefixes configured in the network.
> If the preferred-lifetime is not explicitly specified in the
> configuration by the administrator, those prefixes would have
> the default value of lifetime (7 days). Or any other value explicitly
> configured on the router (e.g. to deprecate a prefix for
> renumbering/if the wrong
> prefix has been configured, I have to edit routers configuration and
> set "prefix 2001:db8:1::/54 preferred-lifetime 0").

Okay, so it sounds like the "new information" here is to conceptually tie
the uplink status together with the RA preferred_lifetime fields, along
with the policy implications on the routers themselves.  The coverage added
in the -06 seems to be enough, then.

Thanks for the (quick) reply and clarifications!

-Benjamin