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

[Alper Yegin <alper.yegin@samsung.com>]

> I'm in the process of editing a document on the subject.  Comments
> welcome:
> http://www.drizzle.com/~aboba/IAB/draft-iab-link-indications-00.txt

I'm glad to see IAB is producing a document on link-layer indications.
This would be useful in many places. Thanks.

Let me register my feedback on the document.

This document has a good coverage. I'd recommend addition of DNAv6
discussions, with a reference to draft-ietf-dna-link-information-00.txt.
Also, a discussion around anticipation (link going up/down) would be
useful. Relevant references are draft-ietf-mipshop-fast-mipv6-02.txt and
draft-ietf-mipshop-80211fh-01.txt. 

The document is focused on IEEE 802.11. I think other wireless and wired
L2s are worth considering (802.3, gprs, cdma2000, etc.)


   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.


   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.


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


   As noted earlier, in many circumstances, the definition of "link up"
   or "link down" may not be clear.  For example, where no response is
   provided to multiple retransmissions, a mobile node may wish to scan
   for an alternative point of attachment, since the likely reason for
   the loss is that it has moved out of range of the Access Point.
   However, in a stationary point-to-point installation, it is more
   likely that the link has become impaired, and therefore may return to
   service at a future point.  As a result, the definition of "link
   down" may change depending on the usage scenario.

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.


   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.


   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.


   Since link layer indications are typically insecure, proposals
   incorporating them need to consider the potential security
   implications of spoofed or modified link layer indications, as well
   as the potential denial of service attacks.  This is particularly
   important in situations where insecure link layer indications are as
   a substitute for secure mechanisms operating at a higher layer.

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


   As a result, link
   layer indications as implemented in [IEEE80211F] enable an attacker
   to disassociate a station located anywhere within the ESS, simply by
   sending a Reassociation Request frame.

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


   Claim and Defend
     Prior to configuration of a Link-Local IPv4 address, it is
     necessary to run a claim and defend protocol [IPv4LL].  Since a
     host needs to be present to defend its address against another
     claimant, and address conflicts are relatively likely, a host
     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.


     Premature "link up" indications result in both security
     vulnerabilities and potential problems with IP address assignment.
     By causing the DS to be updated once a Reassociation Response is
     sent, [IEEE80211F] enables an attacker to disconnect attached
     stations at will by sending a Reassociation Request from anywhere
     within the ESS.

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


   Link Layer Prefix Advertisement

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

Regards,

Alper