Subject: draft-chakrabarti-nordmark-6man-efficient-nd review

From: ayourtch <[email-masked]>
Date: Mon, 5 Aug 2013 12:51:53 +0200 (CEST)

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 21 Aug 2013 00:39:17 -0400

Hi Andrew,

On 08/05/2013 06:51 AM, ayourtch wrote:
> 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.

Here is the draft I was talking about. The draft will go to WGLC soon.

http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-01

Thanks
Suresh

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 21 Aug 2013 10:36:08 +0100 (WEST)

Hi Suresh,

> http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-01

This is a much needed work, awesome, thanks!

I hope we see all hosts doing it soon.

(I've a couple of Qs on the resilient RS, I'll unicast them, to avoid the 
thread pollution).

--a

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 30 Aug 2013 01:44:54 +0000

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:[email-masked]] 
Sent: Monday, August 05, 2013 3:52 AM
To: Samita Chakrabarti; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
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.

----------

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.

"

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?

"

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.

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

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.

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?

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.

"

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

"

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

"

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

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

"

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

==> 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?

"

"

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

"

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

==> Your concerns are reasonable. Agree with you that the implementations can provide different solutions as a value-add.

"

===> If you can clarify your comment with section numbers, it'd be quite useful for us to address this comment.

"

===>  I see. Can you please suggest a text here ?

"

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

"

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

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 30 Aug 2013 01:55:19 +0000

Hi Suresh,

Thanks for the pointer to the draft.

It sends continuous RS messages or uses exponential backoff algorithm until  it gets a RA.

Sure, we can put a reference to this draft from our document for line-powered networks.  In restricted node networks, continuous RS from multiple nodes are not desirable, in those cases the MAX_RS_SOLICITATIONS  can be increased to a higher number than 3.

Regards,
-Samita

-----Original Message-----
From: Suresh Krishnan 
Sent: Tuesday, August 20, 2013 9:39 PM
To: ayourtch
Cc: Samita Chakrabarti; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd review

Hi Andrew,

On 08/05/2013 06:51 AM, ayourtch wrote:
> 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.

Thanks
Suresh