Subject: Route Information Options in Redirect Messages

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Jan 2017 15:51:11 +0000

See below for a new draft that proposes to update RFC4861 and RFC4191 to
permit the inclusion of Route Information Options in Redirect Messages.
This represents a backward-compatible extension to the IPv6 ND Redirect
function. Please review and comment on the list.

Fred
[email-masked]

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 06, 2017 1:52 PM
To: [email-masked]
Subject: I-D Action: draft-templin-intarea-rio-redirect-00.txt

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

        Title           : Route Information Options in Redirect Messages
        Author          : Fred L. Templin
	Filename        : draft-templin-intarea-rio-redirect-00.txt
	Pages           : 5
	Date            : 2017-01-06

Abstract:
   The IPv6 Neighbor Discovery protocol provides a Redirect function
   allowing routers to inform hosts 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 forwarding information that the source can associate with the
   next hop.

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

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

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: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Jan 2017 17:33:10 +0000

Cross-posting onto "int-area" where discussions motivated this work.

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, January 09, 2017 7:51 AM
To: 6man WG <[email-masked]>
Subject: Route Information Options in Redirect Messages

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 06, 2017 1:52 PM
To: [email-masked]
Subject: I-D Action: draft-templin-intarea-rio-redirect-00.txt

Abstract:

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: james woodyatt <[email-masked]>
Date: Mon, 9 Jan 2017 11:02:11 -0800

On Jan 9, 2017, at 07:51, Templin, Fred L <[email-masked]> wrote:
> <https://tools.ietf.org/html/draft-templin-intarea-rio-redirect>

p1. I’m interested to see what V6OPS will think of this.

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

--james woodyatt <[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Jan 2017 19:53:36 +0000

Hi James,

> From: Int-area [mailto:[email-masked]] On Behalf Of james woodyatt
> Sent: Monday, January 09, 2017 11:02 AM
> To: 6man WG <[email-masked]>; INT Area <[email-masked]>
> Subject: Re: [Int-area] Route Information Options in Redirect Messages
> 

If the concern is for backwards compatibility with legacy deployments,  the
proposal honors backwards compatibility per RFC4861. What do you think?

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

Thanks - Fred

> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jan 2017 11:08:20 +1300

Fred,

Can you check that there would be no adverse interaction with RFC8028,
especially https://tools.ietf.org/html/rfc8028#section-3.4

Regards
   Brian

On 10/01/2017 04:51, Templin, Fred L wrote:
> .

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Jan 2017 17:55:10 +0000

Hi Brian,

I am looking at the section that says:

"3.4.  Redirects
   There is potential for adverse interaction with any off-link Redirect
   (Redirect for a destination that is not on-link) message sent by a
   router in accordance with Section 8 of [RFC4861].  Hosts SHOULD apply
   off-link redirects only for the specific pair of source and
   destination addresses concerned, so the host's Destination Cache
   might need to contain appropriate source-specific entries.  This
   extends the validity check specified in Section 8.1 of [RFC4861]."

What is being proposed in the document I submitted is the inclusion of
RIOs in Redirect messages for a *prefix* that is not on-link, as opposed
to a singleton destination. So, the same SHOULD in the paragraph above
would seem to apply also to prefix redirection the same as for ordinary
destination redirection.

Thanks - Fred

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, January 09, 2017 2:08 PM
> To: Templin, Fred L <[email-masked]>; 6man WG <[email-masked]>
> Subject: Re: Route Information Options in Redirect Messages
> 
> Fred,
>

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 10 Jan 2017 11:34:13 -0800

On Tuesday, January 10, 2017 9:55 AM, Fred Templin wrote:
> ... 

Fred, I am reading the security section of your draft. I think it needs a
bit more work.

Currently, the RIO are only expected in router advertisements. RA are
somewhat special, and there is often specific code in switches to check RA
and prevent RA spoofing -- e.g., RA-Guard. Allowing the option in Redirect
messages could very well bypass the RA specific checks. Doesn't that open
the path for new attacks? Should you not say something about that in the
security section? How about specific mitigations, such as sanity checks when
processing redirect messages?

-- Christian Huitema

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Jan 2017 21:52:56 +0000

Hi Christian,

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2017 11:34 AM
> To: Templin, Fred L <[email-masked]>; 'Brian E Carpenter' <[email-masked]>; '6man WG' <[email-masked]>;
> 'INT Area' <[email-masked]>
> Subject: RE: [Int-area] Route Information Options in Redirect Messages
> 

Since IP will still operate correctly if transmission of Redirect messages is
somehow suppressed (i.e., denial of Redirect service), the more serious
threat to be considered is spoofing. Here is what currently appears under
Security Considerations:

   "Security considerations for Redirect messages that include RIOs are
   the same as for any IPv6 ND messages as specified in Section 11 of
   [RFC4861].  Namely, the protocol must take measures to secure IPv6 ND
   messages on links where spoofing attacks are possible.

   A spoofed Redirect message containing no RIOs could cause corruption
   in the host's destination cache while a spoofed Redirect message
   containing RIOs could corrupt the host's routing tables.  While the
   latter would seem to be a more onerous result, the possibility for
   corruption is unacceptable in either case."

So, from the first paragraph, we can see that the protocol must take
measures to secure IPv6 ND messages on links where spoofing attacks
are possible. The second paragraph then analyzes the consequences of
what could happen if a spoofing attack were successful and we see that
there are unacceptable negative consequences for both traditional
Redirects and Redirects that include RIOs.

The text stops short of saying that "no Redirects of any kind should be
used on links where spoofing attacks are possible". Would adding a
statement such as this address the concern?

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jan 2017 15:23:55 +1300

> would seem to apply also to prefix redirection the same as for ordinary

I didn't want to bias your reading, but that was my conclusion too. If
correct, maybe your draft needs to cite RFC8028 and augment it accordingly.

Regards
    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Jan 2017 17:14:28 +0000

Hi Brian,

> Sent: Tuesday, January 10, 2017 6:24 PM
> To: Templin, Fred L <[email-masked]>; 6man WG <[email-masked]>; INT Area <[email-masked]>

Yes, certainly it makes sense to cite RFC8028, and the next document version
will do that. Thanks very much for pointing this out.

Fred

---

From: Zied Bouziri <[email-masked]>
Date: Wed, 11 Jan 2017 22:47:46 +0100

Hi Fred
In section 6 :
"Namely, the protocol must take measures to secure IPv6 ND messages on links where spoofing attacks are possible »
By reading this passage, I have the impression that there are links where attack spoofing is possible and others not !
How can we know if this attack is possible or not in a specified link ?
Thank you 
Zied

> Le 10 janv. 2017 à 22:52, Templin, Fred L <[email-masked]> a écrit :
> 
> Hi Christian,
> 

Best Regards, مع تحياتي
Zied BOUZIRI، زياد بوزيري
ISET Charguia, Tunisie
www.bouziri.tn <http://www.bouziri.tn/>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Jan 2017 22:22:23 +0000

Hi Zied,

This is discussed in “IPv6 ND Trust Models and Threats [RFC3756]”. Under Section 4.2.4
it says: “This attack is not a concern if access to the link is restricted to trusted nodes”.
SEND [RFC3971] provides one possible mitigation in other cases.

Thanks - Fred

From: Zied Bouziri [mailto:[email-masked]]
Sent: Wednesday, January 11, 2017 1:48 PM
To: Templin, Fred L <[email-masked]>
Cc: Christian Huitema <[email-masked]>; Brian E Carpenter <[email-masked]>; 6man WG <[email-masked]>; INT Area <[email-masked]>
Subject: Re: [Int-area] Route Information Options in Redirect Messages

Hi Fred
In section 6 :

Le 10 janv. 2017 à 22:52, Templin, Fred L <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Christian,

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Tuesday, January 10, 2017 11:34 AM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; 'Brian E Carpenter' <[email-masked]<mailto:[email-masked]>>; '6man WG' <[email-masked]<mailto:[email-masked]>>;
'INT Area' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Int-area] Route Information Options in Redirect Messages

