Subject: Re: ICMP EaTEN message...

From: William D Ivancic <[email-masked]>
Date: Mon, 10 Apr 2000 17:24:53 -0400

For the router to see the IP header and check sum, the layer 2 protocol
would first have to pass the corrupted layer 2 data to layer 3.  Layer 2
usually has its own check sum.     Assuming this is the case and the IP
checksum does not pass, I would be reluctant to  believe anything in the
header.  It seams to easy to implement denial of services attacks and other
bad things here.

Also,  I've seen ECN used in two forms:  Explicit Congestion Notification
and Explicit Corruption Notification.  These are not interchangeable.  Any
suggestions on renaming Explicate Corruption Notification?  I believe ECN
was first used for Explicit Congestion Notification.

Will Ivancic 

>
>Bora Akyol <[email-masked]> writes:
>
>> One concern:
>> 
>> How does a wireless network router know who a corrupted packet belongs to
>> in a shared medium network so that it can send this message.
>> 
>> Very likely, what this will boil to is sending a message to all TCP
>> sessions that it has seen recently on this link.
>
>This was not what I had in mind.  Rather, I thought that the router
>could simply look at the IP header in the corrupted packet and hope
>that the source IP address was not corrupted.  My assumption (not
>knowing a lot about wireless) was that there is a reasonably good
>chance that four bytes early in the packet would have made it through
>OK.  However, perhaps this is not a good assumption...

---

From: Jamshid Mahdavi <[email-masked]>
Date: 10 Apr 2000 18:05:40 -0700

> was first used for Explicit Congestion Notification.

ETEN (or EaTEN) is our attempt to rename Explicit Corruption
Notification, so there isn't a clash of abbreviations.  I added my
thoughts on one way to implement it, with ICMP.  Other suggestions are
also welcome!

ECN should mean Explicit Congestion Notification and nothing else.

--Jamshid

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 11 Apr 2000 18:19:32 -0700 (PDT)

i agree that it is quite hard in practice to use the first of
the two message types as per nitin's classification below:

"Nitin H Vaidya" <[email-masked]> said:
> There are two related possibilities for sending
> ICMP EaTEN type message, of which only the first one
> below seems to be considered in this thread:
> 
> * Unnecessary fast retransmits: As you note, the receiver
>   may determine that a packet is corrupted, and inform its
>   sender (provided that the header info is intact).
>   
>   This approach may be beneficial when the channel encounters
>   a "random" loss (as opposed to an extended period of bad state).
...

> * Unnecessary timeouts:
>   An alternative situation that is not handled well by link level
>   retransmissions is that of extended bad periods (for instance,
>   driving through a tunnel with link broken, or losing connectivity
>   during hand-off between non-overlapping cells, or a long error
>   burst for whatever reason).
> 
>   I believe that explicit notifications are of greater value
>   in such situations, than when you have occassional packet
>   being corrupted by errors.
>   In such cases, the ICMP can be generated at the base
>   station rather than the wireless receiver, for packets
>   destined to the wireless host (fortunately,
>   the base station has packet header information available).

couldn't agree more here. i presented such a solution reusing 
an existing (but unused) icmp msg during the TSVWG meeting in
adelaide. there was pushback from van jacobson, steve deering
and geoff huston primarily  on the grounds
that it is easy to launch DOS attacks by using this "host
isolated" icmp unreachable.

the DOS risk can be alleviated by applying the ttl = 255 rule to
limit the DOS to neighboring systems, a mechanism originally
suggested by bob gilligan for use in ipv6 neighbor discovery
and also used in reverse tunneling for mobile ipv4 (rfc2344).
once this is in place, the extended link outage could not be
signalled from several hops away, but thems the breaks. this
would still be useful in the common case in the future in which
cell phones become routers between a cellular network and
a local network (bluetooth, for example). 

i'll be writing this up as an (individual) internet draft for pittsburgh.
for a quick summary see attachment.

> was first used for Explicit Congestion Notification.

only the first usage is correct. there is text to clarify this
confusion in the ERROR draft (appendices).

-gabriel
Error conditions can be reported
with an ICMP Host Unreachable message.  IP is required to pass
any such messages up to transport layers like UDP and TCP,
and these, in turn, to applications above them [RFC1122].
What is not clearly defined is what code within an ICMP Host
Unreachable message should be used to notify of an error condition.
For conditions of network outage, a currently unused
'host isolated' (code 8) was introduced for routers (actually,
IMP's) to inform hosts of an outage. 
Additionally, [MD95] argues for the application of 'host isolated' for 
notifications emanating from a host's lower layers.

In summary, these notifications to upper layers can originate either from 
within a host itself or in another host altogether. ICMP includes the necessary
information to determine the sender of the notification, as well
as a part of the datagram which encountered the error.

---------------------------------------------------------------
[RFC1122] Robert Braden, RFC-1122, Requirements for Internet hosts-
communication layers, October 1989.

[MD95] Gabriel Montenegro and Steve Drach, "System Isolation and
Network Fast-Fail Capability in Solaris," Second USENIX Symposium
on Mobile and Location-Independent, April 1995.
http://www.usenix.org/publications/library/proceedings/mob95/montenegro.html