WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt

Post by Theodore Ts'o
Many 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

Stephen Kent

2004-10-22 19:31:55 UTC

Mark,

Karen and I were reviewing all the comments we received during the WG
last call, making final change to 2401bis. Most of your comments were
easy to address, but there were some that require further discussion,

Post by Mark Duffy
"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 general, an entry in the SPD cache points to exactly one SA. this
is what one would expect because the purpose of the cache is to speed
up the mapping of outbound packets to SAs. there are exceptions,
however, and so we will revise the text. exceptions arise when one
uses multiple SAs to carry traffic of different priorities (e.g., as
indicated by distinct DSCP values) but with the same selectors, on
different SAs.

Post by Mark Duffy
" 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.

Once a packet has crossed the IPsec boundary, it cannot be processed
via IPsec again, unless it is bypassed, i.e., lopped. this is true in
both directions, inbound or outbound. If one requires multiple passes
through IPsec to protect a packet, then one must have entries in the
SPD-O/I caches to allow such bypassing, as illustrated in Appendix E.

Post by Mark Duffy
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
"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."

Yes, 7.3 is a MAY, but that's for protected traffic, not for BYPASS
traffic. The debate over fragment handling for IPsec-protected
traffic spilled over into BYPASS traffic as well, as documented in
Appendix D. I don't recall messages that suggest the WG decided to
drop the requirement to support fragment reassembly for BYPASS
fragments. If you can point me to the relevant messages, then we
will change the text as you suggest.

Post by Mark Duffy
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.

Tbe processing described above is correct for IPv4 when the DF bit is
set, as you noted. It also is appropriate for IPv6, because we can't
fragment on the plaintext side for v6. maybe we could fragment on the
ciphertext side, but that is still not in the spirit of v6, since we
are an intermediate system performing fragmentation. The question is
very poor performance that results for v4 or v6 if we fragment. How
about compromise: for v6 we send the PMTU and drop the packet, as
now described; for v4 we send the PMTU message, but still pass the
packet, fragmenting on either side as configured.

Post by Mark Duffy
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?

We were explicitly asked to preserve the analysis that motivated the
final text in 2401bis, hence the appendix in question. The Appendix
presents arguments for different approaches, and ends with the
observation that we settled for one MUST and two MAYs. other than the
question about fragment reassembly for BYPASS traffic, what parts of
it do you feel are no longer consistent with the final text?

Steve

Mark Duffy

2004-10-27 20:03:58 UTC

Hi Steve and Karen, and thanks again for your efforts. I've responded
below for each item.
--Mark

Mark,
Karen and I were reviewing all the comments we received during the WG last
call, making final change to 2401bis. Most of your comments were easy to
address, but there were some that require further discussion, or which we

Post by Mark Duffy
"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 general, an entry in the SPD cache points to exactly one SA. this is
what one would expect because the purpose of the cache is to speed up the
mapping of outbound packets to SAs. there are exceptions, however, and so
we will revise the text. exceptions arise when one uses multiple SAs to
carry traffic of different priorities (e.g., as indicated by distinct DSCP
values) but with the same selectors, on different SAs.

I agree that if one is using the SPD cache to speed up the mapping of
outbound packets one would like to have one cache entry per SA
(**). However, it is my understanding that the purpose of the SPD cache
*in the context of the 2401bis document* is not to speed up execution but
to model the desired behavior under the standard. Therefore I suggest two
changes to the wording:

. State somewhere that for the purposes of this specification, it is
assumed that there is one SPD cache entry for every SA (**).

. The wording from rfc2401bis-03 that is quoted above implies that the
cache-entry-per-SA is a *consequence* of the decorrelation, i.e. it says
"... if the SPD entries are first decorrelated, then ... and each cached
entry will map to exactly one SA ...". This was the cause of my original
comment. I suggest changing this text to e.g.
"But, if the SPD entries are first decorrelated, then the resulting
entries can safely be cached. Each cached entry will indicate that
matching traffic should be bypassed or discarded, appropriately."

(**) I agree that multiple SAs for the same selector set but for different
DSCPs would share an SPD cache entry. One way to capture this would be to
replace statements like:
"each cached entry will map to exactly one SA, or ... bypassed or
discarded" with:
"each cached entry will map to one or more SAs with the same selector
set, or ... bypassed or discarded"

Post by Mark Duffy
" 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.

Once a packet has crossed the IPsec boundary, it cannot be processed via
IPsec again, unless it is bypassed, i.e., lopped. this is true in both
directions, inbound or outbound. If one requires multiple passes through
IPsec to protect a packet, then one must have entries in the SPD-O/I
caches to allow such bypassing, as illustrated in Appendix E.

The way I am looking at it, once a SG has applied tunnel mode IPsec to a
packet, it has created a *new* IP packet that is from the SG itself. I
view this new packet as originating *inside* the IPsec boundary (comparable
to the way that, say, IKE packets from the SG originate from inside the
IPsec boundary).

If on the other hand an SG is to view the tunnel mode packet that it just
created as having arrived from outside the IPsec boundary, that seems to me
to be quite confusing. What interface would it be considered to have
arrived from? Which (of potentially multiple) SPDs should be used for the
pseudo-inbound processing? How do I (configuring the policy) distinguish
these packets from ones that really came in off the network? At the bottom
line, why should an SG treat an IPsec packet that it just created as though
it just arrived on an unprotected interface?

Post by Mark Duffy
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
"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."

Yes, 7.3 is a MAY, but that's for protected traffic, not for BYPASS
traffic. The debate over fragment handling for IPsec-protected traffic
spilled over into BYPASS traffic as well, as documented in Appendix D. I
don't recall messages that suggest the WG decided to drop the requirement
to support fragment reassembly for BYPASS fragments. If you can point me
to the relevant messages, then we will change the text as you suggest.

I don't know of any relevant messages, either for or against this, for
bypass traffic. However, it seems to me that the whole stateful fragment
checking question is about the same for PROTECT and for BYPASS. I think
all the same arguments could be made on all sides. Therefore I would
assume that the decision reached should be the same for PROTECT and for
BYPASS.

Since we had the big discussion for PROTECT and decided that stateful
fragment checking is a MAY, I would expect the same conclusion to apply for
BYPASS. However, you seem to be taking the position that unless this was
specifically discussed for BYPASS, that the standard in this area is
defaulting to MUST. I don't see why that should be the case.

Post by Mark Duffy
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.

Tbe processing described above is correct for IPv4 when the DF bit is set,
as you noted. It also is appropriate for IPv6, because we can't fragment
on the plaintext side for v6. maybe we could fragment on the ciphertext
side, but that is still not in the spirit of v6, since we are an
intermediate system performing fragmentation. The question is very poor
performance that results for v4 or v6 if we fragment. How
about compromise: for v6 we send the PMTU and drop the packet, as now
described; for v4 we send the PMTU message, but still pass the packet,
fragmenting on either side as configured.

