Post by Theodore Ts'oMany thanks to Stephen Kent and Karen Seo for submitting the updated
version of the rfc2401bis-03.txt. At this point, we believe that this
document has addressed all pending issues that have been listed in the
Issue Tracker. So therefore, it is appropriate that we start a one
week working group, starting today and terminating on Tuesday, October
2nd.
I presume that was supposed to be Tues Oct *5* :-)
Thank you Steve and Karen, this is coming together nicely! Nonetheless,
here are a bunch of comments...
--Mark
-------
In sect. 3.1 p. 8:
"In this document, the term "inbound" refers to traffic entering an IPsec
implementation via the unprotected interface or emitted by the
implementation on the unprotected side of the boundary and directed towards
the unprotected interface."
I believe the next-to-last word there should be protected, not UNprotected.
-------
In sect 4.1 p. 13:
"A transport mode SA is a security association typically employed between a
pair of hosts to provide end-to-end security services. When security is
desired between two intermediate systems along a path (vs. end-to-end use
of IPsec), transport mode MAY be used between security gateways or between
a security gateway and a host. In the latter case, transport mode may be
used to support in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling
[FaLiHaMeTr00]) over transport mode SAs."
The phrase "in the latter case" may have been meant to refer to "when
security is desired between two intermediate systems" as distinct from
"between a pair of hosts." But, it can easily be read as referring to
"between a security gateway and a host" vs. "between security gateways" and
thereby stating that transport mode with in-IP tunneling may be used
between an SG and a host but not between 2 SGs. Since I don't think that's
the intent I propose the following change:
s/In the latter case/In the case where transport mode is used between
security gateways or between a security gateway and a host/
--------------
In sect. 4.4.1 re selectors (p. 20):
"Since the SPD-I is just a part of the SPD, the same rule applies here,
i.e., if a packet that is looked up in the SPD-I cannot be matched to an
entry there, then the packet MUST be discarded."
In this text, it is not clear to me what "the same rule applies here" is
referring back to. Perhaps this can be clarified or removed.
--------------------
Also in 4.4.1: If I understand correctly, the SPD-S, SPD-I, and SPD-O are
just subcategories of the overall SPD and in the ordered SPD these are all
interleaved, is that right? If the SPD has been decorrelated the question
doesn't really arise but if not decorrelated and working from an ordered
SPD, it's not clear that it makes any sense to look in one of these without
looking in all of them. Perhaps the text can clarify this.
--------------------
In sect 4.4.1.1 (Selectors), Next Layer Protocol: I believe that for IPv4
the next layer protocol in the packet that is evaluated against the SPD is
*always* the value in the Protocol field, i.e. there is no concept of
skipping over any encapsulations. I think the description here of skipping
over extension headers should be clarified that it applies only to IPv6.
-------------------
In sect. 4.4.1.1 p 25-26, where it is describing selectors for ICMP type
and code it talks about e.g. "The message type is placed in the most
significant 8 bits of the 16-bit selector and the code is placed in the
least significant 8 bits. ..." There is similar text for the MH
selector. I don't think this is relevant for RFC2401bis; this looks like
it belongs in IKEv2, and in fact it is (for icmp anyway). This text should
be removed, or if it needs to stay for some reason it should state that it
is talking about encoding these selectors for IKE.
In sect 4.4.1.3 there is other text about setting port selectors. Is this
about setting port selectors in IKE? If so I suggest adding a sentence
pointing out that that's what the section is about.
----------------
In 4.4.1.1 and 4.4.1.2. Is "Name" a Selector or is it something else? In
4.4.1.1 (p.26) it's listed as one of the selector types but in 4.4.1.2 it
is listed as a part of the SPD entry separate from the selector sets.
-------------
4.4.2.1 Data items in the SAD. Should this list include the Bypass DF bit
and Bypass DSCP, (copied from the SPD entry)?
-----------------
Sect 5 first paragraph:
"But, if the SPD entries are first decorrelated, then the resulting entries
can safely be cached, and each cached entry will map to exactly one SA, or
indicate that matching traffic should be bypassed or discarded,
appropriately. (Note: The original SPD entry might result in multiple SAs,
e.g., because of PFP.)"
As the text here points out, multiple SAs might be created pursuant to one
SPD entry. But it seems like a bit of a leap from that to saying that each
cached SPD entry maps to one SA. It doesn't even seem correct, unless the
"SPD cache" *by definition of the model* contains entries that map to one
SA each. If that is the case it should be so stated; otherwise the
statement about each cached SPD entry mapping to one SA should be
removed. As far as I can see, nothing is gained by requiring the SPD cache
to be so fine-grained.
-----------------
In sect. 5.1 item 4:
" 4. The packet is passed to the outbound forwarding function (operating
outside of the IPsec implementation), to select the interface to which the
packet will be directed. This function may cause the packet to be passed
back across the IPsec boundary, for additional IPsec processing, e.g., in
support of nested SAs. If so, there MUST be an entry in SPD-I database that
permits inbound bypassing of the packet, otherwise the packet will be
discarded."
I don't understand why the last 2 sentences are there. Let's look at the
case of an overlay network, which I presume is one of the applications that
might cause iterated application of IPsec. After once applying IPsec we
have, say, an ESP packet. We do a forwarding lookup on the dest address of
the ESP packet and that forwarding lookup selects another (or the same)
SPD-O/SPD-S, which the packet is then evaluated against. Where and why
does the SPD-I bypass rule come into play in such a scenario? Where is the
packet "passed back across the IPsec boundary"? I think perhaps there is
more to the model you have in mind here then I am picking up from the text.
Ditto for the similar statement in the Inbound Processing section.
-----------
In sect 5.1.1 2 several cases where packets are dropped are itemized. There
are two categories listed for cases where IKE could not negotiate an
appropriate SA:
" b1. The IPsec system was unable to set up the SA required by the SPD
entry matching the packet because the IPsec peer at the other end of the
exchange is administratively prohibited from communicating with the initiator."
" b2. The IPsec system was unable to set up the SA required by the SPD
entry matching the packet because the IPsec peer at the other end of the
exchange could not be contacted."
These don't seem to cover all the possible reasons the IKE might fail, for
example, the case where the local IPsec device could not successfully
authenticate itself to the remote one. I think that either more reasons
should be added (with appropriate ICMP type and code), or one or both of
the above items should be made more general. For example, b1 could be
generalized to "... because a suitable SA could not be negotiated with the
IPsec peer at the other end."
---------------
In sect 5.1.2 at the bottom of p. 46 there are several references to "DS
field". I believe these are referring specifically to the DS field in the
*outer* IP header. It would be helpful to make that explicit.
-----------
In sect 5.2 p. 51 step 3a it discussed creating an audit log entry. It's
not clear whether the auditable event would be any processing done under
step 3a, or just the multicast case discussed just before the
auditing. But, it doesn't seem in either case that it should be an
auditable event -- there is no error case or unusual occurrence here, just
normal, vanilla processing.
-----------
In sect 7.2 (Separate Tunnel Mode SAs for Non-Initial Fragments):
"Also, because an SA of this sort will carry ALL non- initial fragments
that match a specified Local/Remote address pair and protocol value, users
and administrators are advised to protect such traffic using ESP (with
integrity) and the "strongest" integrity and encryption algorithms
available at both peers."
I think the point here is that the fragments carried on this SA belong to
packets that might have gone on a variety of separate SAs of varying
security, if not for the fragmentation. So I think it makes more sense if we
s/algorithms available at both peers/algorithms in use for any traffic
between both peers/
-------------
In sect. 7.4 (BYPASS/DISCARD traffic) it says "An implementation MUST
support stateful fragment checking to accommodate BYPASS traffic for which
a non-trivial port range is specified." This seems to mandate that an
implementation support the type of stateful fragment checking that is made
a MAY in 7.3.
I propose that this statement be changed to include the alternative of
dropping the non-initial fragments (which should be the normal behavior
*anyway* if there is no applicable SPD policy with port selectors of ANY or
OPAQUE). So I would change the above-quoted sentence to:
"An implementation MAY BYPASS non-initial fragments pursuant to an SPD
policy entry with a non-trivial port range if stateful fragment checking is
performed to verify the applicable ports for those fragments."
----------
In sect 8.2.1 (propagation of PMTU), it says that once it has "learned" a
new PMTU, the IPsec implementation should wait for outbound traffic for the
SA and "When such traffic arrives, if the traffic would exceed the updated
PMTU value the traffic MUST be discarded and an appropriate ICMP PMTU
message sent."
I think that is the correct behavior *if* the packet had DF set, but if it
does not then the IPsec implementation should either fragment then encrypt
or encrypt then fragment, per its configuration.
-----------------
Appendix D has not been updated to align with what was eventually decided,
and so may lead to confusion. Perhaps it should just be dropped?
-------------
Thanks,
Mark