Subject: Re: [Int-area] draft-bonica-internet-icmp

From: Joe Touch <[email-masked]>
Date: Wed, 01 Feb 2006 12:49:34 -0800

I raised a few on the INT-AREA mailing list in Oct 2005 in the
pre-ICMP/MPLS split which were not addressed in either the 00 or 01
versions of this draft.

- ---
Use of the "unused" area, as Ron suggested, seems inappropriate because
those fields are not known to be 'cleared' by existing ICMP sources, so
their value cannot be reliably used for flags IMO.
- ---

A few further concerns are below:

The technique of using a valid checksum to "correctly determine" that
the option is present at the 137th byte is overstated. The 1's
complement checksum can be used to infer that data has not been
corrupted, but it is not appropriate for data synchronization (the use
here), as would, e.g., a stronger sum such as a CRC. 1's complement is
known to be susceptible to packet corruption that dovetails portions of
packets together (see Stone and Partridge, Sigcomm 2000).

Finally, and most importantly, the document does not sufficiently
address how it will affect the payload of ICMP packets, in changing
existing Internet recommendations. When the payload of certain messages
is smaller than 128 bytes, it will work fine. However, section 6
suggests (somewhat obscurely) that future implementations send only 128
bytes to represent the datagram. This is in direct opposition to the
recommendations of RFC 1812.

The only solution to these issues appears to be the creation of new type
codes and the emission of two errors for each ICMP error - one under the
current code, one with the new, augumented code. Short of this, it is
unclear that a backward compatible extension such as this can usefully
coexist.

Joe

Ron Bonica wrote:
> None that have been brought to my attention.
> 
>                             -ron
> 
> Margaret Wasserman wrote:
> 
>>Thanks, Ron!
>>
>>Are there any remaining concerns about this document that should be resolved
>>before I agree to sponsor it for publication (which will include sending it
>>for a 4-week IETF LC)?
>>
>>Margaret 
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked] 
>>>[mailto:[email-masked]] On Behalf Of Ron Bonica
>>>Sent: Monday, January 30, 2006 9:40 AM
>>>To: [email-masked]
>>>Subject: [Int-area] draft-bonica-internet-icmp
>>>
>>>Folks,
>>>
>>>I have updated draft-bonica-internet-icmp. The new version 
>>>can be found at the following URL:
>>>
>>>http://www.ietf.org/internet-drafts/draft-bonica-internet-icmp-01.txt
>>>
>>>The most significant change is that the "length" field has 
>>>been moved to avoid a conflict with the "Next-Hop MTU" field 
>>>that is defined in RFC 1191.
>>>
>>>                             Ron
>>>
>>>_______________________________________________
>>>Int-area mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/int-area
>>>
>>
>>
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Ron Bonica <[email-masked]>
Date: Thu, 02 Feb 2006 12:32:33 -0500

Joe Touch wrote:
> ---
> ---

Joe,

RFC 792 compliant implementations clear all unused bits. The statement
below is from RFC 792:

"Any field labeled "unused" is reserved for later extensions and must be
zero when sent, but receivers should not use these fields (except to
include them in the checksum)."

The rest of the argument hinges upon us being able to trust that a
non-zero value in the length field really represents the length of the
original-datagram field. If we can't agree on that much, the rest of the
argument is moot.

> packets together (see Stone and Partridge, Sigcomm 2000).

I reluctantly agree...

If the checksum is not correct, the application determines that the
subsequent bytes do not represent valid extensions. However, if the
checksum is correct, the application is not 100% certain that the
subsequent bytes represent valid extensions. It is certain only to some
level of probability.

However, I think that there is a way to work around this. See my final
comment, below.

> recommendations of RFC 1812.

We could back off from that suggestion.

The only reason that we make it is because a widely deployed base of
partially compliant TRACEROUTE applications relies on the original
datagram field containing exactly 128 octets. However, this is not a
hard requirement. If an ICMP implementation doesn't need to be backwards
compatible with those partially compliant TRACEROUTE applications, it
could send more octets.

> unclear that a backward compatible extension such as this can usefully

Do you think that the proposal could be salvaged by saying that a fully
compliant application MUST NOT parse for extentions unless a length
attribute is specified? That said, vendors would have two choices:

- field fully compliant applications, understanding that TRACEROUTE
would not be backwards compatibile with partially compliant ICMP
implementations
- field a partially compliant TRACEROUTE, possibly in addition to a
fully compliant version of the same program.

                                       Ron

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Feb 2006 10:26:47 -0800

> original-datagram field. If we can't agree on that much, the rest of the

