Subject: Route Information Options in IPv6 Neighbor Discovery

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Apr 2017 21:34:40 +0000

Please see below for an updated version of "Route Information Options
in IPv6 Neighbor Discovery". Note that the title is changed since the last
version because we are now allowing RIOs to appear in other IPv6 ND
messages besides just Redirects. In particular, we are now allowing RIOs to
also appear in Neighbor Solicitation (NS) and Advertisement (NA) messages.

The rationale for leveraging NS/NA instead of RS/RA is given in Section 4.2.6.
The rest of document was updated to address the helpful input received
from colleagues at IETF98. Please review and post comments to the list
and/or the authors.

Fred and James

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, April 06, 2017 4:25 PM
To: [email-masked]
Subject: I-D Action: draft-templin-6man-rio-redirect-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Route Information Options in IPv6 Neighbor Discovery
        Authors         : Fred L. Templin
                          James Woodyatt
	Filename        : draft-templin-6man-rio-redirect-02.txt
	Pages           : 12
	Date            : 2017-04-06

Abstract:
   The IPv6 Neighbor Discovery protocol provides a Redirect function
   allowing routers to inform recipients of a better next hop neighbor
   on the link toward the destination, and a Neighbor Solicitation (NS)
   function allowing nodes to solicit a Neighbor Advertisement (NA)
   response from the neighbor.  This document specifies backward-
   compatible extensions to Redirect, NS and NA messages to support the
   discovery of more-specific routes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-6man-rio-redirect/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-6man-rio-redirect-02
https://datatracker.ietf.org/doc/html/draft-templin-6man-rio-redirect-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-templin-6man-rio-redirect-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Apr 2017 13:56:21 +0200 (CEST)

> from colleagues at IETF98. Please review and post comments to the list

SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine would 
be in scope for this documents security section. For instance, what would 
an SAVI enabled L2 switch that inspects ND entries do when it sees this 
RIO entry in ND?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Apr 2017 15:23:30 +0000

Hi Mikael,

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Friday, April 14, 2017 4:56 AM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]; james woodyatt <[email-masked]>; Dave Thaler <[email-masked]>
> Subject: Re: Route Information Options in IPv6 Neighbor Discovery
> 
> be in scope for this documents security section.

Can you send a pointer to the document?

> For instance, what would

I would have to look, but if the document says that the switch
should throw away ND messages with options other than those
specified in RFC4861 that sort of defeats the extensibility of IPv6
ND in general, doesn't it?

Thanks - Fred
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Apr 2017 11:03:16 -0700

> On Apr 14, 2017, at 4:56 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine would be in scope for this documents security section. For instance, what would an SAVI enabled L2 switch that inspects ND entries do when it sees this RIO entry in ND?

As specified, I think it would ignore them. It looks at the NA to determine what {IP address, MAC address} or {IP address, MAC address, Port #} association it should enforce. It has no illusion that this is the only data present.

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Apr 2017 11:04:06 -0700

> On Apr 14, 2017, at 8:23 AM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Mikael,
> 

https://tools.ietf.org/html/rfc6620
6620 FCFS SAVI: First-Come, First-Served Source Address Validation
     Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M.
     Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=84010 bytes)
     (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620)

https://tools.ietf.org/html/rfc6959
6959 Source Address Validation Improvement (SAVI) Threat Scope. D.
     McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=62217 bytes)
     (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959)

https://tools.ietf.org/html/rfc7039
7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J.
     Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format:
     TXT=31946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039)

https://tools.ietf.org/html/rfc7219
7219 SEcure Neighbor Discovery (SEND) Source Address Validation
     Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014.
     (Format: TXT=90423 bytes) (Status: PROPOSED STANDARD) (DOI:
     10.17487/RFC7219)

https://tools.ietf.org/html/rfc7513
7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J.
     Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=123735 bytes)
     (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513)

https://tools.ietf.org/html/rfc8074
8074 Source Address Validation Improvement (SAVI) for Mixed Address
     Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E.
     Levy-Abegnoli, Ed.. February 2017. (Format: TXT=23910 bytes)
     (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Apr 2017 06:43:49 +0200 (CEST)

On Fri, 14 Apr 2017, Fred Baker wrote:

> As specified, I think it would ignore them. It looks at the NA to 
> determine what {IP address, MAC address} or {IP address, MAC address, 
> Port #} association it should enforce. It has no illusion that this is 
> the only data present.

So the question becomes, is this desired behaviour? Sounds to me that 
there needs to be SAVI document enhancement for this RIO in ND then, for 
things to continue functioning properly (as I imagine if something sends 
RIO in ND to somewhere, there is expectation that any antispoofing device 
should allow for return traffic as well).

---

From: Fred Baker <[email-masked]>
Date: Sun, 16 Apr 2017 23:19:16 -0700

> On Apr 16, 2017, at 9:43 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> So the question becomes, is this desired behaviour? Sounds to me that there needs to be SAVI document enhancement for this RIO in ND then, for things to continue functioning properly (as I imagine if something sends RIO in ND to somewhere, there is expectation that any antispoofing device should allow for return traffic as well).

Please feel free to make specific suggestions.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Apr 2017 23:47:01 +0000

I have a question on how SAVI interacts with the IPv6 Redirect function in general.
When a Router Redirects a Source to a Target, the Source has discovered something
that it did not know before, namely that a target IPv6 prefix is reachable via the
Target directly without having to go through the Router.

Armed with this knowledge however, what is to stop the Source from sending packets
with spoofed IPv6 source addresses via the Target? And, this is an issue for standard
IPv6 Redirect for a singleton destination and not just for Redirects that include RIOs.

That said, there is a way for the Source to tell the Target about the source address(es)
it intends to use by including the source addresses or prefixes in RIOs in a NS sent
to the Target before any data packets are sent. And, if the Source lies about any of
its addresses any SAVI L2 devices that examine the NS messages can drop them.

Thanks - Fred 

> From: Fred Baker [mailto:[email-masked]]
> Sent: Sunday, April 16, 2017 11:19 PM
> To: Mikael Abrahamsson <[email-masked]>
> Cc: Templin, Fred L <[email-masked]>; james woodyatt <[email-masked]>; [email-masked]; Dave Thaler
> <[email-masked]>
> >>> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine would be in scope for this documents security section. For
> instance, what would an SAVI enabled L2 switch that inspects ND entries do when it sees this RIO entry in ND?
> >>
> >> As specified, I think it would ignore them. It looks at the NA to determine what {IP address, MAC address} or {IP address, MAC
> address, Port #} association it should enforce. It has no illusion that this is the only data present.
> >
> > So the question becomes, is this desired behaviour? Sounds to me that there needs to be SAVI document enhancement for this RIO
> in ND then, for things to continue functioning properly (as I imagine if something sends RIO in ND to somewhere, there is expectation
> that any antispoofing device should allow for return traffic as well).
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Apr 2017 17:41:55 -0700

We have essentially the same problem with IPv4 Source Guard, as several companies call the technology. It has been deployed since 2004 or thereabouts as proprietary technology, but operates essentially as SAVI/DHCP does. We don't observe the issue you raise.

A redirect in essence is router A telling some host that router B in the same subnet that would be a better choice - that router A's next hop for the indicated address is router B, and the host can be a good citizen by sending that traffic to B in the first place. If they're in the same subnet and the host can talk with both of them, the host is going to use the same source address and the same interface. SAVI is thrilled, and if the host does as it is told, we reduced message rate on the LAN a little bit.

Further discussion of SAVI should probably go to [email-masked]...

> On Apr 17, 2017, at 4:47 PM, Templin, Fred L <[email-masked]> wrote:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Apr 2017 01:07:22 +0000

Hi Fred,

> Sent: Monday, April 17, 2017 5:42 PM
> Cc: Mikael Abrahamsson <[email-masked]>; james woodyatt <[email-masked]>; [email-masked]; Dave Thaler
> <[email-masked]>
> We have essentially the same problem with IPv4 Source Guard, as several companies call the technology. It has been deployed since
> 2004 or thereabouts as proprietary technology, but operates essentially as SAVI/DHCP does. We don't observe the issue you raise.
> 
> A redirect in essence is router A telling some host that router B in the same subnet that would be a better choice - that router A's next
> hop for the indicated address is router B, and the host can be a good citizen by sending that traffic to B in the first place. If they're in
> the same subnet and the host can talk with both of them, the host is going to use the same source address and the same interface.
> SAVI is thrilled, and if the host does as it is told, we reduced message rate on the LAN a little bit.

The issue is what happens if, after the redirection, the Source (what you are calling the
"host") starts sending packets with IPv6 source addresses other than the one(s) it has
configured from an on-link prefix. The Target (what you are calling "router B") would
have no way of knowing what IPv6 source addresses are allowed to emanate from
the Source. What I am suggesting is that the Source could first tell the Target about
the source addresses/prefixes it is authorized to use by sending the Target an NS
message, and any L2 SAVI gear can simply drop the message if the Source lies.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Apr 2017 20:42:53 +0000

Hi Fred,

A comment about SAVI/DHCP. RFC7513 seems to suggest DHCP snooping, i.e.,
some device on the path from the DHCP server to client examines the contents
of DHCP messages. Unfortunately, the DHCPv6 Security specification mandates
the use of encryption:

https://www.ietf.org/id/draft-ietf-dhc-sedhcpv6-21.txt

Does it mean that Secure DHCPv6 will be incompatible with SAVI?

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Apr 2017 13:46:42 -0700

> On Apr 18, 2017, at 1:42 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Fred,
> 

Great question for [email-masked].