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

Re: New draft -- IPSEC AH

I don't see any substantive problems but here are a couple of "nits" that I
see as interoperability (or understanding) issues.  On this:


> 
 > 2.2 Payload Length
 > 
 >    This 8-bit field specifies the length of AH, in 32-bit words (4-byte
 >    units), minus "2," i.e., the fixed portion (as defined in the
 >    original AH spec) of AH is not counted.  (Since the Sequence Number
 >    field is always present, the fixed portion of AH is now three 32-bit
 >    words.  However, the "minus 2" length adjustment has been retained
 >    for backwards compatibility.)  A "null" authentication algorithm may
 >    be used only for debugging purposes.  Its use would result in a "0"
 >    value for this field, as there would be no corresponding
 >    Authentication Data field.

Two points on the above.  

What is the "backwards compatibility" issue here, can that be
elaborated on at least by E-mail?  Is there code out there based on the
old RFC thats just looking to skip over the AH and can otherwise still
function even though it no longer understands this header format?  We
have a legacy of firewalls, for example, that will let AH go by but may
wish to filter other things later on in the packet?  If this is the
understanding then I guess that text there is fine...

The other point is that if the length field should be "# 32-bit words
minus 2" then I don't understand how the last sentence gets a result of
"0" for the null authentication algorithm example.  Shouldn't it be "1"
since the fixed portion of AH is now 3 32-bit words?  And in the more
"standard" case of a 96-bit authentication value plus the 3 32-bit fixed
portion the length field will be "4", correct?

(Perhaps this is the problem Steve Kent's E-mail this morning was
referring to when he mentioned that Karen Seo spotted a problem, my
apologies for elaborating on this if thats so.  I couldn't tell whether
she did that in the past or against this latest draft which seems to have
it incorrect.)


A second issue:

 > 
 > 2.5 Sequence Number
 > 
 >    This unsigned 32-bit field contains a monotonically increasing
 >    counter value (sequence number).  The counter is initialized to 1
 >    when an SA is established.  The sequence number must never be allowed
 >    to cycle; thus, it MUST be reset (by establishing a new SA and thus a
 >    new key) prior to the transmission of 2^32-1 packets on an SA.
 > 

 .
 .
 .

 > 3.2.2  Sequence Number Generation
 > 
 >    The transmitter increments the Sequence Number for this SA, checks to
 >    ensure that the counter has not cycled, and inserts the new value
 >    into the Sequence Number Field.  A transmitter MUST not send a packet
 >    on an SA if doing so would cause the sequence number to cycle.  An
 >    attempt to transmit a packet that would result in sequence number
 >    overflow is an auditable event.


Minor inconsistency or missed update in the above sections.  As exchanged in
E-mail between Adams and Kent (4/3 & 4/5/97) there is still the
appearance that the first sequence number on the wire is 2, not 1.  If
section 2.5 (this *sounds* like the sender's version of the SA) would
initialize its counter to 0, not 1, then  3.2.2 will "send" sequence #1
for the first packet.  The 2^32-1 is then 2^32 in section 2.5, 2^32-1
packets may be transmitted successfully before cycling the numbers.

My only concern is that I don't want receivers to be built that always
drop the first packet of the SA (3.3.3 is a little vague about what the
lowest valid sequence number is at SA startup that can be received,
even though its receive counter is initialized to zero).  SA startup
can be slow enough without this additional packet loss.

Thanks.

                        
                         
   -- Marc --
Follow-Ups: