Hi , Thanks for your detailed comments. Apology for the late reply . It'd be nice to know your name - so we could address you directly.
Please see the responses in-line. -----Original Message----- From: ayourtch [mailto:ayour...@cisco.com] Sent: Monday, August 05, 2013 3:52 AM To: Samita Chakrabarti; nordm...@cisco.com; pthub...@cisco.com; m...@lilacglade.org Cc: ipv6@ietf.org Subject: draft-chakrabarti-nordmark-6man-efficient-nd review 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. ===> Sure. The target of this document is both high-loss networks and regular IPv6 networks. In both cases less number of multicast signaling is desirable. I think it make sense to add a few lines on configurable number of times the RS can be sent in a high-loss link. I'll check with Suresh on his proposal. Suresh, would you like to make the comment on the list again? " 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.. ? ===> Current IPv6 ND can be spoofed as well and it is no different than that. One can run L2-level security or run SEND. " 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. ===> The document talks about both NEAR and legacy routers. The goal is to transition to a network where all routers are NEAR and hosts are Efficient-hosts. But for interoperability and backward compatibility a router can be configured in MIXED mode where it can serve both. RA frequency can be configured based on the type of network and applications. "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. ====> Not sure if I understand the problem here. Can you please explain the sequence of ND messages in Bonjour and point to the partial problem you're envisoning? " 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. ===> Makes sense. Will discuss it with my co-authors about the suggestion. " 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 ? ===> I guess it can be spared for the solicited node MCAST addr. We need to double check if NEAR uses solicited mcast for any reason. " 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 ? ===> I suppose the text can be clarified here. We are talking about the situation if the router receives two NS messages from the same host ( one regular and the other containing ARO option), then it the router should prefer the NS message with the ARO option. " 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". ===> Let's have the discussion off-line along with the co-authors and see how we can address this comment to make the router more efficient. "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 :-) ===> Good catch. It is trying to say that a NEAR creates legacy NCE for the other routers in the subnet since the routers are not registering with each other. This part needs clarification. " 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... ==> You are right -- 'SHOULD' is to help transition. There are some implementations who might not have to deal with legacy IPv6 nodes and they may decide not to implement mixed mode. " 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... ==> Agree. It could be an attack vector in an open network. But it no new threat. Do the routers today use any authentication mechanism when they exchange multicast messages today? " 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 ? ===>This makes sure the newest valid registration wins when there are multiple default routers in the subnet and the host policy is to always connect to the router that provides itself with best performance or closest proximity. " 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. ===> Note that the registration actually creates the temporary NCE with a short lifetime -- thus for unknown destinations when the attack happens, the NCE are cleared automatically after a very short while. Thus the DOS attack cannot build up. For valid entries the temporary entries are replaced by registered entries. A node cannot randomly send registration NS as they will fail with EUID checks -- of course the processing time of the CPU will be spent or the implementation may put a limit to process failed registrations from a given host. 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 :-) ==> Your concerns are reasonable. Agree with you that the implementations can provide different solutions as a value-add. " 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 you can clarify your comment with section numbers, it'd be quite useful for us to address this comment. " 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. ===> I see. Can you please suggest a text here ? " 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). ===> It is trying to say the enhanced mode routers should work with the existing protocols. Again, an implementation may choose to provide configuration knobs to customize. " 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. ====> I don't think it provides a new kind of attack. Any ND packet information can be spoofed if it is run in the clear. How does it introduce stealing the IP address? Hope it helps. ===> Thanks for your comments again. It is helpful indeed. Regards, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
