Subject: ICMP and unknown extension headers?

From: Markku Savela <[email-masked]>
Date: Tue, 6 Jun 2000 13:04:01 +0300 (EET DST)

The RFC-2460 in chapter 4 explains that one should return a "Parameter
Problem" ICMP for unrecognized extension header. This has an offset
pointing to the "next header field".

Question: What is the value of this offset, if the problematic "next
header" was uncovered by ESP processing?

Admittedly, ESP is a bad example, because one probably should not be
sending the ICMP in this case. But, there might be other future funny
extension headers that produce the next header value in strange
ways?

[Just asking before changing our implementation, which incorrectly(?)
returns ICMP Unreachable (type=1, code=4) for any protocol that
nobody listens. Unknown extension header is just a protocol that has
no handler installed or activated].

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 12 Jun 2000 15:07:53 +0900

>>>>> On Tue, 6 Jun 2000 13:04:01 +0300 (EET DST), 
>>>>> Markku Savela <[email-masked]> said:

> extension headers that produce the next header value in strange

Just as you said, I don't think it is meaningful to consider how an
icmp6 error packet against an encrypted packet should be. Is this
really your practical concern, or do you have another example of this
kind of problem?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Mon, 12 Jun 2000 09:27:08 +0300 (EET DST)

> really your practical concern, or do you have another example of this

Not really.

ESP is just an example, that there are headers where an offset to the
erroroneus value makes no sense. When such "problems" are uncovered, I
just ask myself: is the specification truly clean?

I just have architecture where extension headers can be defined and
implemented in loadable handlers, ESP being one of them, means that
the next header field must be returned by the handler in some way,
because it does not occur in packet (after ESP). Thus the API of such
handlers now has to be changed to return the offset for the ICMP in
addition to actual next header value, for the case where the next
header is unknown. (Or have some flag to tell that no offset is
available, and assume all other headers follow the default IPv6 ext
header layout...)
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Mon, 12 Jun 2000 06:58:04 -0700

>header" was uncovered by ESP processing?

It should be the offset of the byte containing the unrecognized or
unsupported Next header value, counting from the beginning of the packet.

>extension headers that produce the next header value in strange

Every extension header has a Next Header field somewhere, and that
field has some offset from the start of the packet, so what's the
problem?

>nobody listens.

That is indeed incorrect.  That error message should only be used for
protocols that:

	- you *do* recognize

	- are known to have ports 

	- have no process listening on the destination port

	- have no protocol-specific method to report the error (such as
	  TCP reset).

