[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-arch-sec-02.txt
Hugh,
>
>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.
This is an intro section and it is providing a basic explanation of the
differences between the two modes of use. The last sentence specifies what
is tunneled, i.e., IP packets. Other protocols tunnel other packet formats,
so this is a useful degree of specificity and is not tautological.
>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 notion than additional transport mode SA nesting offers no added
benefits was not base on an assumtpion of use of inadequate encryption in
any single SA. You're right that super encryption could yield added
benefits under such circumstances. We will add a parenthetical note to
clarify this.
>
>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.
Right you are! We'll fix that.
>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?
Sorry this was not clear, but others have responded and described what is
meant. Specifically, every inbound or outbound packet is subject to
processing by IPsec and the SPD must specify what action will be taked in
each case. However, through the use of wildcards in various selector
fields, and because all packets on a single UDP or TCP connection will tend
tend to match a single SPD entry, this requirement does not imply an
impossibly detailed level of SPD specification. The selectors are
analogous to what one finds in typicaly stateless firewalls or filtering
routers, so sys admins have experience in managing specification for this
level of packet processing. I'll look to se if we can clarify the
statement, but we've generally not had any confusion in this regard.
>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.".
Yes, right again! We'll fix that.
>In "d.", what does "above" mean? I know, but am not sure that this
>term is defined (certainly not in this section).
Case "d" means that an iplementation must support an SA bundle which
consists of an AH or ESP SA, or AH and ESP SAs, in transpport mode followed
by a tunnel mode using AH or ESP. Thus packets processed via this bundle
will have two (three in the case of AH+ESP transport mode) IPsec headers,
as enumerated above.
>I am uncomfortable with this apparently intricate and empirical
>enumeration of possibilities.
We used to allow more elaborate combinations, but the WG decided to limit
the iteration and combinations as defined here, to make Ipsec
implementation easier. Enumeration seems to be the best way to describe the
allowed combinations, under these circumstances.
>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.
Although we don't support nested tunnels with common endpoints, you're
right that this could be better worded. How about "The inner IP header
Source Address and Destination Addresses identify the original sender and
recipient of the datagram (from the perspective of this tunnel),
respectively.
>In Acknowledgements there is a comma preceded by a space.
Yep, first line of the second paragraph. We'll fix it.
>Appendix C
>
>Each occurrence of "1 << diff" should probably be "1ul << diff".
>
>I'm not sure that the test harness should be included.
Not being a C programmer, I'll defer to others on these points.
Steve
References: