RE: Route Information Options in Redirect Messages (updated)

Hi Lorenzo – see below for responses:

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Sunday, February 05, 2017 5:27 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: IPv6 List <ipv6@ietf.org>; james woodyatt <jhw@google.com>
Subject: Re: Route Information Options in Redirect Messages (updated)

I'm not sure about the security reliability and reliability of this scheme. The first things that come to mind are:

What happens if the whole network is renumbered? Fundamentally, the entity that is authoritative for the larger prefix (i.e., the one sending the prefix redirect) is the one that controls routing to that prefix. What happens if that entity realizes that the prefix is no longer valid, and that thus the sub-prefixes are also no longer redirected? How does it withdraw those redirects?

FLT>>> The renumbering event itself would be no different than renumbering for
FLT>>> any DHCPv6 PD scenario – I guess it would entail a DHCPv6 “reconfigure”
FLT>>> exchange. But, once a prefix is renumbered, there are a couple of ways
FLT>>> that previous redirections could be cancelled. First, the redirection target
FLT>>> could send unsolicited Redirects with Route Lifetimes set to 0 for the
FLT>>> previous prefixes (in which case, the source will again allow future traffic
FLT>>> to flow through a default router). Second, the redirection target can
FLT>>> send “Destination Unreachable” messages to the source, which can then
FLT>>> infer that the redirected routes are no longer valid and delete the
FLT>>> redirected route. Our draft is currently silent on Destination Unreachables,
FLT>>> but ‘draft-templin-aerolink’ talks about them and we could adopt some
FLT>>> of that text.

Second: security. I get the feeling that a lot of work needs to be done here to cover all the corner cases. One obvious example is: suppose I have 2001:db8:1:1:/64 on link, and then some host sends an unsolicited RIO announcing that it is responsible for 2001:db8:1:1:/64, or for both 2001:db8:1:1::/65 and 2001:db8:1:1:8000::/65. What happens? Hopefully the host doesn't get to MITM all the traffic on the link.

FLT>>> Please check the Security Considerations section and let us know if you
FLT>>> have any comments on what appears there. To your point, though, a
FLT>>> Node A having received a prefix redirect with next hop Node B will
FLT>>> never accept a redirect from Node C claiming to own the prefixes
FLT>>> that are legitimately owned by Node B.

Even assuming that a router actually legitimately redirects a sub-prefix to a given node for a certain lifetime, what's to stop that node claiming that sub-prefix even after the original lifetime has expired? Should the host receiving the prefix redirect enforce that the prefix lifetime can never increase?

FLT>>> RIOs include a Route Lifetime which gives a number of seconds before
FLT>>> the prefix expires. If the node that is the owner of the prefix wishes
FLT>>> to extend the Route Lifetimes, it can send unsolicited Redirects to its
FLT>>> (redirected) correspondents. But, once Route Lifetime expires the
FLT>>> correspondent discards the prefix and allows future packets to once
FLT>>> again flow through a default router.

More in general it looks like this document is trying to reinvent a fair amount of stuff that's already covered in detail, and more robustly, in homenet. Why not use those solutions instead?

FLT>>> Please have a look at the use cases. The three that I have mentioned are
FLT>>> 1) enterprise mobile devices (e.g., cellphones, tablets, etc.), 2) Airplanes
FLT>>> in civil aviation networks, and 3) Unmanned Air Vehicles in unmanned
FLT>>> air traffic management networks. Others have mentioned other use
FLT>>> cases, and I think we will find that there are still many others. About
FLT>>> reinventing homenet, I think you would find that these concepts have
FLT>>> been around a lot longer than homenet.
FLT>>>
FLT>>> Thanks - Fred

On Wed, Feb 1, 2017 at 8:14 AM, Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
An updated version of "Route Information Options in Redirect Messages" is now
available (see below). This version addresses 6man list comments posted in the
1/9/2017 - 1/12/2017 timeframe, and re-aligns the work from intarea to 6man.
It also expands on several aspects of the proposal that were not covered in the
intarea draft. Please (re-)review and post comments to the list.

Fred and James

-----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org<mailto:i-d-announce-bounces@ietf.org>] On Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Sent: Monday, January 30, 2017 2:33 PM
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
Subject: I-D Action: draft-templin-6man-rio-redirect-01.txt

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

        Title           : Route Information Options in Redirect Messages
        Authors         : Fred L. Templin
                          James Woodyatt
        Filename        : draft-templin-6man-rio-redirect-01.txt
        Pages           : 7
        Date            : 2017-01-30

Abstract:
   The IPv6 Neighbor Discovery protocol provides a Redirect function
   allowing routers to inform recipients of a better next hop on the
   link toward the destination.  This document specifies a backward-
   compatible extension to the Redirect function to allow routers to
   include routing information that the recipient can associate with the
   next hop.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-templin-6man-rio-redirect-01

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

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<http://tools.ietf.org>.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------