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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 01 Aug 2018 19:26:56 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-v6ops-conditional-ras-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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 [...]".)

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?

Other than that, thanks for the well-written document!

---

From: Jen Linkova <[email-masked]>
Date: Thu, 2 Aug 2018 12:50:46 +1000

Hi Benjamin,

> like "The general security considerations of [X] and[Y] apply, and in

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.

> question here just without the PIO markings, or not advertising anything at

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").

-- 
SY, Jen Linkova aka Furry

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Aug 2018 22:18:06 -0500

Thanks for the updates, Jen.  [inline]

> 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 [...]".

> 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