Let me break it into 3 cases:

1. Original (cleartext) packet is IPv4 and has DF set:
I think you and I are agreed that it should discard the packet, and send a
PMTU ICMP message.

2. Original (cleartext) packet is IPv4 and has DF clear:
I think you are suggesting that the IPsec implementation send a PMTU ICMP
message but also fragment (before or after IPsec) and forward the
packet. I disagree with that. I agree it should fragment and forward the
packet, but I DO NOT agree that it should send the PMTU ICMP. The reason
is that the ICMP message that would be sent is type 3 (Destination
Unreachable) code 4 ("fragmentation needed and DF set"). I do not think it
is good practice to send "fragmentation needed and DF set" in cases where
DF was not set.

3. Original (cleartext) packet is IPv6:
I think you and I are agreed that this should be treated just like case 1.

BTW I think the above cases cover all cases, regardless of whether a tunnel
mode IPsec encapsulation would be IPv4 or v6.

Post by Mark Duffy
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?

We were explicitly asked to preserve the analysis that motivated the final
text in 2401bis, hence the appendix in question. The Appendix presents
arguments for different approaches, and ends with the observation that we
settled for one MUST and two MAYs. other than the question about fragment
reassembly for BYPASS traffic, what parts of it do you feel are no longer
consistent with the final text?

