[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on draft-metzger-ah-01.txt

> From: David Waitzman <djw@BBN.COM>
> Section 2.1 second to last paragraph of Authentication Data: It says
> "filled with unspecified implementation dependent (random) values".
> The word "random" is perhaps dangerous here, since you (I presume)
> don't mean cryptographicly random.  I suggest removing it.
The parenthetical aside "(random)", which is implementation dependent,
could certainly be cryptographically random if the implementation so
desires.  In any case, completely unspecified implementation dependent
values could appear to be random or appear to be the same, randomly;
that's what "unspecified implementation dependent" means.

> Section 3.1 third paragraph: Could you clarify which IP options are
> calculated in the calculation?  IP LSRR, timestamp, etc. options are
> modified in transit so should not be in it.
If you already know that these options are modified in transit, then I'm
sure that others can figure out the same thing.

There are many options, some obsolete, and new ones may show up at any
time.  It is not useful to list all possible past, present and future
options.  It is not useful to spell out every last implementation detail
in a protocol specification.

> Section 3.1 last paragraph: Must the ICMP data containing part of the
> offending IP datagram have unmodified (e.g. pre-zeroing) values for
> those fields zeroed in the crypto-checksum calculation?  This would
> require making a copy of the original datagram or at least of the
> fields that will be zeroed, just in case the datagram is rejected but
> may provide better error information.  I suspect that you want the
> faster behavior (e.g.  no copying).
I have no idea what you are talking about.  The fields in the appended
IP datagram (in those messages which append an IP datagram), will no
longer be modified in transit, even if they are options which may have
been previously modified in transit to that point, and therefore would
not be zeroed during the calculation prior to sending.

Your implementation is responsible for handling the calculation, and
such details as copying are outside the scope of this document.  (I
presume from your comments that you are implementing?)

> (please send responses directly to me as I'm not on the ipsec list)
Just this once.  If you wish to participate, you should be on the list.