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

[james woodyatt <[e-mail]>]

On Jan 9, 2017, at 11:53, Templin, Fred L <[e-mail]> wrote:
> On Monday, January 09, 2017 11:02 AM, james woodyatt <[e-mail]> 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.

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.

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.

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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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].


--james woodyatt <[e-mail]>