The issue is that the receiver doesn't check that the fields are zero;
that makes sense from the sense of the original spec, but means that
setting their value will not be checked by the existing implementations.
This means that the payload that the option refers to CANNOT change
based on those fields; it can be AUGMENTED (mean more), but the existing
meaning (without length) cannot change. See below...

> compatible with those partially compliant TRACEROUTE applications, it

Dealing with one widely deployed base isn't the same as the issue of the
current recommendations, as per 1812. This document appears to override
that recommendation - that certainly needs to be more clear, at least.

I would prefer wording that addresses the impact more specifically:

	IF this option is supported and used in a particular reply,
	the node MUST NOT send more than 128 bytes of the
	original packet. This overrides the reccomendation of RFC1812
	to include s much of the original packet as possible,
	up to a total of 567 bytes, and may affect the parsing of the
	packet contents in some cases.

(this is alluded to, but not as specifically stated.

> attribute is specified?

Sure. The trouble is that this is not backward compatible.

Compliant existing implementations will ignore the length attribute, and
then can (and should) interpret the entire payload as a prefix of the
original segment.

There is nothing they can do to know this is not the case. They can't
check the IP checksum - the entire packet may not be included.

> That said, vendors would have two choices:
> 

I don't understand how existing implementations that follow existing
specs aren't fully compliant. This seems like an extension to ICMP; if
you're overriding existing standards in a non-backward compatible way,
that would be bad ;-)

> fully compliant version of the same program.

I don't know what the partially-complaint version refers to. I was
thinking of two fully-compliant versions:

	- one that knows the existing codes
	- one that knows new codes with new meanings

Joe

---

From: Ron Bonica <[email-masked]>
Date: Tue, 07 Feb 2006 07:00:45 -0500

Folks,

During a very pleasant telephone conversation, Joe Touch convinced me
that I am not so much _extending_ selected ICMP messages as
_redefining_ selected fields in those ICMP messages. At first glance,
the distinction between extension and redefinition might appear to be
inconsequential, but it is not.

If we were extending ICMP, future ICMP developers could write code that
is compliant with RFCs 792 and 1812, not specifying the length attribute
described in draft-bonica-internet-icmp. In fact, that
future programmer could be totally unaware of draft-bonica.

However, omission of the length attribute could cause compatibility
problems.

In order to maintain compatibility, when a future ICMP programmer codes
an ICMP message with the "original datagram" field greater than or equal
to 128 octets, that programmer MUST specify a length attribute.

So, in the next few days I will post an updated version of draft-bonica
that reflects Joe's comments. I realize that the word "redefinition"will
expose the draft to greater scrutiny, but I think that this is the right
thing to do.

                                       Ron

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Feb 2006 14:16:03 -0800

> to 128 octets, that programmer MUST specify a length attribute.

Minor addition:

AND all ICMP programmers MUST NOT parse more than 128 bytes of an ICMP
message unless indicated as valid by a nonzero length attribute.

FWIW, the term 'future' above may be misleading; both requirements apply
to all implementations - existing and future, since an exhaustive search
of existing implementations is infeasible.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Tue, 07 Feb 2006 18:33:23 -0500

Joe,

I am not sure that I agree with that part. I think that the following
would be a better statement:

"Fully compliant ICMP applications must not parse more that 128 bytes of
an ICMP message unless indicated as valid by a non-zero length
attribute. However, in the interest of backwards compatibility, vendors
may elect to deploy partially compliant TRACEROUTE applications.
Partially compliant TRACEROUTE applications parse the ICMP extension
header when a length attribute is lacking, assuming that the original
datagram field contains exactly 128 octets. Furthermore, partially
compliant TRACEROUTE applications only parse the ICMP extension header
when its version number and checksum appear to be correct.

> of existing implementations is infeasible.

agree.

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Feb 2006 15:37:04 -0800

> "Fully compliant ICMP applications must not parse more that 128 bytes of

MUST NOT

> may elect to deploy partially compliant TRACEROUTE applications.

MAY...

Agreed - where "partially compliant" is as defined in the doc.

> compliant TRACEROUTE applications only parse the ICMP extension header
                                   ^^^^^^^^^^^^^^^

MUST NOT parse the ICMP... when ... appear to be incorrect ;-)

> when its version number and checksum appear to be correct.

Yeah - for those on the list, we'll converge on this nit off-list...

Joe

---

From: Ron Bonica <[email-masked]>
Date: Tue, 07 Feb 2006 23:00:46 -0500

>>"Fully compliant ICMP applications must not parse more that 128 bytes of

agree

>>may elect to deploy partially compliant TRACEROUTE applications.

also agree.
>>compliant TRACEROUTE applications only parse the ICMP extension header

agree again. I will crank out another version of the draft as soon as I
return from travel and run it by you.

                                       -r