[DNA] Re: Feedback on draft-iab-link-indications

[Bernard Aboba <aboba@internaut.com>]

Thanks for the feedback.

>    Where the reliability of a link layer indication may be suspect, ...
>
> I'm not sure what is meant by an unreliable L2 indication. An example
> would help here.

I was thinking of some of the recent research results from MIT Roofnet,
where many of the links are neither "up" nor "down", but rather in an
intermediate state.  Will fill in the details.

>    As a result, in situations where the Weak Host model is implemented,
> ...
>
> What is a "weak host"? A reference to where it is defined would be
> helpful.

OK.  I'll add this to the glossary.  I was thinking of the "weak host
model" where the outgoing interface is determined by the routing table.

>    The result is that link
>    layer indications may not be worth considering if they are wrong only
>    a small fraction of the time.
>
> Did you mean "correct only", or "wrong even" instead of "wrong only"?

I meant "wrong even".  That is a small probability of a mistake can make
the hint not worth considering if the penalty for being wrong is large.

> Well, this is a L2 design issue imho. Once it assesses the situation as
> link down and takes actions accordingly (including delivering a link
> down event notification), the consumer of the L2 notification has
> nothing to do but take it.

The problem is that in some scenarios (such as mesh networks) it is
sometimes unclear whether a link is "up" or "down".  The up/down model
assumes that a link is either in a state where it has low loss ("up") or
very high loss ("down").  In adhoc mesh networks there can be intermediate
states were loss is low in one direction and high in the other direction
(asymmetry);  or where loss is intermediate in one or both directions.

Even in 802.11 Infrastructure mode, link "up"/"down" indications are
heavily implementation dependent.  A link can have very high loss ("down")
at one rate, and be usable ("up") at another rate.  Tests show that rate
negotiation performance can vary widely.  Some implementations are fast,
others are very slow to recognize when the link has disappeared entirely.

Plus, even if the link to one AP is "down" there may be other APs in
the same SSID, so that Reassociation may be possible.  So if there is an
alternative link that can be brought "up" then it may make sense to
suppress sending a "down" indication after rate negotiation fails.

>    2.4.  Layer compression
>
> This section is not making any statement, other than providing
> references. Layer compression's impact on the L2 indications (e.g., L3
> information delivered by L2) can be discussed. Btw, PPP has the same
> nature.

Yes, that is a good suggestion.  I will work on it.


>    2.5.  Remoting implications
>
> When an access network element other than the L2 access device needs to
> react to link events, remoting the notification is necessary. Please see
> http://yegin.org/alper/draft-yegin-l2-triggers-00.txt.

This is taken care of by existing routing protocols when the route
metric takes L2 into account (such as ETX).  For example, with ETX an
increase in L2 loss will result in an increase in the routing metric which
will cause downstream nodes to find alternate paths.  If the link goes
down, then the route metric goes to infinity.

> Unless they are remoted, the indications are delivered within the same
> node stack. I'm not sure which insecurity is this text referring to.

L2 indication "remoting" can be thought of as a routing problem, so that
routing security issues arise.

> This is due to the insecure design of that link-layer. What can we do
> about it within the scope of L2 notifications and their consumers? If
> the L2 is tricked into doing something, and it is simply notifying the
> upper-layers after the fact, done is done...

The problem is caused because 802.11F spoofs a multicast packet indicating
that the host has attached before the host has authenticated itself.  The
problem would not occur if the AP did nothing and let the host's first
sent packet cause learning to occur in the switches.  Since the AP cannot
forward STA packets until authentication completes,  switch learning
cannot occurr prematurely this way.

>      returning from sleep mode or receiving a "link up" indication could
>      encounter an address conflict were it to utilize a formerly
>      configured Link-Local IPv4 address without rerunning claim and
>      defend.
>
> Is this an issue for the link-layer indication, or its specific
> consumer? I think the latter.

Yes -- the latter.

> Again, this is a L2 design bug. Warning people about their presence is
> good, but I wonder what we can recommend based on that.

It's an example of an L2 that is unclear about the definition of
"link up" and "link down".  The lack of standardization of roaming
and rate negotiation in 802.11 are other examples.


> I think "L2 suffix advertisement" is worth mentioning as well (e.g., via
> PPP).

OK.