Re-reading the appendix now, it doesn't strike me as badly as last time :-)
so I will largely withdraw this complaint. The only thing I see from a
quick look (maybe only a nit, I'll concede):

"...essentially create a "non-initial fragment only" SA, precisely the
solution that the WG rejected." and
"The Working Group rejected the convention of creating an SA to carry only
non-initial fragments"
As reflected in sect 7.2, separate SAs may be used for non-initial fragments.

Stephen Kent

2004-10-29 22:55:11 UTC

Mark,

Section 5, first para:
I think we can change the text discussing SPD cache entries and SAs
to avoid the unintended implication you noted. As you said, the
cache model is adopted to simplify presentation and there was no
intent to suggest that the mapping to a single SA is a side effect of
the cache use and an efficiency issue. So, with the caveats we noted
re multiple SAs for DSCP, etc., I think this issue is now closed.

<SNIP>

Once a packet has crossed the IPsec boundary, it cannot be
processed via IPsec again, unless it is bypassed, i.e., lopped.
this is true in both directions, inbound or outbound. If one
requires multiple passes through IPsec to protect a packet, then
one must have entries in the SPD-O/I caches to allow such
bypassing, as illustrated in Appendix E.

The new, tunneled packet is inside the IPsec boundary, but it is past
the point where we do outbound packet lookups. That was a major
motivation re simplifying the processing model, i.e., avoiding
looping inside of the IPsec boundary in support of nesting. This
notion has been stable for quite a while, as we removed the
requirement for support of SA bundles. the last list discussion of
this took place back in early August when Mike Roe sent a message
asking for clarification on how to set up entries in forwarding
tables and in the SPD to effect the looping needed for nested SAs.

Post by Mark Duffy
If on the other hand an SG is to view the tunnel mode packet that it
just created as having arrived from outside the IPsec boundary, that
seems to me to be quite confusing. What interface would it be
considered to have arrived from? Which (of potentially multiple)
SPDs should be used for the pseudo-inbound processing? How do I
(configuring the policy) distinguish these packets from ones that
really came in off the network? At the bottom line, why should an
SG treat an IPsec packet that it just created as though it just
arrived on an unprotected interface?

I think the question of how one treats a packet as it emerges from
IPsec processing is well illustrated in the set of figures we have
added to 2401bis, going back to December of 2003. Figure 2 shows the
output from AH/ESP processing going to the forwarding function, and
shows a path from that function, through the SPD-I, and back to the
SPD-selection function. This was described precisely to support the
looping needed for nested SA processing.

Still, let me answer the questions you raised. As per figure 2, this
traffic goes from the forwarding module to the SPD-I. The inbound
traffic discussion on page 52 says that a packet MAY be tagged with
the interface IF that is necessary to support different SPD-Is. I
guess we could say, in the outbound processing discussion, that if
necessary, the traffic being looped back could be tagged as coming
from this internal interface, if necessary, i.e., if there is more
than one SPD-I. That would allow use of a different SPD-I for "real"
external traffic vs. looped traffic, if needed. The example we gave
in Appendix ?? did not make that assumption, i.e., it used just one
SPD-I, which is the default. the bottom line is that we have said for
about a year that this is how we would loop packets to effect nested
SA processing.

In sect. 7.4 (BYPASS/DISCARD traffic)

<SNIP>
Since we had the big discussion for PROTECT and decided that
stateful fragment checking is a MAY, I would expect the same
conclusion to apply for BYPASS. However, you seem to be taking the
position that unless this was specifically discussed for BYPASS,
that the standard in this area is defaulting to MUST. I don't see
why that should be the case.

I am not sure that we defaulted a MUST for fragment reassembly for
BYPASS, after deciding to make it a MAY for protected traffic. I
thought that we changed it to MUST after some discussion on the list,
after having listed it as MAY/SHOULD in the earlier draft, but I may
be wrong. How about a quick straw poll, so we can make the word be
MUST or MAY, depending on what folks decide.

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.

Tbe processing described above is correct for IPv4 when the DF bit
is set, as you noted. It also is appropriate for IPv6, because we
can't fragment on the plaintext side for v6. maybe we could
fragment on the ciphertext side, but that is still not in the
spirit of v6, since we are an intermediate system performing
fragmentation. The question is very poor performance that results
for v4 or v6 if we fragment. How about compromise: for v6 we send
the PMTU and drop the packet, as now described; for v4 we send the
PMTU message, but still pass the packet, fragmenting on either side
as configured.

I think you and I are agreed that it should discard the packet, and
send a PMTU ICMP message.

right.

Post by Mark Duffy
I think you are suggesting that the IPsec implementation send a PMTU
ICMP message but also fragment (before or after IPsec) and forward
the packet. I disagree with that. I agree it should fragment and
forward the packet, but I DO NOT agree that it should send the PMTU
ICMP. The reason is that the ICMP message that would be sent is
type 3 (Destination Unreachable) code 4 ("fragmentation needed and
DF set"). I do not think it is good practice to send "fragmentation
needed and DF set" in cases where DF was not set.

whoops, good point. I guess we should just wait for hosts behind an
SG to send traffic with DF set as part of PMTU discovery, and act
accordingly. OK.

Post by Mark Duffy
I think you and I are agreed that this should be treated just like case 1.

right.

Post by Mark Duffy
BTW I think the above cases cover all cases, regardless of whether a
tunnel mode IPsec encapsulation would be IPv4 or v6.

agreed.

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?

We were explicitly asked to preserve the analysis that motivated
the final text in 2401bis, hence the appendix in question. The
Appendix presents arguments for different approaches, and ends with
the observation that we settled for one MUST and two MAYs. other
than the question about fragment reassembly for BYPASS traffic,
what parts of it do you feel are no longer consistent with the
final text?

Re-reading the appendix now, it doesn't strike me as badly as last
time :-) so I will largely withdraw this complaint. The only thing
"...essentially create a "non-initial fragment only" SA, precisely
the solution that the WG rejected." and
"The Working Group rejected the convention of creating an SA to
carry only non-initial fragments"
As reflected in sect 7.2, separate SAs may be used for non-initial fragments.

we'll revisit that chunk of text.

Steve

Mark Duffy

2004-11-01 22:50:26 UTC

Hi Steve,

There were several issues in this email thread. I think all are resolved
except stateful fragment bypass. Please see below. --Thanks, Mark

Mark,
I think we can change the text discussing SPD cache entries and SAs to
avoid the unintended implication you noted. As you said, the cache model
is adopted to simplify presentation and there was no intent to suggest
that the mapping to a single SA is a side effect of the cache use and an
efficiency issue. So, with the caveats we noted re multiple SAs for DSCP,
etc., I think this issue is now closed.

great

<SNIP>

Once a packet has crossed the IPsec boundary, it cannot be processed via
IPsec again, unless it is bypassed, i.e., lopped. this is true in both
directions, inbound or outbound. If one requires multiple passes through
IPsec to protect a packet, then one must have entries in the SPD-O/I
caches to allow such bypassing, as illustrated in Appendix E.

The new, tunneled packet is inside the IPsec boundary, but it is past the
point where we do outbound packet lookups. That was a major motivation re
simplifying the processing model, i.e., avoiding looping inside of the
IPsec boundary in support of nesting. This notion has been stable for
quite a while, as we removed the requirement for support of SA bundles.
the last list discussion of this took place back in early August when Mike
Roe sent a message asking for clarification on how to set up entries in
forwarding tables and in the SPD to effect the looping needed for nested SAs.

Post by Mark Duffy
If on the other hand an SG is to view the tunnel mode packet that it just
created as having arrived from outside the IPsec boundary, that seems to
me to be quite confusing. What interface would it be considered to have
arrived from? Which (of potentially multiple) SPDs should be used for
the pseudo-inbound processing? How do I (configuring the policy)
distinguish these packets from ones that really came in off the
network? At the bottom line, why should an SG treat an IPsec packet that
it just created as though it just arrived on an unprotected interface?

I think the question of how one treats a packet as it emerges from IPsec
processing is well illustrated in the set of figures we have added to
2401bis, going back to December of 2003. Figure 2 shows the output from
AH/ESP processing going to the forwarding function, and shows a path from
that function, through the SPD-I, and back to the SPD-selection function.
This was described precisely to support the looping needed for nested SA
processing.
Still, let me answer the questions you raised. As per figure 2, this
traffic goes from the forwarding module to the SPD-I. The inbound traffic
discussion on page 52 says that a packet MAY be tagged with the interface
IF that is necessary to support different SPD-Is. I guess we could say, in
the outbound processing discussion, that if necessary, the traffic being
looped back could be tagged as coming from this internal interface, if
necessary, i.e., if there is more than one SPD-I. That would allow use of
a different SPD-I for "real" external traffic vs. looped traffic, if
needed. The example we gave in Appendix ?? did not make that assumption,
i.e., it used just one SPD-I, which is the default. the bottom line is
that we have said for about a year that this is how we would loop packets
to effect nested SA processing.

I'm all for removal of the SA bundles, and using looping where multiple
encapsulations are required. I had not previously understood this
ramification about bypassing through the SPD-O/I. However, I can live with it.

In sect. 7.4 (BYPASS/DISCARD traffic)

<SNIP>
Since we had the big discussion for PROTECT and decided that stateful
fragment checking is a MAY, I would expect the same conclusion to apply
for BYPASS. However, you seem to be taking the position that unless this
was specifically discussed for BYPASS, that the standard in this area is
defaulting to MUST. I don't see why that should be the case.

I am not sure that we defaulted a MUST for fragment reassembly for BYPASS,
after deciding to make it a MAY for protected traffic. I thought that we
changed it to MUST after some discussion on the list, after having listed
it as MAY/SHOULD in the earlier draft, but I may be wrong. How about a
quick straw poll, so we can make the word be MUST or MAY, depending on
what folks decide.

I'll post a separate message on this one, to facilitate discussion.

In sect 8.2.1 (propagation of PMTU), it says that once it has "learned" a

[...]

Post by Mark Duffy
I think you are suggesting that the IPsec implementation send a PMTU ICMP
message but also fragment (before or after IPsec) and forward the
packet. I disagree with that. I agree it should fragment and forward
the packet, but I DO NOT agree that it should send the PMTU ICMP. The
reason is that the ICMP message that would be sent is type 3 (Destination
Unreachable) code 4 ("fragmentation needed and DF set"). I do not think
it is good practice to send "fragmentation needed and DF set" in cases
where DF was not set.

whoops, good point. I guess we should just wait for hosts behind an SG to
send traffic with DF set as part of PMTU discovery, and act accordingly. OK.

great.

Mark Duffy

2004-11-02 20:45:54 UTC

(subject changed from Re: [Ipsec] WORKING GROUP LAST
CALL: draft-ietf-ipsec-rfc2401bis-03.txt)

Please see below.

Post by Mark Duffy
In sect. 7.4 (BYPASS/DISCARD traffic)

[snip]

[sk] I am not sure that we defaulted a MUST for fragment reassembly for
BYPASS, after deciding to make it a MAY for protected traffic. I thought
that we changed it to MUST after some discussion on the list, after having
listed it as MAY/SHOULD in the earlier draft, but I may be wrong. How
about a quick straw poll, so we can make the word be MUST or MAY,
depending on what folks decide.

I looked a bit at the "paper" trail. The -02 draft (last paragraph of
sect. 7) specified MAY/SHOULD stateful fragment checking for
BYPASS/DISCARD. Subsequently, Tero Kivinen described a possible attack on
1 Jun 04 <http://www.vpnc.org/ietf-ipsec/mail-archive/msg03576.html> (near
the bottom of the message).

The attack example that is now in the -04 draft is not the same as Tero's
example and I think it needs correction (see below). At the same time,
Tero's description does not mention that the attacker would need to guess
the Identification field and source port of the protected packet in order
to carry out the attack. This would make the attack quite a bit harder
against encrypted packets (but not for packets protected with auth only).

Fixing the description of this attack in 2401bis-04:

The case described in 7.4 is one where (for example)
traffic for (SA1, DA1, tcp, DP1) is IPsec-protected and
traffic for (SA1, DA1, tcp, DP2) is BYPASSed.
This is actually not vulnerable to Tero's attack because without stateful
inspection, non-initial fragments for DP2 would not be BYPASSed. Rather,
the attack Tero described requires that there be a BYPASS rule for dest
port of ANY or OPAQUE, e.g.
traffic for (SA1, DA1, tcp, DP=ANY) is bypassed.
*That* SPD entry would, in the absence of stateful fragment checking, allow
non-initial fragments to pass and corrupt the reassembled datagram.

P.S. The existing example uses port 25=telnet. In fact, telnet is port 23.

Why stateful fragment checking for BYPASS is not sufficient:

I believe that stateful fragment checking for BYPASS does not preclude this
attack and in fact makes it worse. Assume we have an SPD that says:
1. SA=sa1, SP=any, prot=tcp, DA=da1, DP=25 ==> protect
2. SA=sa1, SP=any, prot=tcp, DA=da1, DP=ANY ==> bypass.
Further, assume that stateful fragment checking is done for the bypass.
Now, telnet user creates and sends a fragmented packet with (SA=sa1,
SP=2222, prot=tcp, DA=da1, DP=25)
The fragments of this packet are protected by an SA created per rule 1.
Attacker removes one or more of the protected non-initial fragments.
Attacker observes (or guesses) the Ident and SP for those fragments.
Attacker creates a new packet with (SA=sa1, SP=2222, prot=tcp, DA=da1,
DP=3333) and with the given Ident value. I.e. everything is the same
except the dest port and the data.
Attacker breaks that packet into fragments and sends them.
The security gateway, with stateful fragment checking, passes all the
fragments pursuant to SPD rule 2.
Destination host might assemble the non-initial fragments onto either
initial fragment (the legit one to port 25 or the bogus one to port
3333). If it assembles them onto the one with DP=25, the attack has succeeded.

Stateful fragment checking for bypass actually makes this worse because
without it, the hostile non-initial fragments will only be bypassed if
there is an SPD entry for DP=ANY (or OPAQUE). With stateful checking, the
hostile fragments can also be bypassed pursuant to SPD entries that have
non-trivial port selectors.

My recommendation:

As far as I can see the SG behavior that completely precludes this attack
is for the SG to disallow BYPASS forwarding of any non-initial
fragments. So that should be the required default behavior. Stateful
fragment checking for bypass could be a MAY but with a stern warning about
the possibility of this attack.

Thanks,
Mark

Tero Kivinen

2004-11-03 09:20:50 UTC

Stateful fragment checking is sufficient if and only if it is done
for all traffic, including BYPASS and PROTECTED traffic.

Post by Mark Duffy
I believe that stateful fragment checking for BYPASS does not preclude this
1. SA=sa1, SP=any, prot=tcp, DA=da1, DP=25 ==> protect
2. SA=sa1, SP=any, prot=tcp, DA=da1, DP=ANY ==> bypass.
Further, assume that stateful fragment checking is done for the bypass.

Lets also assume that the stateful fragment checking is also done for
the protected data.

Post by Mark Duffy
Now, telnet user creates and sends a fragmented packet with (SA=sa1,

^^^^^^
smtp :-)

Post by Mark Duffy
SP=2222, prot=tcp, DA=da1, DP=25)
The fragments of this packet are protected by an SA created per rule 1.
Attacker removes one or more of the protected non-initial fragments.
Attacker observes (or guesses) the Ident and SP for those fragments.
Attacker creates a new packet with (SA=sa1, SP=2222, prot=tcp, DA=da1,
DP=3333) and with the given Ident value. I.e. everything is the same
except the dest port and the data.
Attacker breaks that packet into fragments and sends them.
The security gateway, with stateful fragment checking, passes all the
fragments pursuant to SPD rule 2.

Hmmm.. depends how the statefull fragment checking is done. If it is
done in the style where the packets are queue up until first fragment
is seen, then the first fragment is processed, and rest of the
fragments go through exactly same SA processing than the first
fragment (i.e. it will insert entry to the fragment cache pointing
from src-IP, dst-IP, frag-ID -> SAD-entry, where SAD-entry can be
protect with SPI xxxx, or bypass).

This would mean that either the attacker generated plaintext packets
are discarded as they are not protected if the real first fragment was
processed first, or the protected fragments are sent through without
decryption (bypassed) in case the attacker generated first frament was
processed.

Post by Mark Duffy
Destination host might assemble the non-initial fragments onto
either initial fragment (the legit one to port 25 or the bogus one
to port 3333). If it assembles them onto the one with DP=25, the
attack has succeeded.

That would require the SGW to do both BYPASS and PROTECT processing
for some of the fragments simultaneusly. If the SGW will only do one
of those at time, and its fragment cache has longer timeouts than the
end host, then the end host will be protected.

Post by Mark Duffy
Stateful fragment checking for bypass actually makes this worse because
without it, the hostile non-initial fragments will only be bypassed if
there is an SPD entry for DP=ANY (or OPAQUE). With stateful checking, the
hostile fragments can also be bypassed pursuant to SPD entries that have
non-trivial port selectors.
As far as I can see the SG behavior that completely precludes this attack
is for the SG to disallow BYPASS forwarding of any non-initial
fragments. So that should be the required default behavior. Stateful
fragment checking for bypass could be a MAY but with a stern warning about
the possibility of this attack.

Hmmm. I can agree that disallowing BYPASS for fragments does protect
the traffic, but I think stateful fragment checking (if properly done)
for all traffic is the safest way to allow fragments and BYPASS rules.

--
***@safenet-inc.com

Mark Duffy

2004-11-03 22:35:42 UTC

At 04:20 AM 11/3/2004, Tero Kivinen wrote:
[snip]

Post by Tero Kivinen
Hmmm.. depends how the statefull fragment checking is done. If it is
done in the style where the packets are queue up until first fragment
is seen, then the first fragment is processed, and rest of the
fragments go through exactly same SA processing than the first
fragment (i.e. it will insert entry to the fragment cache pointing
from src-IP, dst-IP, frag-ID -> SAD-entry, where SAD-entry can be
protect with SPI xxxx, or bypass).
This would mean that either the attacker generated plaintext packets
are discarded as they are not protected if the real first fragment was
processed first, or the protected fragments are sent through without
decryption (bypassed) in case the attacker generated first frament was
processed.

That's all fine as far as it goes. But I think there are other cases to be
considered. While they are probably less likely, I don't think we can
assume they will never arise. Here are a few:

1. When PROTECTed fragments are handled per sect 7.2 (2401bis-04) there is
not stateful checking of these fragments so they wouldn't be blocked in
that way.

