[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem about reassembly and fragmentation
Title: Re: Problem about reassembly and
fragmentation
At 2:33 PM -0800 3/8/02, Scott Fluhrer wrote:
At 11:44 AM 3/8/2002, Stephen Kent
wrote:
At 10:32 AM -0800 3/8/02, Scott Fluhrer
wrote:
Obnit: you can encrypt fragments in tunnel mode. In transport
mode,
you can only encrypt unfragmented packets, and so you must
reassemble
(or drop) if you get fragments. And yes, there are IPSec
implementations where you could possibly see fragments that need to
be
encrypted using transport mode.
RFC 2401 states that transport mode is to be used only between
endpoints, and that the next layer protocol is typically a transport
layer protocol, apropos the mode name. In what circumstances do
you see fragments (hence another IP header) being encapsulated in
transport mode? L2TP?
The implementation I'm thinking about acts as a BITW in front of a
specific end point (IP address), and intercepts all traffic to/from
the end point, and encrypts/decrypts traffic on behalf of the end
point. The BITW itself doesn't have an IP address, and so it
borrows the end point's. To anything past the BITW, the BITW and
the endpoint appear to be one unit that does (among other things)
IPSec. And so, if the end point sends fragments with itself as
the source IP address, then the BITW may decide to encrypt them, and
if the SA it selects happens to be in transport mode, well, we're in
exactly the scenario I eluded to above...
Steve
Scott,
Note the following from 2401 (Appendix B), with my application of
bold text:
B.2 Fragmentation
If required, IP fragmentation occurs after IPsec
processing within an
IPsec implementation.
Thus, transport mode AH or ESP is applied only
to whole IP datagrams
(not to IP fragments). An IP packet to which
AH or ESP has been applied may itself be fragmented by
routers en
route, and such fragments MUST be reassembled prior to
IPsec
processing at a receiver. In tunnel mode, AH or ESP
is applied to an
IP packet, the payload of
which may be a fragmented IP packet. For
example, a security gateway, "bump-in-the-stack"
(BITS), or "bump-
in-the-wire" (BITW) IPsec implementation may apply
tunnel mode AH to
such fragments. Note
that BITS or BITW implementations are examples
of where a host IPsec implementation might receive
fragments to which
tunnel mode is to be
applied. However, if transport mode is to be
applied, then these implementations MUST reassemble the
fragments
prior to applying IPsec.
I confess I am slightly confused: I thought I was saying precisely
what the highlighted text says. That is, when I said:
> In transport mode, you can only encrypt unfragmented packets, and
so you must reassemble (or drop) if you get fragments.
I meant that "if transport mode is applied, then you must
reassemble the fragments prior to applying IPSec". This
would appear to be precisely what the RFC says, except that the RFC
specifies it only for "these implementations" (by which the
RFC doesn't really mean this restriction is limited only to BITS and
BITW implementations), and that I added the proviso that dropping it
was possible, mostly for completeness.
Just out of curiosity, what did you think
I meant? You're not the only one who raised a question, and so
I'd like to know how I was unclear.
Whoops; I overlooked that part of your comment. We are in
agreement here.
I would like to push in the direction of not having to accept
fragments at a BITW/BITS or SG, using ICMP PMUT message to push back
at hosts, so that we could avoid the need to reassemble in any mode
(tunnel or transport) and so that one can always apply full selector
sets to traffic, not having to worry about the unavailability of
releveant fields due to fragmentation.
Steve