RE: Route Information Options in Redirect Messages (updated)

"Templin, Fred L" <> Wed, 08 February 2017 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B7B012A053 for <>; Wed, 8 Feb 2017 14:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aMiqowfon38R for <>; Wed, 8 Feb 2017 14:34:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 301BA129E5B for <>; Wed, 8 Feb 2017 14:34:08 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v18MY7nW038553; Wed, 8 Feb 2017 15:34:07 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v18MY41S038176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 8 Feb 2017 15:34:04 -0700
Received: from (2002:8988:eede::8988:eede) by (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Feb 2017 14:34:03 -0800
Received: from ([]) by ([]) with mapi id 15.00.1178.000; Wed, 8 Feb 2017 14:34:03 -0800
From: "Templin, Fred L" <>
To: Mark Smith <>
Subject: RE: Route Information Options in Redirect Messages (updated)
Thread-Topic: Route Information Options in Redirect Messages (updated)
Date: Wed, 8 Feb 2017 22:34:03 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_95cf0e37ab8b49caba6141a9084e583dXCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
Cc: james woodyatt <>, 6man WG <>, =?utf-8?B?56We5piO6YGU5ZOJ?= <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Feb 2017 22:34:11 -0000

Hi Mark,

I have always understood turning someone’s plaintext message into hypertext as
an unfriendly act in these list discussion. Effective inline-ing is no longer possible.
Top-posting is the only option.

That said, I will go back to what I was saying before – the scenario for a redirected
prefix is no different than for a redirected singleton address, where an untrustworthy
first-hop router could redirect a client to a victim target. This is a matter for discussion
in security considerations – it is not justification for instrumenting an overly-restrictive
validity check that would limit applicability in use cases where the threat does not apply.

Thanks - Fred

From: Mark Smith []
Sent: Wednesday, February 08, 2017 2:11 PM
To: Templin, Fred L <>
Cc: james woodyatt <>om>; 神明達哉 <>jp>; 6man WG <>
Subject: RE: Route Information Options in Redirect Messages (updated)

Hi Fred,

On 9 Feb. 2017 08:37, "Templin, Fred L" <<>> wrote:
Hi Mark,

> -----Original Message-----
> From: Mark Smith [<>]
> Sent: Wednesday, February 08, 2017 1:06 PM
> To: Templin, Fred L <<>>
> Cc: james woodyatt <<>>; 神明達哉 <<>>; 6man WG <<>>
> Subject: Re: Route Information Options in Redirect Messages (updated)
> Hi Fred,
> On 9 February 2017 at 07:33, Templin, Fred L <<>> wrote:
> > Hi Mark,
> >
> > What you are digging into here is out of scope for this document in the same
> > way that orchestrating redirects for singleton destinations is out of scope for
> > RFC4861.
> What RFC covers redirects? RFC4443 doesn't.
No, I am only talking about RFC4861.

I'm afraid I don't still don't understand what you're saying.

This mechanism is, at face value, nothing more than a single message carrying a redirect for a range of addresses.

However, because it can carry a range of addresses, it may be useful in other contexts where single address redirects are either or nearly worthless. For example, RFC4861 explicitly prohibits routers from processing single address redirects, so there is no point sending them to routers.

I think one of those scenarios where a prefix redirect would be useful (but a single address redirect isn't) is a router control plane client/server relationship, where this mechanism operates following the same model as the Next Hop Resolution Protocol does - the server router instructs the client routers to establish more direct paths between themselves across the shared multi-access link, but the client routers do not make those shorter path decisions. If they did, they would be control plane peers, not clients.

The validation rule you're describing allows the client routers to make their own best path choices, which means the server router has lost its ability to be the single decision maker and the single source of truth.

> >  All it says in the validation checks is:
> >
> >   - The IP source address of the Redirect is the same as the current first-hop
> >      router for the specified ICMP Destination Address.
> >
> > It does not say anything about how all of the potential first-hop routers on
> > the link coordinate among themselves to make sure that the Redirects don't
> > steer hosts into a rat's nest of endless loops.
> >
> > Yes, just the same as for redirects of singleton destinations, there is an
> > implied trust basis that routers that send Redirects will behave truthfully
> > and consistently. It is no different for Redirects that contain RIOs.
> >
> Then my use case is not a use case for this. I have to provide
> services to stub routers, but cannot trust them to act entirely
> benevolently, because I don't own, operate or even have much influence
> over what brand they are. I want to provide a the best and possibly
> better service to them because their owners are paying me to e.g.,
> local layer 2 switching in the exchange, but I cannot let one customer
> impact the service of any other customer.
OK, but then that sounds like either a different document or a Security
Considerations note for this document. But, the mainline validity check
needs to stay generic.

It seems to me that the default validity check needs to be the one that provides the most robustness, which usually means the default setting needs to suit the likely deployment environment it will be deployed in.

In my scenario, if you trusted and operated all of the routers, you could run a dynamic IGP on them to provide optimal path information to them. A new mechanism like a prefix redirect is an alternative to existing mechanisms in this scenario.

If you can't trust the routers, then you either provide them with a default route (either they configure statically or you provide via RAs) or run BGP with them, which has all the policy knobs necessary to provide and receive routing information securely. BGP of course isn't scalable to residential broadband.

The latter case is the most common, in the order of 100s of millions of instances around the world. So I think the default validation for these sorts of messages for stub routers should suit that scenario (requiring non-technical users to switch on increased security features just doesn't work.)


Thanks - Fred<>

> Regards,
> Mark.