Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

[Mark Smith <[e-mail]>]

On 26 February 2017 at 07:40, David Farmer <[e-mail]> wrote:
>
>
> On Sat, Feb 25, 2017 at 1:15 PM, Brian E Carpenter
> <[e-mail]> wrote:
>>

> Thinking about this a bit more; I think the non-64 lengths should be
> "OPTIONAL for host implementations of IPv6 to support", "RECOMMENDED for
> router implementations of IPv6 to support", "operational use of /127 subnet
> prefixes for point-to-point router links is RECOMMENDED",

I don't think /127s should be at a level of RECOMMENDED.

They are a way to mitigate a ND cache attack if your implementation is
vulnerable to one.

They are a way to mitigate a ICMP ping-pong attack, however that
requires the /127 prefix length to be configured on both ends of the
link, and that is not a requirement of the IPv6 protocol - there is no
requirement and no checking that all nodes attached to a link have
addresses from the prefix assigned to the link. A link with a /127 on
one end, and just a LL on the other (as could happen on links between
a service provide and a customer if there isn't configuration
discipline), is vulnerable to a ping-pong attack, yet would not be
obviously failing e.g., still deliver 100% successful Internet access
to that customer.

/127 of course prevent things that /64 can provide. For example, just
like hosts, Internet connected routers would benefit from being
protected from unsolicited inbound address scans by having a random
address within a /64 (you can't launch a TCP syn attack against a BGP
speaking router if you can't find it).

I think a RECOMMENDED and therefore default parameter is the one that
should have the greatest chance of interoperability, is the one that
is likely to provide the best security in the least secure
environment, and the one that is making the least functionality or
capability tradeoffs.

In my mind, /127s make too many tradeoffs to mitigate a couple of
attacks for which it may not be necessary or effective if
configuration is not verified as correct.

I think recommending /127s for point-to-point router links also
creates an implicit and unstated constraint that RFC8064
("Recommendation on Stable IPv6 Interface Identifiers") only applies
to hosts. If that is the actual constraint, it should have been stated
in that RFC, and ideally in the title of it.

People of course can use /127s in their own network if they choose to
and are willing to sacrifice the potential benefits to their routers
of not using /64s, because IPv6 supports it per BCP198.

I think making /127s a default recommendation for point-to-point links
is effectively saying that routers have no need for any of the
benefits hosts get from /64s, and I don't think that is the case.

Regards,
Mark.