...

Thanks - Fred
[email-masked]<mailto:[email-masked]>

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

Best Regards, مع تحياتي
Zied BOUZIRI، زياد بوزيري
ISET Charguia, Tunisie
www.bouziri.tn<http://www.bouziri.tn/>

---

From: Tomoyuki Sahara <[email-masked]>
Date: Thu, 12 Jan 2017 16:28:25 +0900

Hi, Fred

> proposal honors backwards compatibility per RFC4861. What do you think?

From the section 3. of the draft:

      "The contents of the Reserved field, and of any unrecognized
      options, MUST be ignored.  Future, backward-compatible changes to
      the protocol may specify the contents of the Reserved field or add
      new options; "

RIO options in Redirect Message are not "unrecognized" options
but are "not specified to be used with Redirect memssages". The
next pragraph in RFC4861 is better text to be quoted:

   The contents of any defined options that are not specified to be used
   with Redirect messages MUST be ignored and the packet processed as
   normal.  The only defined options that may appear are the Target
   Link-Layer Address option and the Redirected Header option.

   ( https://tools.ietf.org/html/rfc4861#page-74 )

Once the draft is published as a RFC, it shall update the second sentence.

Thanks,
Tomoyuki

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jan 2017 15:29:04 +0000

Thank you, Tomoyuki-san. I agree with your observation, and will make the
necessary changes to the draft.

Fred

> From: Tomoyuki Sahara [mailto:[email-masked]]
> Sent: Wednesday, January 11, 2017 11:28 PM
> Cc: 6man WG <[email-masked]>; INT Area <[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 13 Jan 2017 07:46:59 +0100 (CET)

> SEND [RFC3971] provides one possible mitigation in other cases.

Is there anything out there that implements SEND? I see Cisco IOS support, 
quick googling didn't yield anything I found that indicated "widely 
supported". Frankly, I don't even understand how it would work in a 
non-tightly-administrated network, with pre-provisioned cyrptographic 
information.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: [email-masked]
Date: Fri, 13 Jan 2017 08:15:04 +0100 (CET)

> non-tightly-administrated network, with pre-provisioned cyrptographic 

- Juniper, at least in JunOS 15.1 and newer for the MX platform.
- Huawei, at least in VRP 8.100 and newer for the NE40 platform.

Note that I haven't checked in exactly which version it was introduced.

(No, we don't use SEND.)

Steinar Haug, AS2116

---

From: james woodyatt <[email-masked]>
Date: Tue, 17 Jan 2017 17:18:54 -0800

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

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Jan 2017 16:44:06 +0000

Hi James,

> Sent: Tuesday, January 17, 2017 5:19 PM

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.

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Jan 2017 10:18:43 -0800

On Jan 18, 2017, at 08:44, Templin, Fred L <[email-masked]> wrote:
> 
> 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)?

Thank you for inviting me to be a co-author! Yes, I would be happy to accept. Please sign me up.

--james woodyatt <[email-masked] <mailto:[email-masked]>>