Subject: [DNA] persistent TCP connection under 802.11 outage

From: Kai Chen <[email-masked]>
Date: Mon, 27 Sep 2004 22:32:49 -0500 (CDT)

Dear DNA members:

Sorry if this question has been asked before. I am trying to keep a TCP
connection persistent (e.g. SSH, FTP) over a 802.11 AP even after the
wireless link experiences temparary outage.

Currently the scenario goes like this:
1) 802.11 NIC detects loss of link;
2) OS tears down the interface and clears all the exisiting TCP states;
3) when the link is back, AP's DHCP likely gives the host the same IP;
4) however, the old TCP connections cannot continue due to lack of
socket states in the kernel.

Does anyone know how to solve (or approach) this problem under both
Windows XP and Linux? If the NIC's device driver can shield the link
outage from the upper layer, this problem should go away, correct?

Any pointers are greatly appreciated. Thanks very much in advance.

--
Kai Chen
Computer Science Department
Univ. of Illinois at Urbana-Champaign
Urbana, IL 61801, U.S.A.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Sep 2004 15:43:35 -0700 (PDT)

> wireless link experiences temporary outage.

Please be specific about the manner in which the "outage" is generated.
Did you pull the plug on the AP, or is the AP shedding load in an orderly
way (e.g. by Disassociating its associated stations)?

> 2) OS tears down the interface and clears all the exisiting TCP states;

I do not believe that 2) is appropriate behavior: Transport protocols
should not tear down state on receipt of a "link down" indication.

Research by MIT LCS and others has shown that WLAN links need not
necessarily be in the "up" (low packet loss) or "down" (100% packet
loss) state -- they can be intermediate states where a large fraction
of packets are lost or where connectivity is intermittent.  This is
particularly true for 802.11 adhoc operation in mesh networks.

Even in an indoor Infrastructure WLAN network where the classic
"up"/"down" model usually holds, it is possible for a STA to wander out of
range and then come back.  Where no explicit packet exchange
(e.g. Disassociate, Deauthenticate, etc.) has occurred, the "link down"
determination is typically made in an implementation specific way, based
on RSSI, packet loss, etc.

Implementations vary widely;  some will send a "link down" in only a
few seconds, others will take much longer.  The details are highly
dependent on the rate negotiation algorithm, which is not part
of the 802.11 standard.

In general, tearing down transport state on receipt of a "link down" makes
transport protocols more brittle than they need to be.  It can be argued
that this is true even given an explicit packet exchange -- a given AP
might be shutting down for maintenance and the STA might scan and
associate with another nearby AP soon after.  In this case, what good
did it do to tear down transport state?

> outage from the upper layer, this problem should go away, correct?

Shielding the outage is certainly one way to approach the problem, but a
better way is to fix the transport code so that it doesn't respond to
"link down" events.

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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 29 Sep 2004 12:57:03 -0700

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 29 Sep 2004 13:55:27 -0700 (PDT)

Thanks for the feedback.

> I'm not sure what is meant by an unreliable L2 indication. An example

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.

> What is a "weak host"? A reference to where it is defined would be

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.

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

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

> information delivered by L2) can be discussed. Btw, PPP has the same

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

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

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

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

> consumer? I think the latter.

Yes -- the latter.

> 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

OK.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 30 Sep 2004 11:49:38 -0700

> (asymmetry);  

How is the interface treated in that case? It is like "link up for
transmission, down for reception". Is this how it is presented to the IP
stack, and the forwarding takes this into account somehow?

> or where loss is intermediate in one or both directions.
> 

Yes, I agree correct and consistent implementation of link up/down on
the L2 is important.

> suppress sending a "down" indication after rate negotiation fails.

Maybe. The downside is, if the L2 is going to suppress the events, it
better know which ones to suppress. This requires pushing some of the
logic from upper-layer to L2. After all, the consumers of L2
notifications are the ones that know which ones are interesting.

> down, then the route metric goes to infinity.

The simple example I had was sending an unsolicited router advertisement
as soon as a new host attaches to the network. That happens with
cdma2k/3GPP2, though the L2 attachment point and first hop router are
the same (PDSN).

> cannot occurr prematurely this way.

I understand. I think this is just an example of a incorrectly
implemented link up on IEEE 802.11 and how it breaks things. If we
characterize the text like that, than I can understand how it fits this
document.

Alper