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

Re: ESP/AH draft comments

Cheryl,


>ESP
>
>1. Section 2, diagram. Why does the "Confid. Coverage" have a star?

The asterisk referes to the diagram "footnote".

>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).

That's a good, concise way to express the notion.  We can adopt that
terminology here and in the other documents as well.

>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?

This is partly a holdover from the previous drafts, but also a
clarification that was discussed on the list, where there was agreement
that an SPI of 0 MUST not be transmitted.  Since we earlier say that 1-255
are reserved, it begs the question as to the status of 0, so I think we
need to say something, either here or in the arch doc.

>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.

We can add the term "MUST" to this text to emphasize this.

>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.

One might argue that two hosts could establish a tunnel mode ESP SA between
them to provide better traffic flow security than would be offered by a
transport mdode ESP SA, so I am reluctant to define the difference between
tunnel and transport mode  as you suggest.  A transport mode SA to a GW
would be OK if the gateway was the destination, e.g., a secured Telnet
session for managing the gateway.  But otherwise a transport mode SA should
not be made to a gateway.

>6. Section 3.1, paragraph 2. I ferverently hope ESP won't come before
>AH in transport mode.

You and me both :-).  Steve Deering also noticed that typo and sent mail to
the list about it on Wednesday.

>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).

Sequence counter comparisons are not pefromed using modular arithmetic. The
receiver would regard receipt of of a packet with a "cycled" sequence
number as being less than the window and thus would reject the packet as a
replay, auditing the event.  No special check is needed, right?

>8. Section 3.3.1: Text should be made consistant with the AH spec.

Yes, we will make the text parallel that of AH.

>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.

We will revisit the two discussions and make them more parallel.

>AH draft:

>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)?

Your're right that the documents diverge in the discussion of inbound
processing; I suspect this is a holdover from the originals.  There is an
equivalent requirement to reject fragments for both AH and ESP inbound
processing, consistent with the prohibition against IPSEC (transport mode)
processing being applied to fragments.  So long as the software is working
properly we ought not encounter fragements.  However, it's not unreasonable
to include an explicit check for that and so we can make the discussion of
reassembly in the two documents parallel.

Steve
Follow-Ups: References: