questions / comments on draft-kohno-ipv6-prefixlen-p2p-02

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Sat, 31 July 2010 02:58 UTC

Date: Sat, 31 Jul 2010 12:29:58 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: ipv6@ietf.org
Subject: questions / comments on draft-kohno-ipv6-prefixlen-p2p-02
Message-ID: <20100731122958.6dee4c79@opy.nosense.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: list

Hi,

I've read through this update to the draft, and have a few questions /
comments.


o  Ethernet point-to-point links

"  This may include Ethernet links which are configured to be point-to-
   point.  In such cases, there is no need to support Neighbor Discovery
   for address resolution, and other general scenarios like the use of
   stateless addresss autoconfiguration are not relevant."

If the second sentence applies to the Ethernet scenario, then how do
the routers on each of this link know what destination MAC address to
put in the Ethernet frames?

It would seem to me that there are at least three possible options:

- static configuration of destination MAC addresses

Impractical IMHO for the operational overhead it creates (error prone
including typos, breaks if interface module is changed etc., chances
of these errors go up if the changes are occurring in the early hours
of the morning)

- Enabling ND NS/NA for destination MAC address discovery

with a /127 prefix length, the neighbor cache exhaustion attack has
been mitigated, so I don't think there is any harm in having ND NS/NA
occur on these links. It also allows ICMP Destination Unreachables to
be generated if the remote IPv6 address becomes unavailable

- Switch off link layer address recognition on the Ethernet interfaces
  a.k.a. "promiscuous mode".

This would make the Ethernet link a true layer 2 point-to-point link.
A neat trick might be to re-purpose the address fields in the Ethernet
headers to carry different information e.g. MPLS label stack, similar
to how DLCIs were re-purposed in MPLS over frame relay.


o  Link local addressing

Are link local addresses required on this link? How is it generated,
and what is its prefix length?


o  Generating ICMP Destination Unreachables

As mentioned earlier, one of the consequences of using a /127 is that
the ND neighbor cache is now not vulnerable to exhaustion DoS attacks,
because the address space assigned to the link is so small. Wouldn't it
be better to switch NS/NA/NUD back on for these links (i.e. all p2p, not
just Ethernet), so that they can now generate ICMP Destination
Unreachables, which is a MUST according to RFC4861?


o  Applicability to customer PPP p2p links

How can /127s be applied to customer PPP/PPPoE point-to-point links.
They're just as vulnerable to the issues this draft is addressing, and
as there's likely going to be many magnitudes more of them compared to
SONET/SDH/Ethernet point-to-point links between routers upstream of the
network edge, they'll also possibly be a large target for attackers. As
an example, I'm working on a scenario where there are probably no more
than 200 to 300 inter-router point-to-point links upstream of the
network edge, but there are over 150K+ PPP sessions attaching customers
to that network. Being able to protect those 150K+ PPP sessions from
these issues would be very valuable.


Regards,
Mark.

questions / comments on draft-kohno-ipv6-prefixle… Mark Smith