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

Comments on ESP and AH IPSEC drafts.


After implementing the IPSEC AH and ESP transforms, I have a few
comments I'd like to make on the drafts.  Most of the comments I have 
concern the performance of the transforms. Although I've achieved 
performance numbers which are better than my expectations, there is 
always room for improvement.   Also, the more closely the transforms 
perform to clear packets, the faster people will adopt IPSEC in general, 
obviously. 


ESP Draft (draft-ipsec-esp-des-md5-03.txt Sept 96):

Section 2.2: Initialization Vector.

I think including an IV in the packet should constitute a separate 
transform with a unique IANA designation.   Optional fields slow 
performance and in this case, the keying material and caching information 
are different even though most of the actual operation is substantially 
the same.  A separate transform designation would allow implementations 
treat the packets differently, to store cached information differently 
and process packets uniformly without in-line testing.   Implementations 
could achieve the same effect by sub-categorizing transform designations 
on their own, however a separate designation would allow the transforms to 
diverge in order to support hardware assist (original intention) and to 
simplify SA negotiation for transforms without the IV. 

Section 2.3: Replay Prevention.

I don't see the purpose of negotiated window sizes unless there is some 
vulnerability in accepting out of order packets.  I don't know of any such 
vulnerabilities but if there are, it would be nice if they were called out 
in the draft.   If there are no such vulnerabilities, then why would I ever 
want to NOT support receiving packets out of order if my implementation 
supports a sliding window?  If I'm communicating with a host that does not 
have a window, I'll be re-transmitting a lot of packets but there is no 
reason for me not to accept packets out of order.   This seems like an 
implementation detail not to be negotiated. 


Section 2.5: Padding.

I would like to suggest placing the Payload Type, Pad Length and padding 
fields before the payload data.   Stop laughing.   After having implemented 
this, I can say that it would be a heck of a lot more efficient and 
therefore, perform better, if I didn't have to walk an MBUF chain twice to 
remove padding.  You have to do this twice because you have to go to the 
end first to get the length of the padding.   Since the padding could be 
spread out of a variable number of buffers behind you, you have to start at 
the head again and walk down until you find the buffer containing 
packet[length-pad], and free from there.  Chopping the data off the head of 
the buffer chain would save this walk and some hairy math to crop the right 
size of data off the end. 

The HMAC data at the end isn't as much of a problem because you can 
find it on the first pass.  Placing it at the head however would remove the 
buffer chain walk completely.    I don't know if this is enough of a win to 
change its location, considering the buffer would have to zero'd as is 
the case with AH.    



AH Draft (draft-ietf-ipsec-ah-hmac-md5-02.txt Aug 96) 

Section 2.1: Replay Prevention.

The replay field, as described, is NOT similar to the replay field 
described in the document ESP-DES-MD5 document.  ESP-DES-MD5 contains only 
a 32 bit field while this document calls for a 64 bit field.  Also, the 
paragraph concerning the key lifetime not exceeding the period to transmit 
2^64 packets contradicts other statement made in document. The section on 
keys states, "Thus implementations should, and as frequently as possible, 
change the AH key."  It seems a 32 bit replay field would be more in line 
with key refresh needs.    If we agree to a 64 bit field for easier support 
on 64 bit architectures, it may be wise to support using only 32 bits for 
key refresh purposes anyway.  

Also, for performance sake, could we make the field non-optional?  If the 
key negotiation determines the parties not do replay detection, the field 
should still exist, left untested.  This would fix the overhead of the 
header and reduce testing and gyrations around optional fields in the 
middle of the header.   If it is truly to be optional, lets move it to 
after the authentication data. 

As an overall comment, the AH document does not include varied keys for 
initiator and responder as the ESP document does.   Shouldn't we vary 
the keys in the same manner? 


Comments anyone?

------------------------------------------------
Rob Adams                       adams@cisco.com
Cisco Systems                   408 457 5200
101 Cooper St.
Santa Cruz, CA 95060
Follow-Ups: