[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-metzger-ah-01.txt
- To: William Allen Simpson <Bill.Simpson@um.cc.umich.edu>
- Subject: Re: Comments on draft-metzger-ah-01.txt
- From: David Waitzman <djw@BBN.COM>
- Date: Mon, 20 Mar 95 09:50:28 -0500
- Cc: firstname.lastname@example.org
- In-Reply-To: Your message of Sun, 19 Mar 95 21:54:30 +0000. <4324.Bill.Simpson@um.cc.umich.edu>
> > 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.
Is there any point to the values being cryptographically random? I
doubt it if you're doing authentication but probably yes if you're
doing privacy. Saying just "unspecified implementation dependent" is
sufficient to get your point across. "(random)" is misleading because
it is not necessary.
> > 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.
Heres the flow I was trying to explain:
1. IP Datagram comes in on the wire
2. Some checks are done.
3. Some ICMP messages may be sent at this point.
4. Certain fields in the IP datagram are zeroed. [ Is a copy done now?? ]
5. The crypto calculation is done.
6. The datagram is then examined for other problems.
7. Some ICMP messages may be sent at this point.
-> If so, if the ICMP message requires part of the original IP datagram
to be returned, is it the IP datagram from before or after step #4?
> 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?)
I am not implementing. Perhaps later. I would like a standard IPv4
authentication and privacy protocol to be available.