RE: Route Information Options in Redirect Messages (updated)

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

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

Thanks - Fred
[e-mail]

> -----Original Message-----
> From: Mark Smith [mailto:[e-mail]]
> Sent: Wednesday, February 08, 2017 12: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 8 Feb. 2017 06:54, "Templin, Fred L" <[e-mail]> wrote:
> 
> Hi Mark,
> 
> 
> 
> > Ø  I think you need to be careful of not effectively reinventing a dynamic routing protocol
> 
> 
> 
> > No, there is no reinvention going on here. The behavior parallels redirects
> 
> > for singleton destination addresses, where Redirects are accepted from the
> 
> > current first-hop router, be it a default or non-default.
> 
> 
> So in my proposed case of a stub router receiving and accepting a
> prefix redirect, that is where there would be more of behaviour
> change, as, per RFC4861,
> 
> A router MUST NOT update its routing tables upon receipt of aRedirect.
> 
> For these stub routers, accepting a prefix redirect from more than
> just a default router is where I think it starts encroaching on the
> functionality of a dynamic routing protocol. It starts being possible
> to have all the stub routers in the set sending each other prefix
> redirects (perhaps maliciously) and ending up with a variety of
> different, possibly random paths across the link, with some of those
> paths creating forwarding loops. Dynamic routing protocols would
> resolve this situation to a single best path as well as eliminating
> forwarding loops. That is the sort of functionality that would be (and
> should be to keep it simple) missing from a simple prefix redirect
> mechanism.
> 
> I think limiting the problem space to that of providing a better entry
> point into the "proper" routing system/forwarding domain for stub
> routers, by only accepting them from default routers learned via RAs
> or static configuration, avoids the possibility of encountering and
> having to mitigate these more complex issues.
> 
> Perhaps that means there needs to be two different validation rules
> for the two different types of devices:
> 
> - for hosts, accept prefix redirects from current first-hop router for
> a destination covered by the prefix
> 
> - for stub routers, only accept prefix redirects from default routers
> 
> with the fundamental distinguisher between the device types being
> whether they forward non-local packets or not, and whether a stub
> router accepts them or not being dependent on whether there is a
> dynamic routing protocol enabled on the prefix redirect receiving
> interface.
> 
> 
> Regards,
> Mark.
> 
> 
> 
> 
> 
> 
> 
> 
> Thanks - Fred
> 
> 
> 
> From: Mark Smith [mailto:[e-mail]]
> Sent: Tuesday, February 07, 2017 11:38 AM
> 
> 
> To: Templin, Fred L <[e-mail]>
> Cc: 6man WG <[e-mail]>; james woodyatt <[e-mail]>; 神明達哉
> <[e-mail]>
> Subject: RE: Route Information Options in Redirect Messages (updated)
> 
> 
> 
> 
> 
> 
> 
> On 8 Feb. 2017 05:43, "Templin, Fred L" <[e-mail]> wrote:
> 
> Hi Jinmei-san,
> 
> <snip>
> >
> > Hmm, maybe I'm so dumb but I'm afraid I still don't understand intent
> > clearly.  Do you mean an operational assumption of this proposal is to
> > use it in a link where RA guard isn't deployed?  If so, it's far
> > better (at least to me) to just say so.
> >
> > BTW, if this proposal keeps the concept of "unsolicited redirect" and
> > also allows the destination address of '::' to bypass the host's
> > validity check of whether it's really the first hop router for the
> > destination,
> 
> No, that is not what we want to have happen. The document doesn't
> say this currently, but we want to retain a revised version of the validity
> check. The revised version of the check would say:
> 
> OLD:
>       - The IP source address of the Redirect is the same as the current
> 
>         first-hop router for the specified ICMP Destination Address.
> 
> NEW:
>       - The IP source address of the Redirect is the same as the current
>         first-hop router for the specified ICMP Destination Address, or
>         (when the ICMP Destination Address is '::') the same as the current
>         first-hop router for the specified RIOs
> 
> Would welcome better wording than this, but we definitely do want
> to retain the validity check. Comments?
> 
> 
> 
> I think you need to be careful of not effectively reinventing a
> dynamic routing protocol that ends up missing the necessary
> capabilities required of one to keep this method simple.
> 
> 
> 
> When I've thought about this sort of capability, I've thought of it as
> a hint from the routing system to the users of the forwarding domain -
> hosts and stub routers (default and connected route only routers,
> possibly with other static routes) - of a better entry point for their
> packets into the forwarding domain.
> 
> 
> 
> In the case of a stub router, if it needs or would benefit from more
> dynamic network information than just a prefix redirect hint, then I
> think that is really saying that the stub router shouldn't be a stub
> router - it needs to be a full and proper participant in the routing
> system (running dynamic routing protocol, discovering and conveying
> network topology information etc.), rather than a user of it via
> default route to the forwarding domain.
> 
> 
> 
> That's why I thought the validation should be that these prefix
> redirects are only accepted from a default router learned via an RA or
> static default router configuration, as a default router has the role
> of offering an entry point into the forwarding domain. It would
> enforce the existing boundary between the devices that are users of
> the forwarding domain, and the devices that are participants in the
> routing system that decide the paths through the forwarding domain.
> 
> 
> 
> Regards,
> 
> Mark.