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

Comments on draft-ietf-ipsec-arch-sec-02.txt

I was disappointed that there wasn't more said about ISAKMP/Oakley
etc.

Section 3.2, has the sentence:
   In transport mode the protocols provide protection primarily
   for upper layer protocols; in tunnel mode, the protocols are applied
   to tunneled IP packets.

as a naive reader, I have no idea what this is trying to communicate
about tunnel mode.  It sounds like a tautology.

Section 4.3 states:

           o Transport adjacency refers to applying more than one security
             protocol to the same IP datagram, without invoking tunneling.
             This approach to combining AH and ESP allows for only one
             level of combination; further nesting yields no added benefit
             since the processing is performed at one IPsec instance the
             (ultimate) destination.

This statement must be assuming that two composed ESP transforms are
no more secure than a single one (otherwise the conclusion is false).
Similarly, it must assume that two AHs don't lead to more confidence.
I think that neither of these assumptions is true.  On the other hand,
one approach available is to add a new AH or ESP that is equivalent to
the compositions of interest.

I'm not quibbling with the decision to limit adjacency.  I just think
that the quoted text isn't precisely correct.


The first normal paragraph after this quoted text starts:

   These two approaches also can be combined, i.e., an SA bundle could
   be constructed from one tunnel mode SA and one or two transport mode
   SAs, applied in sequence.

The use of "i.e." is incorrect; "eg." is meant; "for example" is
better.

Section 4.4.1, paragraph 3, sentence 2 states:

   This interface must allow the user (or system administrator) to
   specify the security processing to be applied to each packet entering
   or exiting the system, on a packet by packet basis.

I don't think that the user/sysadmin would be willing to specify
security processing on a packet by packet basis.  What exactly is
intended by this sentence?

Section 4.5, near the end:

   The following combinations of AH and ESP MUST be supported in the
   indicated contexts:

           - Cases 1, 3, 4 (between H1 and H2):
                   a. AH in transport mode
                   b. ESP in transport mode
                   b. AH followed by ESP in transport mode
                   d. any one of a, b, or c above AH or ESP in tunnel mode
           - Cases 1, 2, 3, and 4 (all SAs shown):
                   e. AH in tunnel mode
                   f. ESP in tunnel mode

   As noted above, support for additional combinations of AH and ESP is
   optional.  Use of other, optional combinations may adversely affect
   interoperability.

I think that the second "b." ought to be "c.".

In "d.", what does "above" mean?  I know, but am not sure that this
term is defined (certainly not in this section).

I am uncomfortable with this apparently intricate and empirical
enumeration of possibilities.

Section 5.1.2, first point:

         o The outer IP header Source Address and Destination Address
           identify the "endpoints" of the tunnel (the encapsulator and
           decapsulator).  The inner IP header Source Address and
           Destination Addresses identify the original sender and recipient
           of the datagram, respectively.

The word "original" is a little tricky.  We might be dealing with
tunneling in tunneling.

In Acknowledgements there is a comma preceded by a space.

Appendix C

Each occurrence of "1 << diff" should probably be "1ul << diff".

I'm not sure that the test harness should be included.

Hugh Redelmeier
hugh@mimosa.com  voice: +1 416 482-8253
Follow-Ups: