Re: Route Information Options in Redirect Messages (updated)

[Mark Smith <[e-mail]>]

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, and have
another couple of use cases. I'd be interested in being a co-author.

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

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.

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.

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.

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.

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


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.

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

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.

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.

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 think that is it for the moment.

Regards,
Mark.