2. If the SG implementation is such that its fragment cache is closely
integrated with its SPD cache (or with a stateful firewall), then a
PROTECTed and a BYPASSed packet with the same {SA, DA, Ident} but with
different Protocol, SP, or DP might have their stateful fragment processing
done separately (keyed by more than just {SA, DA, IDent} and simultaneously
without interfering with each other.

3. If the SG implementation frees its fragment cache entry as soon as all
fragments have been forwarded, it could pass all frags of a legitimate
packet first then all frags of an attack packet next. And then those
fragments could be reordered in the network prior to delivery to the
destination.

Any of these cases could lead to an attacker corrupting a packet that had
been PROTECTed.

In general, I think that
-if there is any way for non-initial fragments from an attacker to
transit an SG
-and the attacker can guess or observe that there is fragmentation
-and the attacker can guess or observe the SA, DA, and Ident of a
fragmented packet
Then the attacker may be able to corrupt the reassembled victim packet.

The "hostile" fragments don't even have to be BYPASSed, they can be
PROTECTed and statefully checked!

--Mark

Tero Kivinen

2004-11-04 09:25:51 UTC

Post by Mark Duffy
1. When PROTECTed fragments are handled per sect 7.2 (2401bis-04) there is
not stateful checking of these fragments so they wouldn't be blocked in
that way.

If you are using 7.2 then the receiving SGW will throw away all
non-initial fragments coming outside the special non-initial fragments
SA, as they do not match the required protection for the traffic (i.e.
if the local SGW is configured to use separate SA for non-initial
fragments, it will also require it for incoming non-initial
fragments).

So no problem there.

Post by Mark Duffy
2. If the SG implementation is such that its fragment cache is closely
integrated with its SPD cache (or with a stateful firewall), then a
PROTECTed and a BYPASSed packet with the same {SA, DA, Ident} but with
different Protocol, SP, or DP might have their stateful fragment processing
done separately (keyed by more than just {SA, DA, IDent} and simultaneously
without interfering with each other.

The statefull fragment checking should be so that external body cannot
distinguish it from the reassembly + refragmentation with identical
boundaries and identical fragment id. So if the SGW is not following
that, but uses extra information when processing packets then it is
incorrect.

Post by Mark Duffy
3. If the SG implementation frees its fragment cache entry as soon as all
fragments have been forwarded, it could pass all frags of a legitimate
packet first then all frags of an attack packet next. And then those
fragments could be reordered in the network prior to delivery to the
destination.

I would consider such SG implementation quite bad. It would not be
incorrect, but it is little bit unsecure way to implement it. Note,
that using this to attack the end host requires attacker to do some
other attacks to, normally he cannot force reordering of the packets
happening inside the network after SGW.

Post by Mark Duffy
Any of these cases could lead to an attacker corrupting a packet that had
been PROTECTed.

Only if the SGW implementation is also badly implemented. SGW is
designed to protect the hosts behind it, so it should be correctly
implemented, and also it should have more stricter rules than normal
hosts (i.e. keep checking the fragments for little bit longer etc).

Post by Mark Duffy
In general, I think that
-if there is any way for non-initial fragments from an attacker to
transit an SG
-and the attacker can guess or observe that there is fragmentation
-and the attacker can guess or observe the SA, DA, and Ident of a
fragmented packet
Then the attacker may be able to corrupt the reassembled victim packet.

That makes the attack quite hard already, and I still do not think
the attacks would work against the stateful fragment checking,
especially if it is implemented in the "collect all fragments, just
like doing reassembly - then send them out" format (very inefficient
and expensive, but the safe way to do it). All other implementations
of stateful fragment checking should have similar properties than to
that version. You can make optimizations to that, but you need to keep
the security properties of that original model.

Post by Mark Duffy
The "hostile" fragments don't even have to be BYPASSed, they can be
PROTECTed and statefully checked!

In that case either the policy is unsecure or the attacker is behind
the another SGW, in which case the SGW's are not supposed to protect
against those attacks (i.e. if they are allowed by policy, then the
attacks are allowed by policy :-)

--
***@safenet-inc.com

Mark Duffy

2004-11-05 05:02:40 UTC

Hi Tero,

I largely agree with your refutations of the 3 attack cases I put forth,
though I am leery of relying on SGs to do stateful fragment handling
"correctly" without a clear specification of what that means.

I also think it may be possible under misconfiguration, if the one SG has
multiple SPDs or if there are multiple SGs to the same enterprise, that
non-initial fragments for the same {SA, DA, Ident} may be passed via two
separate paths and thus permit a fragment overwrite attack. There could be
multiple SAs (from different peers) for the same {SA, DA, protocol} and/or
one SA and a BYPASS policy.

In general, I just do not feel highly confident that there is no way for an
attacker to pass non-initial fragments having the same SA,DA as legit
fragments.

Therefore I still assert that SGs MUST support the option to block all
non-initial fragments (which is already the case anyway due to other, more
general requirements). I think stateful fragment checking for BYPASS
should be a MAY at best, since passing these fragments, even with stateful
checking, seems to present certain security risks as noted above. We might
want to also consider a MAY/SHOULD that the SG actually reassemble the
fragments; has that been discussed previously?

--Mark

Post by Mark Duffy
1. When PROTECTed fragments are handled per sect 7.2 (2401bis-04)

there is

Post by Mark Duffy
not stateful checking of these fragments so they wouldn't be blocked in
that way.

processing

Post by Mark Duffy
done separately (keyed by more than just {SA, DA, IDent} and

simultaneously

Post by Mark Duffy
without interfering with each other.

Post by Mark Duffy
Any of these cases could lead to an attacker corrupting a packet that had
been PROTECTed.

Post by Mark Duffy
The "hostile" fragments don't even have to be BYPASSed, they can be
PROTECTed and statefully checked!

Theodore Ts'o

2004-11-05 14:24:52 UTC

Post by Mark Duffy
Therefore I still assert that SGs MUST support the option to block all
non-initial fragments (which is already the case anyway due to other, more
general requirements). I think stateful fragment checking for BYPASS
should be a MAY at best, since passing these fragments, even with stateful
checking, seems to present certain security risks as noted above.

How fragments should be handled has been a subject of a long, intense
discussion in past months. A very large number of arguments were made
and remade about which strategies are MUST/SHOULD/MAY, and while we
finally achieved what I can only call rough consensus on our current
set of MUST/SHOULD's.

It is for this reason that we preserved the "legislative history" in
Appendix D of rfc2401-bis, and section D.8 reads as follows:

There is no simple, uniform way to handle fragments in all contexts.
Different approaches work better in different contexts. Thus this
document offers 3 choices -- one MUST and two MAYs. At some point in
the future, if the community gains experience with the two MAYs, they
may become SHOULDs or MUSTs or other approaches may be proposed.

Beyond this point, we had declared this issue closed, so that the
working group could make forward progress. While we could reopen this
issue if there was a significant technical defect that had since been
discovered, the concerns which you have raised don't appear to rise to
this level. Yes, there are ways that a naive implementor could create
an insecure implementation. But is that is true of pretty much all
security systems, and I believe you and Tero agree that it is possible
to do stateful fragment checking (ultimately which is a MAY).

As the working group had discussed, there does seem to be general
agreement that many, if not most sites aren't even doing port-specific
SA's, but instead use tunnel mode SA's that are configured to pass
traffic without regard to the port field. This is why section 7.1 is
a MUST, and the alternative approaches in section 7.2 and 7.3 are
MAY's.

I must therefore question whether it is worth holding up the entire
rfc2401bis document over what seems minor points for a usage case that
is outside of what is currently the common use of ipsec. Especially
given that section D.8 calls out the fact that we may change how we
handle this in the future, have we not reached the point where it is
time to shoot the engineers and ship the product?

Post by Mark Duffy
We might
want to also consider a MAY/SHOULD that the SG actually reassemble the
fragments; has that been discussed previously?

In fact, the current text of rfc2401-bis states (in section 7.3):

This standard does not
specify how peers will deal with such fragments, e.g., via reassembly
or other means, at either sender or receiver. However, a receiver
MUST discard non-initial fragments that arrive on an SA with non-

So reassembly is explicitly listed as a way of implementing stateful
fragment checking.

- Ted

Mark Duffy

2004-11-05 16:14:55 UTC

Hi Ted, and thanks for responding on this.

Let me summarize in just a few points:

. Most of the "long, intense discussion" was about PROTECTed packets, not
about BYPASSed packets which are currently at issue.

. The "one MUST and two MAYs" (7.1, 7.2, 7.3) you cite below are for
PROTECTed packets. For BYPASS we currently have only MUST (sect 7.4) for
stateful fragment checking.

. D.4 explains the rationale for the MUST on BYPASS, based on a particular
attack it might counter.

. I have questioned whether stateful fragment checking on BYPASS actually
does counter the proposed attack, and suggested that as a result it should
be reduced from a MUST to a MAY.

Now, I can see that this issue has not raised a lot of interest or concern
and I do not want to hold up the process so I will not press further.

--Thanks, Mark

Post by Theodore Ts'o
How fragments should be handled has been a subject of a long, intense
discussion in past months. A very large number of arguments were made
and remade about which strategies are MUST/SHOULD/MAY, and while we
finally achieved what I can only call rough consensus on our current
set of MUST/SHOULD's.
It is for this reason that we preserved the "legislative history" in
There is no simple, uniform way to handle fragments in all contexts.
Different approaches work better in different contexts. Thus this
document offers 3 choices -- one MUST and two MAYs. At some point in
the future, if the community gains experience with the two MAYs, they
may become SHOULDs or MUSTs or other approaches may be proposed.
Beyond this point, we had declared this issue closed, so that the
working group could make forward progress. While we could reopen this
issue if there was a significant technical defect that had since been
discovered, the concerns which you have raised don't appear to rise to
this level. Yes, there are ways that a naive implementor could create
an insecure implementation. But is that is true of pretty much all
security systems, and I believe you and Tero agree that it is possible
to do stateful fragment checking (ultimately which is a MAY).
As the working group had discussed, there does seem to be general
agreement that many, if not most sites aren't even doing port-specific
SA's, but instead use tunnel mode SA's that are configured to pass
traffic without regard to the port field. This is why section 7.1 is
a MUST, and the alternative approaches in section 7.2 and 7.3 are
MAY's.
I must therefore question whether it is worth holding up the entire
rfc2401bis document over what seems minor points for a usage case that
is outside of what is currently the common use of ipsec. Especially
given that section D.8 calls out the fact that we may change how we
handle this in the future, have we not reached the point where it is
time to shoot the engineers and ship the product?

Theodore Ts'o

2004-11-05 21:49:54 UTC

Mark,

Thanks for the summary, and my apologies for missing the thrust of
your concern, which was for handling of packets which are to BYPASS
ipsec processing.

Rereading the thread with this in mind, I am certainly sympathetic to
your concerns. Certainly one argument in favor of your position is
that by requiring stateful fragment checking for BYPASS traffic
complicates the implementation, where as simply prohibiting fragments
for fragment traffic is much simpler. Furthermore, by requiring the
stateful fragment checking machinery in 7.4, that will tend to
influence implementations to implement the MAY in section 7.3, which
is a minus to those who were opposed to section 7.3 on the grounds of
added implementation complexity.

As far as some of your comments about the pitfalls about implementing
the stateful fragment checking, I'm sure that we could always come up
with more text about how to do this securely, either now or in a
future document. I will note though that this is hardly new ground,
as those who have had to implement stateful fragment checking in
firewalls have had to cover 95% of this ground already.

However, BYPASS checking, in that it does not require interoperability
with another ipsec peer, is one of those things that we can tweak at a
later time (or that a vendor can fudge in their implementation)
without impacting interoperability. So this is something that we can
change in a future document, either by amplifying the specification of
how to do the stateful fragment checking (which has been deliberately
underspecified in sections 7.3 and 7.4), or by allowing some other
variant behaviour.

So if you are indeed content to not press this issue at this time, I
think many people will thank you for your forbearance; but if you or
anyone else feel very strongly that we should make a change, now, just
before we go to IETF-wide last call, or during IETF-wide last call, is
the last chance to make changes during this rev of the document.

- Ted

Post by Mark Duffy
. Most of the "long, intense discussion" was about PROTECTed packets, not
about BYPASSed packets which are currently at issue.
. The "one MUST and two MAYs" (7.1, 7.2, 7.3) you cite below are for
PROTECTed packets. For BYPASS we currently have only MUST (sect 7.4) for
stateful fragment checking.
. D.4 explains the rationale for the MUST on BYPASS, based on a particular
attack it might counter.
. I have questioned whether stateful fragment checking on BYPASS actually
does counter the proposed attack, and suggested that as a result it should
be reduced from a MUST to a MAY.
Now, I can see that this issue has not raised a lot of interest or concern
and I do not want to hold up the process so I will not press further.
--Thanks, Mark

Paul Hoffman / VPNC

2004-11-06 02:40:40 UTC

Post by Theodore Ts'o
So if you are indeed content to not press this issue at this time, I
think many people will thank you for your forbearance; but if you or
anyone else feel very strongly that we should make a change, now, just
before we go to IETF-wide last call, or during IETF-wide last call, is
the last chance to make changes during this rev of the document.

Phrased differently, these are perfectly reasonable things to bring
up in IETF-wide last call. The protocol features being talked about
affect the Internet and are reasonable to discuss, even if we don't
end up changing 2401bis to accomodate them other than by mention.

--Paul Hoffman, Director
--VPN Consortium

Mark Duffy

2004-11-07 04:36:25 UTC

Ted,

Thank you for taking the time to re-read the thread and think about this
issue. What I would seek is a minor change that allows discarding
non-initial fragments processed for BYPASS as an alternative to stateful
fragment checking of them.

I think this can be as simple as replacing this sentence in 7.4:
An implementation MUST support stateful fragment checking to accommodate
BYPASS traffic for which a non-trivial port range is specified.
with this one:
An implementation MUST NOT forward fragmented BYPASS traffic
without performing stateful fragment checking.

I don't want to delay the progress of 2401bis unnecessarily and if the
change is made I don't particularly care if it is done now or later in the
cycle. I imagine other changes might be needed anyway during IESG review
or IETF last call.

--Mark

Post by Theodore Ts'o
Mark,
Thanks for the summary, and my apologies for missing the thrust of
your concern, which was for handling of packets which are to BYPASS
ipsec processing.
Rereading the thread with this in mind, I am certainly sympathetic to
your concerns. Certainly one argument in favor of your position is
that by requiring stateful fragment checking for BYPASS traffic
complicates the implementation, where as simply prohibiting fragments
for fragment traffic is much simpler. Furthermore, by requiring the
stateful fragment checking machinery in 7.4, that will tend to
influence implementations to implement the MAY in section 7.3, which
is a minus to those who were opposed to section 7.3 on the grounds of
added implementation complexity.
As far as some of your comments about the pitfalls about implementing
the stateful fragment checking, I'm sure that we could always come up
with more text about how to do this securely, either now or in a
future document. I will note though that this is hardly new ground,
as those who have had to implement stateful fragment checking in
firewalls have had to cover 95% of this ground already.
However, BYPASS checking, in that it does not require interoperability
with another ipsec peer, is one of those things that we can tweak at a
later time (or that a vendor can fudge in their implementation)
without impacting interoperability. So this is something that we can
change in a future document, either by amplifying the specification of
how to do the stateful fragment checking (which has been deliberately
underspecified in sections 7.3 and 7.4), or by allowing some other
variant behaviour.
So if you are indeed content to not press this issue at this time, I
think many people will thank you for your forbearance; but if you or
anyone else feel very strongly that we should make a change, now, just
before we go to IETF-wide last call, or during IETF-wide last call, is
the last chance to make changes during this rev of the document.
- Ted

particular

Post by Mark Duffy
attack it might counter.
. I have questioned whether stateful fragment checking on BYPASS actually
does counter the proposed attack, and suggested that as a result it should
be reduced from a MUST to a MAY.
Now, I can see that this issue has not raised a lot of interest or concern
and I do not want to hold up the process so I will not press further.
--Thanks, Mark

Theodore Ts'o

2004-11-11 19:34:01 UTC

Post by Mark Duffy
An implementation MUST support stateful fragment checking to accommodate
BYPASS traffic for which a non-trivial port range is specified.
An implementation MUST NOT forward fragmented BYPASS traffic
without performing stateful fragment checking.
I don't want to delay the progress of 2401bis unnecessarily and if the
change is made I don't particularly care if it is done now or later in the
cycle. I imagine other changes might be needed anyway during IESG review
or IETF last call.

OK, we'll trea this as an issue raised during last call. It seems to
be a reasonable proposal. Your proposed wording does allow an
implementation which does fragment reassembly; which I assume is what
you wanted to allow, explicitly?

On the other hand, a downside is that it allows an implementation that
filters all fragments to be compliant; on the other hand there are a
lot of firewalls deployed out there that do a lot of sillier things,
including filtering all ICMP packets and breaking Path MTU Discovery,
or filtering SYN packets that have ECN bits set.

I believe Tero has made the assertion that fragment reassembly and
then forwarding of BYPASS traffic is encompassed by the concept of
stateful fragment checking. Would a rewording that made this clearer
be sufficient for you, or are there other specific behaviours you
wanted to allow?

What do other people think?

- Ted

Stephen Kent

2004-11-12 18:43:29 UTC

Post by Theodore Ts'o

OK, we'll trea this as an issue raised during last call. It seems to
be a reasonable proposal. Your proposed wording does allow an
implementation which does fragment reassembly; which I assume is what
you wanted to allow, explicitly?
On the other hand, a downside is that it allows an implementation that
filters all fragments to be compliant; on the other hand there are a
lot of firewalls deployed out there that do a lot of sillier things,
including filtering all ICMP packets and breaking Path MTU Discovery,
or filtering SYN packets that have ECN bits set.
I believe Tero has made the assertion that fragment reassembly and
then forwarding of BYPASS traffic is encompassed by the concept of
stateful fragment checking. Would a rewording that made this clearer
be sufficient for you, or are there other specific behaviours you
wanted to allow?
What do other people think?

Ted,

The exchange between Tero and Mark confirmed that one needs to do
careful, stateful fragment checking for BYPASS traffic, IF one allows
such fragments to be BYPASSed. I don't think this is a new notion; it
echoes the discussion we had month ago that led to the adoption of
the current text. The only issue is whether to mandate support for
BYPASS of fragments, so that a local admin has that option, or
whether we allow implementations that will deny that option to a
local admin. as you note above, one can justify this latter choice
based on common firewall practice today, but we did adopt the current
text based on a WG list discussion a while ago. So, I recommend that
you conduct a quick straw poll on this topic, so that, whichever way
we go, we have documented the WG consensus.

Steve

Mark Duffy

2004-11-12 18:40:31 UTC

Post by Theodore Ts'o

No. What I want to allow, which is not allowed by the current text, is for
implementations to *drop* non-initial BYPASS fragments. The two reasons are:
- implementations may have reasons not to implement stateful fragment
checking (as previously discussed at length for PROTECTed traffic).
- dropping non-initial fragments can protect against certain attacks
(discussed earlier in this thread) that stateful fragment checking cannot.

Post by Theodore Ts'o
On the other hand, a downside is that it allows an implementation that
filters all fragments to be compliant; on the other hand there are a
lot of firewalls deployed out there that do a lot of sillier things,
including filtering all ICMP packets and breaking Path MTU Discovery,
or filtering SYN packets that have ECN bits set.
I believe Tero has made the assertion that fragment reassembly and
then forwarding of BYPASS traffic is encompassed by the concept of
stateful fragment checking. Would a rewording that made this clearer
be sufficient for you, or are there other specific behaviours you
wanted to allow?

I had raised the issue of actual reassembly (as compared to stateful
fragment checking without reassembly) because it can protect against
certain cases that stateful inspection cannot. However, I agree that
reassembly can be accommodated under the existing wording; I don't think
any wording change is needed there.

Post by Theodore Ts'o
What do other people think?
- Ted

vamsi

2004-11-03 20:16:53 UTC

Hi,

I feel that reassembly/fragmentation needs to be done on all packets, even
if there is one SPD policy with transport selectors. If all security
policies contain only IP addresses and Protocol information, then there is
no need for reassembly. When the reassembly is done, the fragmentation
would need to happen based on PMTU of the outgoing link. If the SG acts as
host, then the fragmentation results into creating unique IDENTIFICATION
value in the IP header.

regards
vamsi

Post by Mark Duffy
(subject changed from Re: [Ipsec] WORKING GROUP LAST
CALL: draft-ietf-ipsec-rfc2401bis-03.txt)
Please see below.

Post by Mark Duffy
In sect. 7.4 (BYPASS/DISCARD traffic)

[snip]

[sk] I am not sure that we defaulted a MUST for fragment reassembly for
BYPASS, after deciding to make it a MAY for protected traffic. I thought
that we changed it to MUST after some discussion on the list, after
having listed it as MAY/SHOULD in the earlier draft, but I may be
wrong. How about a quick straw poll, so we can make the word be MUST or
MAY, depending on what folks decide.

I looked a bit at the "paper" trail. The -02 draft (last paragraph of
sect. 7) specified MAY/SHOULD stateful fragment checking for
BYPASS/DISCARD. Subsequently, Tero Kivinen described a possible attack on
1 Jun 04 <http://www.vpnc.org/ietf-ipsec/mail-archive/msg03576.html> (near
the bottom of the message).
The attack example that is now in the -04 draft is not the same as Tero's
example and I think it needs correction (see below). At the same time,
Tero's description does not mention that the attacker would need to guess
the Identification field and source port of the protected packet in order
to carry out the attack. This would make the attack quite a bit harder
against encrypted packets (but not for packets protected with auth only).
The case described in 7.4 is one where (for example)
traffic for (SA1, DA1, tcp, DP1) is IPsec-protected and
traffic for (SA1, DA1, tcp, DP2) is BYPASSed.
This is actually not vulnerable to Tero's attack because without stateful
inspection, non-initial fragments for DP2 would not be BYPASSed. Rather,
the attack Tero described requires that there be a BYPASS rule for dest
port of ANY or OPAQUE, e.g.
traffic for (SA1, DA1, tcp, DP=ANY) is bypassed.
*That* SPD entry would, in the absence of stateful fragment checking,
allow non-initial fragments to pass and corrupt the reassembled datagram.
P.S. The existing example uses port 25=telnet. In fact, telnet is port 23.
I believe that stateful fragment checking for BYPASS does not preclude
1. SA=sa1, SP=any, prot=tcp, DA=da1, DP=25 ==> protect
2. SA=sa1, SP=any, prot=tcp, DA=da1, DP=ANY ==> bypass.
Further, assume that stateful fragment checking is done for the bypass.
Now, telnet user creates and sends a fragmented packet with (SA=sa1,
SP=2222, prot=tcp, DA=da1, DP=25)
The fragments of this packet are protected by an SA created per rule 1.
Attacker removes one or more of the protected non-initial fragments.
Attacker observes (or guesses) the Ident and SP for those fragments.
Attacker creates a new packet with (SA=sa1, SP=2222, prot=tcp, DA=da1,
DP=3333) and with the given Ident value. I.e. everything is the same
except the dest port and the data.
Attacker breaks that packet into fragments and sends them.
The security gateway, with stateful fragment checking, passes all the
fragments pursuant to SPD rule 2.
Destination host might assemble the non-initial fragments onto either
initial fragment (the legit one to port 25 or the bogus one to port
3333). If it assembles them onto the one with DP=25, the attack has succeeded.
Stateful fragment checking for bypass actually makes this worse because
without it, the hostile non-initial fragments will only be bypassed if
there is an SPD entry for DP=ANY (or OPAQUE). With stateful checking, the
hostile fragments can also be bypassed pursuant to SPD entries that have
non-trivial port selectors.
As far as I can see the SG behavior that completely precludes this attack
is for the SG to disallow BYPASS forwarding of any non-initial
fragments. So that should be the required default behavior. Stateful
fragment checking for bypass could be a MAY but with a stern warning about
the possibility of this attack.
Thanks,
Mark
_______________________________________________
Ipsec mailing list
https://www1.ietf.org/mailman/listinfo/ipsec

Stephen Kent

2004-11-03 21:35:07 UTC

Post by vamsi
Hi,
I feel that reassembly/fragmentation needs to be done on all packets, even
if there is one SPD policy with transport selectors. If all security
policies contain only IP addresses and Protocol information, then there is
no need for reassembly. When the reassembly is done, the fragmentation
would need to happen based on PMTU of the outgoing link. If the SG acts as
host, then the fragmentation results into creating unique IDENTIFICATION
value in the IP header.
regards
vamsi

I'm not quite sure what you are saying above.

I suggest you review sections 5 and 7 of
draft-ietf-ipsec-rfc2401bis-04.txt and address your comments to that
text.

Steve

Karen Seo

2004-10-27 03:25:54 UTC

Mark,

I believe we've made edits per your suggestions or replied with
comments/proposed approaches for all the items you listed except for
the following one...

Post by Mark Duffy
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.

Given that the packet specifies AH or ESP as the protocol
and is addressed to this device, there should be an entry
in the SAD for it. The auditable event is the failure to
find a match in the SAD. This is an error and applies
to both unicast or multicast packets. So the current
wording seems reasonable. Do you agree?

"3a. If the packet is addressed to the IPsec device and
AH or ESP is specified as the protocol, the packet is
looked up in the SAD. For unicast traffic, use only the
SPI (or SPI plus protocol). For multicast traffic, use
the SPI plus the destination or SPI plus destination and
source addresses, as specified in section 4.1. In either
case (unicast or multicast), if there is no match, discard
the traffic. This is an auditable event...."

Thank you,
Karen

Mark Duffy

2004-10-28 03:29:45 UTC

Post by Karen Seo

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.

Given that the packet specifies AH or ESP as the protocol
and is addressed to this device, there should be an entry
in the SAD for it. The auditable event is the failure to
find a match in the SAD. This is an error and applies
to both unicast or multicast packets. So the current
wording seems reasonable. Do you agree?
"3a. If the packet is addressed to the IPsec device and
AH or ESP is specified as the protocol, the packet is
looked up in the SAD. For unicast traffic, use only the
SPI (or SPI plus protocol). For multicast traffic, use
the SPI plus the destination or SPI plus destination and
source addresses, as specified in section 4.1. In either
case (unicast or multicast), if there is no match, discard
the traffic. This is an auditable event...."

Thanks Karen, that looks great.
(I think the -03 draft was actually missing a whole line of text here,
which was the main problem.)
--Mark

Karen Seo

2004-10-28 05:13:33 UTC

Mark,

You're right -- the -03 draft is missing a critical sentence. Thanks
for catching this.

Karen

Post by Karen Seo

Post by Mark Duffy
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.

Given that the packet specifies AH or ESP as the protocol
and is addressed to this device, there should be an entry
in the SAD for it. The auditable event is the failure to
find a match in the SAD. This is an error and applies
to both unicast or multicast packets. So the current
wording seems reasonable. Do you agree?
"3a. If the packet is addressed to the IPsec device and
AH or ESP is specified as the protocol, the packet is
looked up in the SAD. For unicast traffic, use only the
SPI (or SPI plus protocol). For multicast traffic, use
the SPI plus the destination or SPI plus destination and
source addresses, as specified in section 4.1. In either
case (unicast or multicast), if there is no match, discard
the traffic. This is an auditable event...."

Thanks Karen, that looks great.
(I think the -03 draft was actually missing a whole line of text
here, which was the main problem.)
--Mark

Karen Seo

2004-10-25 19:27:52 UTC