In practice, this means destination unreachable - port unreachable is only
intended for UDP.  (It's a little layer violation that it exists.)

> Unknown extension header is just a protocol that has

That's fine.  Such cases should be reported as parameter error - unrecognized
next header.

Steve

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 15 Jun 2000 09:45:44 -0700 (PDT)

> field has some offset from the start of the packet, so what's the

I think the stated problem is that extension headers past an ESP header
it offset might not be well defined. For instance, ESP + destination options
where the dstops header has an unknown next header field.

Imagine an ESP algorithm that does compression (and encryption).
Is the implementation supposed to determine at what offset
the offending next header value "lived" in the packet that was received
(i.e. in the encrypted and compressed packet).

Or is the implementation supposed to derive some pseudo offset from
the begining of the decrypted packet?

Similar things might appear (but less severe) when there is a fragment header
before the header which has an unknown next header field.
I suspect many implementations remove the fragment header when the reassembly
is done, which means that the next header offset the implementations
return in ICMP errors would be off by the size of the fragmentation header.
However, if the offending next header field doesn't fit in the first fragment
then what should the correct offset be in an ICMP payoad type unknown?

My assumption is that the offset is undefined both past ESP headers and
when it doesn't fit in the first fragment.

   Erik

---

From: Steve Deering <[email-masked]>
Date: Thu, 15 Jun 2000 10:41:11 -0700

>where the dstops header has an unknown next header field.

At the point in time at which one looks at a Next Header field and
determines that its value is unknown, that field is at some known offset
from the packet start (known to the node doing the inspection, that is).
The packet (or as much of it as will fit) will be sent back to the source
in the ICMP error message, and the offset will point to the troublesome
Next Header field in that returned packet.

>(i.e. in the encrypted and compressed packet).

The receiver would have decrypted and decompressed the packet in order to
examine the Next Header field.  At that point, the location of the Next
Header field is known.  The location of the Next Header field *has* to be
known in order to determine that it contains an unknown/unsupported value,
doesn't it?

>when it doesn't fit in the first fragment.

The offset is always defined in the context of the packet (or partial
packet) returned in the ICMP error message.

Steve

---

From: Steve Deering <[email-masked]>
Date: Thu, 15 Jun 2000 11:22:24 -0700

>known in order to determine that it contains an unknown/unsupported value,

On second thought, an implementation obviously shouldn't be sending a
decryption of a packet inside of an ICMP error message, so this case
is moot.

Steve

---

From: [email-masked] (Niels M�ller)
Date: 15 Jun 2000 20:31:35 +0200

> where the dstops header has an unknown next header field.

I believe it should be possible to define a sensible value for the
offset, where "sensible" means that it should make some sense to the
sender of the packet.

> (i.e. in the encrypted and compressed packet).

In this case, one way to define the offset is as the length of the
packet up to and including the ESP header, plus the offset into the
cleartext (i.e. *after* decryption and decompression) data protected
by ESP. You could end up with an offset larger than the actual packet
as it appeared on the wire, but that should not necessarily be a
problem?

> the begining of the decrypted packet?

One way to do that would be to keep track of the total length of the
headers already processed, and let each module handling a particular
header, on error, return an offset into the data that module was
supposed to handle, which the ip engine can add to the total when
building a icmp error message.

> Similar things might appear (but less severe) when there is a
> fragment header before the header which has an unknown next header
> field.
>

> then what should the correct offset be in an ICMP payoad type unknown?

Hmm. 

Is it possible to apply ESP first and then fragment the resulting
encrypted packet? If so, you might end up with a first fragment
containing an ESP header and (after decryption) some partial but valid
additional headers, and then the next fragment, after decryption,
contains a bad header that should result in an ICMP error packet. That
seems to make things more complicated.

It seems that one needs some way to indicate if the offset is relative
to an individual fragment or to some "logical" reassembled packet.

> when it doesn't fit in the first fragment.

I think it should be possible to define a reasonable offset value in
all cases, but it might be simpler to make it possible to say "oops, I
can't deal with this packet, but I won't go to the effort to tell you
the offset of the header or data I'm having trouble with.".

/Niels

---

From: [email-masked]
Date: Fri, 16 Jun 2000 04:19:10 +0900

Please do read IPsec spec first....

>encrypted packet?

	that is how IPsec is specified.  on sender side, you encrypt then
	fragment.

If so, you might end up with a first fragment
>seems to make things more complicated.

	there is no need to worry about this.  on receiver side, you will 
	reassemble then decrypt.

itojun

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 15 Jun 2000 14:56:32 -0500

> decryption of a packet inside of an ICMP error message, so this case

Not at all.  Either you send the ICMP error back down the same SA as
the offending packet or, if the selectors don't permit that, you
negotiate a new SA to send the error.

This has been thought of before, although 2401 could be a lot clearer.

				Matt

---

From: [email-masked] (Niels M�ller)
Date: 15 Jun 2000 21:53:11 +0200

> 	Please do read IPsec spec first....

Sorry if I'm not updated on all of the relevant spec. 

> 	there is no need to worry about this.  on receiver side, you will 

In this context, the problem is how to report errors by ICMP. If you
detect some problem (say an unknown header) *after* reassembly and
decryption, how do you report the error? Do you compute the offset
relative to the fragment that contained the cryptotext corresponding
to the bad header (and if so, how would you define the offset if the
data is compressed before encryption?), or do you compute it relative
to an reassembled packet that never appeared on the wire?

And as Steve pointed out, even if one computes the offset relative to
the decrypted packet, one must not quote the decrypted packet in the
ICMP packet. It seems that an ICMP packet should quote an initial
segment of the *encrypted* packet (as much of it as is needed to
reconstruct all data up to and including the data that caused the
error), but compute an offset that is interpreted after the packet is
decrypted.

For interpreting the offset, the packet should be viewed as

  some random headers (that were sent in the clear)
  an ESP header
  additional headers and data *after* decryption and decompression,
    depending on the ESP and on the corresponding secret keys.

Do we agree so far?

But this kind of breaks down in the presence of fragmentation, where
you need to be able to report errors

  (i) in the headers preceeding the ESP,
  
  (ii) in headers (or data) that appear only after decryption and
       possibly decompression, i.e. after ESP processing,
  
  (iii) in the cleartext headers (headers before the fragment header
        are sent in the clear, right?) of fragments other than the
        first. 

To me, a proper definition of the error offset seems possible but
non-obvious, and appearantly it's not obvious to Markku or Erik
either, so it needs to be spelled out clearly.

/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 15 Jun 2000 16:09:02 -0400

> the offending packet...

Uhh, SA's are unidirectional.  Perhaps you mean "send the ICMP packet
using the same SA a normal, non-errored response would use.."

					- Bill

---

From: Markku Savela <[email-masked]>
Date: Thu, 15 Jun 2000 23:21:13 +0300 (EET DST)

> using the same SA a normal, non-errored response would use.."

This is what I have been thinking that would make sense. At least in
IPv6 ICMP, the error messages are clearly distingquished. So I have
been wondering if it would be a good rule as follows:

 for IPv6 ICMP Error reports,

  outbound: apply policy and IPSEC to the error packed based on the
  header of the received packet (except the src/dst swapped as if the
  packet were going out)

  inbound: the policy check on ICMP error packets is based on the
  contained header (not the outer ICMP). Thus, if the contained packet
  would have required some IPSEC operations, the *whole* ICMP error
  should have been protected by this IPSEC.

Whether above would be useful, I don't know. I just know that in my
code it would be fairly simple change: when extracting the parameters
from the packet for selector search, I would  just have a branch for
ICMP error types to fetch the same values from the inner header...

-- msa

---

From: Steve Deering <[email-masked]>
Date: Thu, 15 Jun 2000 15:03:09 -0700

At 9:53 PM +0200 6/15/00, Niels M–ller wrote:
>non-obvious, ..., so it needs to be spelled out clearly.

The error offset (in the ICMP Pointer field) is an index into the returned
packet or truncated packet carried in the payload of an ICMP error message,
pointing to the Next Header field that contains the unknown/unsupported
value that caused the ICMP error message to be sent.  (In the unusual case
where the problematical Next Header field does not fall within that part
of the packet that fits within the ICMP error message, the offset points
beyond the end of the returned packet, to where the field would be if it
did fit.)  I think that definition is clear enough.  But that leaves open
the question of what the returned packet itself should look like, in some
of the unclear cases people have been talking about.

My own opinion is that the returned packet or truncated packet should just
be the packet in the form it (logically) appears in the memory of the
receiver at the point in time when the unrecognized Next Header value is
detected.  By "logically", I mean assuming that the receiver is not
stripping off and discarding headers as they are processed (except as
specified for fragment reassembly) or scattering them around to separated
places in memory.

Thus, if the unrecognized value is in a header following a Fragment header,
then the returned packet is the reassembled packet (or as much of the
reassembled packet as will fit, if the whole packet doesn't fit).  If the
unrecognized value was found after decompressing a packet, the returned
packet is the decompressed packet (if the security rules allow it to be
sent at all).  I don't think it matters that the returned packet might
not be identical to something that was actually sent on the wire, and in
fact it is likely to be more useful as a diagnostic tool if it contains
the "processed" packet.  I also think it would be an unwarranted burden
to require implementations to keep around a copy of an unprocessed
received packet, just in case an error message may have to be sent about it.

Comments?

Steve

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 15 Jun 2000 22:30:46 -0700 (PDT)

> Next Header field in that returned packet.

Sorry for my confusion.

I don't know what the security crowd thinks about decrypting a packet
and then including at least part of that packet in an ICMP error
that might be sent in the clear. But that is a different issue.

   Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 21 Jun 2000 08:34:36 +0900

>>>>> On Thu, 15 Jun 2000 15:03:09 -0700, 
>>>>> Steve Deering <[email-masked]> said:

> reassembled packet as will fit, if the whole packet doesn't fit).

Agreed.

> If the
                                     ^^^^^^^^^^^^^you mean decrypting?
> sent at all).

Agreed, although (if you meant decrypting) security folks would think
the error should not be sent as a security point of view.
(If you just meant a compressed packet, I completely agree with you.)

ICMP error packets are just for diagnosis. A receiver of the error
should not care about how the returned packet look like, as long as
the receiver can detect the point of the error correctly.

I'm not sure whether this should explicitly stated in an ipng
document, but it would be useful information for implementors.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 21 Jun 2000 07:50:10 +0900

>>>>> On Thu, 15 Jun 2000 23:21:13 +0300 (EET DST), 

>   should have been protected by this IPSEC.

But how can you examine the contained header, which might be
encrypted, for the policy check?

					JINMEI, Tatuya

---

From: Steve Deering <[email-masked]>
Date: Wed, 21 Jun 2000 16:17:12 -0700

> > packet is the decompressed packet (if the security rules allow it to be

I did mean decompressing.  I thought someone brought up the example of
using the ESP encapsulation to implement compression (or maybe using
a new kind of extension header for compression).

Steve

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 22 Jun 2000 08:20:56 +0900

>a new kind of extension header for compression).

	IPComp? (RFC2393)

itojun

---

From: Markku Savela <[email-masked]>
Date: Thu, 22 Jun 2000 02:33:54 +0300 (EET DST)

> encrypted, for the policy check?

I don't see any problem. Packet is in clear at this point already.

On inbound, the policy check is of course done after IPSEC decryption,
as with any other IPSEC packet. This applies to the ICMP's that come
from the other end point. If ICMP is generated on the route by some
router, then I would not try to decipher it too much (with truncation
and ESP, things get messy).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 26 Jun 2000 06:20:02 +0900

>>>>> On Thu, 22 Jun 2000 02:33:54 +0300 (EET DST), 

> and ESP, things get messy).

Ah, I see. I misunderstood the order of processing. Thanks for the
clarification.

					JINMEI, Tatuya