[EMAIL PROTECTED] writes:
> Please do read IPsec spec first....
Sorry if I'm not updated on all of the relevant spec.
> >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.
>
> there is no need to worry about this. on receiver side, you will
> reassemble then decrypt.
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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
