Re: Some queries regarding RFC 2401: Authentication Header

[Jean-Jacques Puig <jean-jacques.puig@int-evry.fr>]

837,

> 	Some Questions realted to RFC 2401, "Authentication Header":

Authentication Header is 2402. 2401 is worth a look anyway.

> > 1) In section 2.2, Payload Length, it is stated that we can use a "null"
> > algorithm, but i read in RFC 2401, that one must provide at least one
> > service at one time. It doesnt make sense to provide null algorithm. For
> > what sort of debugging is it used ?

I believe it's up to implementors to deal with this question. An example would be to check if a communication with NULL AUTH works; if it does not, there is no point going further anyway. If it does and if it fails with non-NULL AUTH, may be the AUTH algorithmn should be check again, or the algo lookup, the algo use (params...).
NULL AUTH is free. Why shouldn't it make sense ?

> > 2) In IPv6, do we compute the "Payload Length" in 64-bit words or 32-bit
> > words? and do we subtract 2 or 1 in any case for that count?

The section 2.2 is actually clear about it.
IPv4 word length = 32 bits
IPv6 word length = 64 bits
But you should only care about what you really need to know for this payload:

AH Payload length is mesured (in both IPv4 and IPv6) in 32 bits words, minus 2.

Beware of padding, which may involve different payload length for IPv4 and IPv6 (see section 3.3.3.2.1).

Again, IMHO, section 2.2 and section 3.3.3.2.1 are quite clear about it.

> > 3)In case of Sequence Number cycle, do we just drop the packet and report
> > an auditable event or do we create a new SA and Key every time it happens
> > or do we do both?

Sections 3.3.2 and 3.4.3 deals with that.

3.3.2 states:
	"If anti-replay is disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5.) However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero."
and 3.4.3:
	"If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number."

Thus, if anti-replay is disabled, you should not care about cycling.

Now, if anti-replay is enabled:
3.3.2 says:
	"Thus, if the counter has cycled, the sender will set up a new SA and key..."
Ok, it may be unclear.
I thing that the peer which is about to send the first cycling packet SHOULD NOT send such a packet, but SHOULD immediately set up new keying material via IKE.
Logically, peers should not, in a certain way, 'replay' packets of their own (the data from packet sequenced 1 on firts cycled packet could be the same).
Thus, if sequence number cycle, you should drop the packet. This is an auditable event.

> > 4) In the section 3.3.3.2.1 "Authentication Data padding", its is stated
> > that "These padding bytes are included in the Authetication Data
> > calculation", dont we just zero the authentication data field while
> > computing the ICV. If not,  in what perspective the above statement has
> > been made?

It has nothing to do with the Authentication Data field padding (section 3.3.3.2.1).
Section 3.3.3.2.2 explains how PACKET is padded in order to meet ICV computation blocksize requirements.
e.g. if your authentication algo operate on blocks of 17 octets, you should padd the end your packet with (17*(Esup(packet_length/17)) - packet_length) zeros,
where Esup() is:
packet_length/17 is this is an integer (no padding required)
E(packet_length/17) + 1 if packet_length/17 is not an integer (E() being floor() or trunc()).

--
Jean-Jacques Puig