RE: [Int-area] Route Information Options in Redirect Messages

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 18 January 2017 16:44 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548781294A9; Wed, 18 Jan 2017 08:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JON3uhSaL15q; Wed, 18 Jan 2017 08:44:16 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C81012947A; Wed, 18 Jan 2017 08:44:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v0IGiFfm031602; Wed, 18 Jan 2017 09:44:16 -0700
Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0IGi71v031470 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2017 09:44:07 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 Jan 2017 08:44:06 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Wed, 18 Jan 2017 08:44:06 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: james woodyatt <jhw@google.com>, 6man WG <ipv6@ietf.org>, INT Area <int-area@ietf.org>
Subject: RE: [Int-area] Route Information Options in Redirect Messages
Thread-Topic: [Int-area] Route Information Options in Redirect Messages
Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETogAXiyiAAA9u9DABkA37AAAO+46w
Date: Wed, 18 Jan 2017 16:44:06 +0000
Message-ID: <d4a4753d9a3d41e1bbfb2400283574a4@XCH15-06-08.nw.nos.boeing.com>
References: <b0d15d2e8b3e414abf4e87c60d39e252@XCH15-06-08.nw.nos.boeing.com> <AEE70A51-720C-4957-AA1C-8D213EB366D8@google.com> <d12b5166bf0b41f1b85021f6e1410b16@XCH15-06-08.nw.nos.boeing.com> <C746D8F4-C8EC-445A-BD42-928522590C8A@google.com>
In-Reply-To: <C746D8F4-C8EC-445A-BD42-928522590C8A@google.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jIA9YAZrUxTnYroEw0G-s3BgBX4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 16:44:24 -0000

Hi James,

> -----Original Message-----
> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of james woodyatt
> Sent: Tuesday, January 17, 2017 5:19 PM
> To: 6man WG <ipv6@ietf.org>; INT Area <int-area@ietf.org>
> Subject: Re: [Int-area] Route Information Options in Redirect Messages
> 
> On Jan 9, 2017, at 11:53, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
> > On Monday, January 09, 2017 11:02 AM, james woodyatt <jhw@google.com> wrote:
> >>
> >> p2. Section 3.3, Host Specification says this:
> >>
> >>>>   In light of these considerations, a "Type C" host that receives a
> >>>>   Redirect message containing RIOs adopts the combined behaviors of
> >>>>   both of these specifications.  Namely, the host updates its neighbor
> >>>>   cache entry for the Target and updates its routing table per the
> >>>>   included RIOs.  If the Destination address is not the unspecified
> >>>>   address, the host further updates its destination cache.
> >>>>
> >>>>   Note that "Type A'" and "Type B" hosts ignore any RIOs and process
> >>>>   the Redirect message according to Section 8.3 of [RFC4861].
> >>
> >> And I wonder if you have considered the possibility of a “Type D” host, which in my conception would be capable of *only*
> processing
> >> RIO options that appear in ND Redirect messages and *not* in RA messages.
> >
> > Had not considered that, but I don't see a problem with it. FWIW, the 'Type A/B/C' comes from RFC4191 in case others are
> wondering.
> >
> >> I’m not sure that’s a type of host we want to encourage,
> >> but the idea of its possibility was one of the first things that sprang to mind when I contemplated the reasons why so few Type C
> hosts
> >> are currently deployed in the wild after more than a decade since RFC 4191 was published.
> >
> > I am interested in usage inside of a managed network, and not so much about
> > deployment in the wild. Inside of a managed network, the network administrators
> > could enable this function among the deployed hosts to provide the network with
> > a means to manage routing information for more-specific routes.
> 
> Yes, well, as you might imagine, I’m interested in behavior of commodity hosts on unmanaged networks.

OK, no problem. I agree this document should keep an open mind in terms of
potential use cases.

> As far as I know, the most common types of commodity host implementations are Type B at this point. Yes, I know at least one has a
> configurable option to enable Type C behavior, but Type B is the default, and it’s also rarely changed in managed host configurations
> for mobile workstations and personal devices.
> 
> I believe host implementations have not adopted Type C default behavior because of security concerns on unmanaged networks like
> public Wi-Fi hotspots, where the damage potentially caused by so-called “rogue routers” is already perceived to be unacceptably high.
> The theory being that adding support for processing RIO options would further lower the network costs of mounting such attacks, in
> exchange for a questionably valuable route optimization from hosts to possibly illegitimate routers. I’m not a big fan of this line of
> reasoning, but I’ve often seen it used to counter arguments that adding default Type C behavior would be a good idea.

For RIOs in RA messages, I don't think this would result in a route optimization. In
that case, the RA messages simply provide more-specific routes. But, the next
hop will always be the router that sent the RA, i.e., and not a different router.

> A better argument against RIO options in RA Messages, as far as I’m concerned, is that RA Guard [RFC6105] functions are often
> deployed in L2 switching fabrics, and they’ll drop all the RA Messages from most routers other than the protected default routers,
> which are likely to be the ones advertising more specific routes. With ND Redirect Messages, network operators can still have a
> reasonable assurance that hosts never update their routing tables except at the initiation of one of the legitimate default routers,
> which are protected by RA Guard.
> 
> In light of that, I would suggest defining two new types of behavior, which would permit implementers to continue resisting the
> adoption of Type C by default, yet would allow them to add support for processing RIO options just in ND Redirect messages and not
> RA messages. Call that a Type D host, and call the functional combination Type C+D or something.

OK, that makes sense to me.

> Here is my proposed text for Section 3.3 Host Specification.
> 
> >>> The Host Specification follows Section 8.3 of Neighbor Discovery for IP version 6 (IPv6) [RFC4861], Section 3 of Default Router
> Preferences and More-Specific Routes [RFC4191], and Section 3 of First-Hop Router Selection by Hosts in a Multi-Prefix Network
> [RFC8028]. According to [RFC4861], a host that receives a valid ND Redirect message updates its destination cache per the Destination
> information and its neighbor cache per the Target information. According to [RFC4191], a “Type C” host that receives a valid RA
> message updates its routing table per the RIO elements included in the message. Finally, according to [RFC8028], a “Type C” host
> operating on a Multi-Prefix Network with multiple default routes can make source address selection decisions based on information in
> its route table decorated with information derived from the source of the RIO element.

All sounds good, but use of the word "decorated" seems strange in this context. I
don't have a better suggestion at the moment, though.

> >>> In light of these considerations, this document introduces a new “Type D” behavior for hosts with the same kind of routing table
> as a “Type C” host, but which processes RIO elements in ND Redirect Messages according to this specification instead of RA Messages
> as in RFC 4191. Hosts that process RIO elements in both RA messages and ND Redirect Messages are said to have “Type C+D”
> behavior.

Sounds good.

> >>> In both the “Type D” and “Type C+D” cases, hosts process ND Redirect Messages by updating 1) their neighbor cache per the
> Target information, 2) their destination cache per the Destination information when the Destination Address field is not the
> unspecified address, and 3) their routing tables per any RIO elements present.

Sounds good.

> >>> RIO elements in RA Messages are processed by “Type D” hosts in the same way that “Type B” hosts process them, i.e. by ignoring
> them. In “Type C+D” hosts, RIO elements in RA messages are processed in the same way that “Type C” hosts process them.
> >>>
> >>> In the all the cases where hosts process RIO elements, i.e. in RA Messages or in ND Redirect Messages or in both, hosts MAY
> make source address selection decisions, as in [RFC8028], based on their route tables decorated with information derived from the
> sources of received RIO elements.
> >>>
> >>> The behaviors of “Type A,” “Type B” and “Type C” hosts are not changed by this specification. In particular, they all process ND
> Redirect Messages according to Section 8.3 of [RFC4861].

This all sounds good. How would you feel about having this text show up
in the next draft version (and be included as a co-author)?

Second question - should the next draft version be called: "*-intarea*" or
"*-6man*"?  I am leaning toward the latter because the interest seems to
be coming from this WG.

Thanks - Fred
fred.l.templin@boeing.com

> --james woodyatt <jhw@google.com>
> 
> 
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area