Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt

From: Mark Duffy <[email-masked]>
Date: Mon, 01 Nov 2004 17:50:26 -0500

Hi Steve,

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

At 05:55 PM 10/29/2004, Stephen Kent wrote:
>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.

great

>>>>In sect. 5.1 item 4:
>>>>         <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 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).
>
>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.
>
>>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
[...]
>>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.
>
>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.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Mark Duffy <[email-masked]>
Date: Tue, 02 Nov 2004 15:45:54 -0500

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

Please see below.

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Nov 2004 11:20:50 +0200

> Why stateful fragment checking for BYPASS is not sufficient:

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

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

> Now, telnet user creates and sends a fragmented packet with (SA=sa1, 
       ^^^^^^
smtp :-)

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

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

> 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.
-- 
[email-masked]

---

From: vamsi <[email-masked]>
Date: Wed, 03 Nov 2004 12:16:53 -0800

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

At 12:45 PM 11/2/2004, Mark Duffy wrote:
>>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.
>
>*That* SPD entry would, in the absence of stateful fragment checking, 
>allow non-initial fragments to pass and corrupt the reassembled datagram.
>
>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:

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Nov 2004 16:35:07 -0500

>host, then the fragmentation results into creating unique IDENTIFICATION

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

---

From: Mark Duffy <[email-masked]>
Date: Wed, 03 Nov 2004 17:35:42 -0500

At 04:20 AM 11/3/2004, Tero Kivinen wrote:
[snip]
>decryption (bypassed) in case the attacker generated first frament was

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 4 Nov 2004 11:25:51 +0200

> not stateful checking of these fragments so they wouldn't be blocked in 

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.

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

> fragments could be reordered in the network prior to delivery to the 

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. 

> Any of these cases could lead to an attacker corrupting a packet that had 

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

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

> 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 :-)
-- 
[email-masked]

---

From: Mark Duffy <[email-masked]>
Date: Fri, 05 Nov 2004 00:02:40 -0500

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

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 5 Nov 2004 09:24:52 -0500

On Fri, Nov 05, 2004 at 12:02:40AM -0500, Mark Duffy wrote:
> 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?

> We might 

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

---

From: Mark Duffy <[email-masked]>
Date: Fri, 05 Nov 2004 11:14:55 -0500

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

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 5 Nov 2004 16:49:54 -0500

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

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 5 Nov 2004 18:40:40 -0800

>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

---

From: Mark Duffy <[email-masked]>
Date: Sat, 06 Nov 2004 23:36:25 -0500

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

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 11 Nov 2004 14:34:01 -0500

> cycle.  I imagine other changes might be needed anyway during IESG review 

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Nov 2004 13:43:29 -0500

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

---

From: Mark Duffy <[email-masked]>
Date: Fri, 12 Nov 2004 13:40:31 -0500

>you wanted to allow, explicitly?

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.

>be sufficient for you, or are there other specific behaviours you

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.