[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ESP/AH draft comments
So I don't need to drag paper around on vacation...
ESP
1. Section 2, diagram. Why does the "Confid. Coverage" have a star?
2. Section 2.1: I've always found it easier to state that an SPI is
uniquely identified by the tuple (dest addr, security prot, spi).
3. I think we should get rid of the references to the special cases
for debugging. The couple of instances we have is either too many or
two few -- why do we *just* have these?
4. Padding: make very clear that the "default" means what to do (MUST)
if cipher doc doesn't give one; in this case the sender must perform the
default processing.
5. My working definition of transport mode has been: the crypto peers
are both the same as the endpoints for the "original" IP datagram.
Tunnel mode is when they both aren't the same.
I've heard sentiment that a so-called security gateway should allow
transport mode connections to/from itself to an IPSEC host/another
gw. I'm personally somewhat neutral, but we should resolve this.
6. Section 3.1, paragraph 2. I ferverently hope ESP won't come before
AH in transport mode.
7. I'd asked this question before, but I don't remember the response:
If replay detection is a facility to protect the *receiver*, why is the
only auditable event one where the *sender* detects that it has sent too
many packets on the current SA? In the old Hughes draft, it spelled out
that the receiver would detect rollover and treat as the serious event it
was. I don't think it makes sense for the sender to log (it should have
been worrying about getting a new SA in place); and we have no indication
of a replay rollover failure as detected by the receiver (if it's still
really possible to do this with zero-relative counters).
8. Section 3.3.1: Text should be made consistant with the AH spec.
9. Section 3.2.3: make discussion of packet encryption more parallel to
the discussion of packet decryption. The narrative is "more different"
than is warranted.
AH draft:
Several comments from above apply here as well.
1. 3.3.1. I don't understand the discussion about "appears to be an IP
fragment". I also don't know why it's discussed here, and not in the
ESP draft as well. What are we protecting against here that we need a
special check/audit event for this case (such that an ICV wouldn't catch
a reassembly error, for example)?
- C
Follow-Ups: