RE: Route Information Options in Redirect Messages (updated)

["Templin, Fred L" <[e-mail]>]

Hi Mark,

> -----Original Message-----
> From: Mark Smith [mailto:[e-mail]]
> Sent: Saturday, February 04, 2017 5:41 PM
> To: Templin, Fred L <[e-mail]>
> Cc: IPv6 List <[e-mail]>; james woodyatt <[e-mail]>
> Subject: Re: Route Information Options in Redirect Messages (updated)
> 
> Hi Fred, James,
> 
> On 1 February 2017 at 10:14, Templin, Fred L <[e-mail]> wrote:
> > An updated version of "Route Information Options in Redirect Messages" is now
> > available (see below). This version addresses 6man list comments posted in the
> > 1/9/2017 - 1/12/2017 timeframe, and re-aligns the work from intarea to 6man.
> > It also expands on several aspects of the proposal that were not covered in the
> > intarea draft. Please (re-)review and post comments to the list.
> >
> > Fred and James
> >
> 
> I had an idea for this sort for thing a few years ago,

This idea is indeed not new, and has already been published in a string of
informational and experimental RFCs (RFC5558, RFC5720, RFC6179, RFC6706).
RFC6706 in particular shows the inclusion of RIOs in Redirects.

> and have another couple of use cases.

That is good. We think there will be lots of additional use cases.

> I'd be interested in being a co-author.

Thanks for offering your services; James and I will discuss it.

> Firstly, I think a more user friendly name for it could be a "Prefix Redirect".

It sounds nice, but could morph into the term "Predirect" which is already
used for a different purpose in RFC6706. We could still consider it as
inline text in the draft, but I would not be in favor of its use in the title.

> The first use case is the Next Hop Resolution Protocol scenario, where
> there are a set of routers on a mutli-access link, however they're not
> running a dynamic routing protocol between themselves. There is a
> primary router that has knowledge of all other routers and the
> prefixes behind them in the link, and secondary routers that only have
> knowledge of the primary router to which they default route. When the
> primary router knows that secondary router is sending traffic to
> another secondary router on the same link, it sends a "prefix
> redirect" to the first secondary router, establishing a more direct
> path over the multi-access layer 2 link.

Yes. That is exactly the NBMA link model that has been established in
the RFCs I cited above and carries forward into 'draft-templin-aerolink'.
So, I agree with the scenario.

> The more specific example of this use case I was thinking of was an
> ADSL broadband scenario common here in .au, where in the telephone
> exchanges (C.O.s in US terminology), customer ADSL traffic is
> aggregated at layer 2 (Ethernet), and then switched between
> subscribers attached to the same exchange by an off-site BRAS, with
> that inter-subscriber traffic having to traverse the backhaul link to
> the BRAS twice.

Sounds good to me, and more use cases like this are welcome.

> In this scenario a "prefix redirect" sent to the customer RGs would
> allow the intra-exchange traffic to stay local rather than traversing
> the backhaul link. This could also be more useful if there is a CDN
> subnet present in the exchange, allowing the RGs to send and receive
> traffic directly to/from the CDN over the intra-exchange network,
> further keeping traffic local to the exchange. There are some security
> issues here, however if they are overcome, it could be very beneficial
> to keep intra-exchange traffic local, as backhaul and BRAS resources
> are comparatively quite expensive compared to intra-exchange layer 2
> aggregation resources.

Keeping the intra-exchange traffic local is the right idea, and not only
provides a more direct path but also reduces the load on critical network
infrastructure.

> The other use case, which I think is likely the one the in mind when
> the draft was written was delegation of prefixes to individual hosts,
> so that inter-host traffic is direct between hosts rather than via the
> hosts' default router. I think referring to RFC7934 would be useful
> for this case.

This idea has been around in 'draft-templin-aerolink' and its predecessor
RFCs (RFC5558, RFC5720, RFC6179, RFC6706) for many years. I mentioned
this to the RFC7934 authors before its publication but was rebuffed.

> Specific to sections of the draft:
> 
> 1.  Introduction
> 
> I think describing these sorts of messages as a "hint" can be a good
> way to convey the concept. e.g.,
> 
> 'Routers sending these redirect messages are providing a "hint" to the
> recipient about an alternate and more optimal forwarding path to the
> destinations covered by the prefix. The recipient can ignore this
> hint. Sending of traffic by the recipient should still be successful,
> although less optimal."

While I agree with you, I wonder if anything needs to be said in the
draft since RFC4861 already says:

"  A router MUST limit the rate at which Redirect messages are sent, in
   order to limit the bandwidth and processing costs incurred by the
   Redirect messages when the source does not correctly respond to the
   Redirects, or the source chooses to ignore unauthenticated Redirect
   messages.  More details on the rate-limiting of ICMP error messages
   can be found in [ICMPv6]."

This (sort of) permits sources to ignore redirects, which could in
essence mean that the source can interpret redirects as a hint.
But, if you think our draft should say more we could consider it.

> 3.1.  Validation of Redirect Messages
> 
> When thinking about the ADSL scenario above, I'd thought that the RGs
> should only be accepting "prefix redirect" messages from known default
> router(s), learned via RAs or static configuration. As long as bogus
> RAs are prevented from being spoofed on the link, which is necessary
> in an untrusted broadband environment, this would prevent unauthorised
> traffic redirection.

We talk about trust in security considerations. But, note that not only
the default router but also the "current first-hop router" could send
redirects.

> RFC4861 does to a level of of this sort of validation for single
> address redirects:
> 
> "The IP source address of the Redirect is the same as the current
>         first-hop router for the specified ICMP Destination Address."
> 
> however I don't think it is enough validation for these "prefix redirects".

We say more about this in security considerations.

> A scenario would be that the BRAS sends a "prefix redirect" to RG A
> for RGB's /56. RG B would now be the next hop for the /56, and
> therefore RG B could send a "prefix redirect" to RG A for a /57 (or
> two "prefix redirects" for the two /57s covering the /56), causing RG
> A to now send that traffic where ever RG B wanted it to be sent,
> rather than to where the BRAS directed RG A to send it.

RG B could certainly redirect RG A to RG C, that is true. And, if there
is a chance that RG B is being untruthful then RG A should ignore the
messages. Again, the place to discuss this is in security considerations.

> So I think the validations for a single address redirect in RFC4861
> apply, except that "prefix redirects" should only be accepted from a
> default router, learned via an RA or static configuration.

It depends on the security scenario. If routers on the link can truly trust
each other, then it should be OK for RG B to redirect A to C. If some other
form of trust enforcement is needed (e.g., SEND) then so be it.

But, the security considerations for a redirected prefix vs. a redirected
address are one and the same. If there is any chance of spoofing, then
accepting a spoofed redirect would lead to corruption in either case.
In other words, it is never OK to accept a spoofed redirect whether
it only includes a singleton destination address or an entire prefix.

> 3.3.  Host Specification
> 
> I think it would be worth mentioning that in the ADSL/RG scenario
> above (if included), the RGs are acting as a host on their WAN
> interface and that processing of these "prefix redirects" is occurring
> for the same reason that RGs process RAs, as per the W-3 requirement
> in RFC7084.

I like this citation, and agree it would be worth adding.

> I think that is it for the moment.

Thanks for these very helpful comments!

Fred

> Regards,
> Mark.