RE: Route Information Options in Redirect Messages (updated)

[Mark Smith <[e-mail]>]

Hi Fred,

On 9 Feb. 2017 08:37, "Templin, Fred L" <[e-mail]> wrote:

Hi Mark,

> -----Original Message-----
> From: Mark Smith [mailto:[e-mail]]
> Sent: Wednesday, February 08, 2017 1:06 PM
> To: Templin, Fred L <[e-mail]>
> Cc: james woodyatt <[e-mail]>; 神明達哉 <[e-mail]>; 6man WG <
[e-mail]>
> Subject: Re: Route Information Options in Redirect Messages (updated)
>
> Hi Fred,
>
> On 9 February 2017 at 07:33, Templin, Fred L <[e-mail]>
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.)


Regards,
Mark.



Thanks - Fred
[e-mail]

> Regards,
> Mark.