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

comments on draft-ietf-new-auth-00




I read this again and had a few comments, but the major comment is.. wow.. good job!
Thanks Steve, Ran and all other contributors...   This makes a lot of things explicit
and clear... 

My comments are mostly nits..  I'm an engineer, what do you want?

Section 1:

>>   AH may be applied in combination with the IP Encapsulating 
>>   Security Payload (ESP) [KA97b]

I think I'm stupid.   I don't really get the usefulness of this combination anymore other than
it signs the IP header of an ESP'd packet.   Is it really necessary to do this? And is there
a situation where this would foil a realistic attack?  I'm probably just being dumb, nothing new,
but I'm at a loss.  This made loads of sense before combined ESP transforms, but does it
anymore?

Section 2.2:

Remove the null algorithm reference.  I think this is only useful for debugging and probably 
doesn't belong in this document. 

Section 3.2.2:

>> the transmitter increments the sequence number

Earlier you said that the sequence starts at one, and here you say
increment it first implying that the first on the wire is 2.  Okay,
Okay, I know this is a ridiculous comment and everyone knows what 
is meant, but I've actually had conversations with implementers 
where this particular point has caused confusion. 


Section 3.2.3.1.1:

Offset and Flags.  We actually had an interesting conversation about this at the 
anx bakeoff.   Re-assembly is to take place underneath you but you can't be 
assured that the flags will be the same at the receiver as they are at the sender.
You may not do MTU discovery on your host, but a gateway may.  It could set the DF
bit before forwarding.  At the other end, the DF bit may still be set.  In this case, 
fragmentation/reassembly may not even happen, but the bit will still be set in transit. 

Section 3.3.2:

>>There is no requirement for the receiver to transmit any message
>>to the purported transmitter in response 

I'd like to see a "MAY send an administratively prohibited ICMP" here...  This could be very
useful to some implementations, and probably ought to be a matter of policy.  Say for example,
in my LAN, I want this message so I can solve problems quickly, outside my LAN, let them
stew...   Not necessary, just an idea. 

Section 3.3.3:

Could we update the example algorithm in the Hughes draft to do the window test/update in
two separate operations?  Now it does it in one, and the recommended path here is to test,
authenticate then set.  Any example algorithms published should fit the recommendation. 


That's it.  Like I said.. mostly silly..

Again thanks to Steve, Ran and all who contributed, this feels like a real step forward.

-Rob



Follow-Ups: