Hi,
I've read through the document, and the problem that it touches is indeed
*very* acute - I've experienced it every time in the large-scale wireless
deployments.
The below is a braindump written as I was reading the doc - I deliberately
left some of the pieces that might have been explained later in the
document, so if you want you might preempt these by adding explicit
forward references.
----------
Overall, after reading the doc:
1) I think address registration introduces a new attack vector (registration
flood). More thoughts on this inline.
2) I think there are a few more "multicast chatter" cases that are missed -
inline.
3) Given that the FHS is a "must" in IPv6 network, if we assume its presence,
I think the protocol may be simplified, and be made more router-centric,
I think there may be a possible optimization which would not involve changing
the end hosts - as I'd guess it'll take a while for the end hosts to
adapt.
Now, I'm using the text from -02 from the below URL, will copypaste anchors
from it and comments interspersing.
http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-nd/?include_text=1
"
joining the network the host does not wait for the Router
Advertisements as the NEAR routers do not perform periodic multicast
RA as per RFC 4861. Instead, the EAH sends a multicast RS to find
out a NEAR router in the network. The RS message is the same as in
RFC 4861.
"
The RS sending mechanism will be resilient, I assume, such that the node does
get RA even in a high-loss environments, right ? Maybe useful to include a
paragraph or two on the unreliability of this mechanism. I think Suresh said he
had something on this, probably worth referencing.
"
The TID field is used together with age of a registration for
arbitration between two routers (default or backbone) to ensure
freshness and ownership of the registration of a given target
address. "
freshness - yes.. ownership - not sure.. seems like I might spoof this value
easily.. ?
" Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only
solicited RAs are RECOMMENDED. An RA MUST"
This is sometime years in the future when there's no legacy IPv6 nodes ?
Especially in context of mobile byod-type networks (e.g. ciscolive net), I
think the router might need to support both. OTOH, the *interval* of the
multicast RAs can be cranked up. This is what I am doing now, and it does
help...
Okay, I see sometime later:
"The efficiency-aware default router MUST not send periodic RA unless
it is configured to support both legacy IPv6 and efficiency-aware
hosts. If the Router is configured for efficiency-aware hosts
support, it MUST send Router Advertisements with E-bit flag ON and
MUST NOT set 'L' bit in the advertisements."
Fair enough. But then if the router configured for interop, do we still send
RAs "relatively frequently" or do we say also to decrease their default
frequency ? Maybe a micro-optimization, not sure. I need to measure this
somehow with existing gear.
"containing Router's link-layer address (this
is optional in [ND]. An RA MUST carry Prefix
information option with L bit being unset, so
that hosts do not multicast any NS messages"
for the routable addresses, yes this solves the problem. But what I noticed
today is this use case:
Bonjour advertising the services using all sorts of addresses, including
link-local addresses. So, then the devices will do ND on link-local addresses,
etc. - so this will solve the problem only partially, I think.
" Unlike RFC4861 which suggests
multicast Router Advertisements, this
specification optimizes the exchange by
always unicasting RAs in response to RS."
Yay! :-) (with my wireless hat on:)
One thing (maybe) to mention is to say that in the final architecture this may
be configurable depending on the media type ? a broadcast medium with low
capacity could still make use of mcast RAs.
"
The efficiency-aware host MUST NOT send or accept re-direct messages.
It does not join solicited node multicast address.
"
Again, yay! Does this mean we can get rid of MLD queries as well ?
"
one with ARO and another without ARO then the NS message with ARO
gets the precedence and the NS without ARO is ignored. This behavior
protects the router from Denial Of Service attacks. Similarly, if
"
What about two AROs that are different ?
"
Lifetime expires. If an ARO arrives for an NCE that is in
UNCREACHABLE state, that NCE should be marked as STALE.
"
Can we then use this STALE state as an excuse to clean up the table if it gets
full(er) on the router, similar to what we do today with binding table with FHS
? I feel we should discuss - "what happens when the resources on the router are
exhausted or close to exhaustion - how does it recover gracefully from this
condition, if at all".
"However, it will create legacy NCE for NS messages for other routers
in the network. This mode is able to prevent ND flooding on the
link."
I don't understand. Is this for more than one router running in a kind of
redundant mode ? I'd need to understand the exact topology in question, but I
think I have a comment for this part :-)
"
An efficiency-aware Router(NEAR) SHOULD be able to have configuration
knob to configure itself in Mixed-Mode where it will support both
efficiency-aware hosts and legacy hosts.
"
Would this be an excuse for some vendors to not implement the mixed mode ? I
have a vague feeling that this should be "MUST" to help enable transition, but
probably "SHOULD" is for the routers made specifically for the energy-efficient
environments ? Is this something that justified by enough of a ballast of
having to support the legacy mode ? My hunch is that probably there is not a
whole lot, but maybe I am wrong...
"
The new default
router then first send an NS to its peers with a link scope multicast
message to IPv6 address ff02::2 with the ARO option.
"
So, I think the movement scenario presents another attack vector, if I
understand it right - unless there is a signaling mechanism for asserting the
host's identity... I don't have a good solution now, just think this is a
problem. Maybe something like a binding table will take care of it - if it's
centralized at a L2 device that sees everything. I think it is a solved problem
there...
"
value of TID wins. Note that the registration ownership and local
movement detection behavior in NEAR router MUST be optionally
configured. The NEAR routers MAY implement this feature.
"
So does this mean that by default we'll "protect" the existing entry ?
"
The efficiency-aware behavior documented in this specification avoids
the ND DOS attacks by:
o Having the hosts register with the default router
o Having the hosts send their packets via the default router
o Not resolving addresses for the Routing Solicitor by mandating
SLLA option along with RS
o Checking for duplicates in NCE before the registration
o Checking against the MAC-address and EUI-64 id is possible now for
NCE matches
"
The way I see it, it does prevent the attack which destination guard prevents,
and that's it. On the other hand, it introduces a new attack where a malicious
host on local network can send a lot of registrations and exhaust resources of
the router.
I think this is where a mechanism from the network to signal "you're trying too
much" could be useful. OTOH if implemented straightforwardly, this may become a
way for the network to try to control the hosts... I don't know the answer yet.
Maybe I am ratholing, sorry :-)
"
router. At this point, the default routers use Neighbor
Advertisements(NA) to arbitrate the latest ownership of the
registration of host. The ownership of registration is useful for
"
I think I had some questions about this earlier - maybe would benefit from a
reflow, and having the same "movement stuff" in the same place ?
"
if EAH node implements DNA host capability as well, then it SHOULD
give preference to the NEAR routers in its candidate list of routers.
"
I think this is an over-spec. There is already "router preference" field, which
can be happily used to enable more than one use case, including the ability to
switch back and forth from legacy routers.
"
multicast messages in the IPv6 ND procedure, it does not affect
normal IPv6 multicast packets and ability of nodes to join and leave
the multicast group or forwarding multicast traffic or responding to
multicast queries.
"
ahha - so MLD queries are still sent by the querier routers ?
I think that might be quite an impact as well (e.g. on WLC by default MLD
querier time is 90 seconds).
"
These optimizations are not known to introduce any new threats
against Neighbor Discovery beyond what is already documented for IPv6
[RFC 3756].
"
As I noted above, I think this mechanism does introduce a new attack vector...
I am not sure if it does also introduce the attack vector of stealing the
address, seems like it might.
Hope it helps.
--a
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
