[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: router-selection comments

Hi Pekka, 

Thanks for the comments on the router-selection draft.
I've acted on all your comments except one, and it would be great if you
could suggest specific text on that one.  See below.

http://www.icir.org/dthaler/RouterSelectionIssues.htm is the issues
tracker which also contains a pointer to the current draft -04 in

Pekka Savola wrote:
> Thanks for the update.  I think this is in pretty good shape,
> wise,
> and should be shipped ASAP.  Especially, please work on getting those
> types reserved, the ones currently used by implementations have been
> already for other applications!
> substantial
> -----------
>    If there are no routes matching the destination (i.e., no default
>    routes and no more-specific routes), then if a type C host has a
>    single interface then it SHOULD assume the destination is on-link
>    that interface. If the type C host has multiple interfaces then it
>    SHOULD discard the packet and report a Destination Unreachable / No
>    Route To Destination error to the upper layer.
> ==> this "onlink-by-default" rule has big problems, and it has been
> removed
> in rfc2461bis -- I think it should be removed from here as well, or at
> least
> reworded.  Additionally, there doesn't appear to be anything
> router-selection specific here.

(Entered as Issue 11)
Removed the on-link assumption as suggested.

> 3.5. Router Reachability Probing
> ==> as a preface, one should IMHO discuss how this relates to the
> reachability probing of RFC2461.  As far as I see, the only difference
> here
> is that that unreachable, preferable routers are explicitly being
> to
> notice when they become reachable again -- while with vanilla RFC2461
> doesn't matter as all the routers are equally preferable.

(Entered as Issue 14)
Correct. Added text to point this out explicitly.

> 5.1. Best Router for ::/0 vs Router Least Likely to Redirect
> ==> I think these examples show, that if you don't know which type of
> nodes
> (A, B vs C) there exist in the network, the optimal network
> can be a very delicate process.
> This should be explicitly called out somewhere.  

(Entered as Issue 15)
Can you suggest specific text you would like to see?

> Another approach might be
> "disallowing" type B hosts, requiring full router-selection
> implementation,
> which would simplify the types and the configuration quite a bit.

We don't think this change is warranted at this point.  Changing an
implementation from type A to type B is a relatively minor change,
whereas changing from type A to type C is a much larger change.

> 6. Security Considerations
>    A malicious node could send Router Advertisement messages,
>    specifying High Default Router Preference or carrying specific
>    routes, with the effect of pulling traffic away from legitimate
>    routers. However, a malicious node could easily achieve this same
>    effect in other ways. For example, it could fabricate Router
>    Advertisement messages with zero Router Lifetime from the other
>    routers, causing hosts to stop using the other routes. Hence, this
>    document has no new appreciable impact on Internet infrastructure
>    security.
> ==> this is inaccurate.  There is a significant difference between a
> blackhole attack, and a redirection attack.  Redirection can e.g., be
> trivial way to mount MITM attacks.  This draft actually makes it even
> easier. This needs to be explained better in this memo, with
> pointers to SEND stuff.

(Entered as Issue 12)
We don't see how the actual effect is any worse, but this doc does make
it easier to hide what you're doing by narrowing the attack to only a
specific prefix rather than the entire default route.  Added text to
point this out and point to SEND stuff.

> editorial
> ---------
(Entered as Issue 13)
All editorial fixes were made as proposed.


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6