[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on 2401bis-01 - SAD, pkt processing
In draft-ietf-ipsec-rfc2401bis-01.txt sect. 4.4.3 (re the SAD) on p. 23:
Note that
implementations SHOULD be able to handle having the counters at
the ends of an SA get out of synch, ...
(md) Given that the counters will almost certainly be out of sync,
shouldn't that SHOULD be a MUST?
-----
In sect. 5 on p. 28 re IP Traffic Processing:
But, if the SPD entries are first
decorrelated, then the resulting entries can safely be cached, and
each cached entry will map to an SA (or multiple SAs if "populate
from packet" (PFP) is specified), or indicate that matching traffic
should be bypassed or discarded, appropriately.
(md) Rather than 'or multiple SAs if "populate from packet" (PFP) is
specified' wouldn't it be 'or multiple SAs if "populate from packet" (PFP)
is specified or if the SAs have been negotiated with a peer whose SPD
requires finer SA granularity'
-----
In sect 5.2 (inbound traffic processing) on p. 36 list item 2:
2. The packet is examined and demuxed into one of three categories:
- If the packet appears to be IPsec protected and it is addressed
to this device, an attempt is made to map it to an active SA
via the SAD.
- Traffic not addressed to this device is directed to
BYPASS/DISCARD lookup. If multiple SPDs are employed, the tag
assigned to the packet in step 1 is used to select the
appropriate SPD-I (and cache) to search.
- ICMP traffic directed to this device is directed to
"unprotected" ICMP processing (see Section 6).
(md) Packets addressed to this device that are not AH, ESP, or ICMP are not
accounted for. E.g. IKE. I think they should be added to the second
category as so:
- Traffic not addressed to this device, or addressed to this device
and not AH, ESP, or ICMP, is directed to BYPASS/DISCARD lookup.
If multiple SPDs are employed, the tag assigned to the packet in
step 1 is used to select the appropriate SPD-I (and cache) to
search.
A similar change would be needed 2 paragraphs further down in list item 3b.
Thanks, Mark