Subject: [Ipsec] question about 2401bis tunnels and fragments

From: Joe Touch <[email-masked]>
Date: Fri, 01 Oct 2004 11:07:33 -0700

The following discusses some of the text regarding fragmentation and 
tunnel mode. I checked the archives, and although fragmentation issues 
have been discussed numerous times, I did not find that this particular 
issue had been covered. If it has, can someone please point me at the 
thread; if not, I'd like to raise it now (it's a minor editing issue, IMO).

------------------------------

Some of the descriptions on page 13/14 about the need for tunnel mode 
are indeed needs for tunnels (e.g., reassembly), but not necessarily 
need tunnel mode, e.g.:

 > Several concerns motivate the use of tunnel mode for an SA involving
 > a security gateway. For example, if there are multiple paths (e.g.,
 > via different security gateways) to the same destination behind a
 > security gateway, it is important that an IPsec packet be sent to the
 > security gateway with which the SA was negotiated.  Similarly, a
 > packet that might be fragmented en-route must have all the fragments
 > delivered to the same IPsec instance for reassembly prior to
 >
 >
 > Kent & Seo              [Page 14]
 > 
 > Internet Draft  Security Architecture for IP  September 2004
 >
 >
 > cryptographic processing. Also, when a fragment is processed by IPsec
 > and transmitted, then fragmented en-route, it is critical that there
 > be inner and outer headers to retain the fragmentation state data for
 > the pre- and post-IPsec packet formats. Hence there are several
 > reasons for employing tunnel mode when either end of an SA is a
 > security gateway.

as well as end sec D.1 on page 78:

 > In 2401bis, we have explicitly said that it is OK to use transport
 > mode in cases where the IPsec implementation is not the ultimate
 > destination, e.g., between two SGs. In principle, this creates a new
 > opportunity for outbound, plaintext fragments to be mapped to a
 > transport mode SA for IPsec processing. However, in these new
 > contexts in which a transport mode SA is now approved for use, it
 > seems likely that we can continue to prohibit transmission of
 > fragments, as seen by IPsec. For example, in an IP overlay network,
 > packets being sent over transport mode SAs are IP-in-IP tunneled and
 > thus have the necessary inner header to accommodate fragmentation
 > prior to IPsec processing. When carried via a transport mode SA,
 > IPsec would not examine the inner IP header for such traffic, and
 > thus would not consider the packet to be a fragment. Thus it seems
 > reasonable to retain the prohibition on carrying IPv4 fragments on
 > transport mode SAs, even when the source or destination is an SG.

It's not clear how it will help to prohibit IPv4 fragments on such 
tunnels; the packets that are fragmented are encapsulated in IP headers 
that do not indicate them as fragments (the outer packet doesn't 
necessarily have an offset when the inner one does).

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Oct 2004 17:55:53 -0400

At 11:07 AM -0700 10/1/04, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enig7DAB81909B078C51F1772411"
>
>tunnel mode. I checked the archives, and although fragmentation 
>issues have been discussed numerous times, I did not find that this 
>particular issue had been covered. If it has, can someone please 
>point me at the thread; if not, I'd like to raise it now (it's a 
>minor editing issue, IMO).
>
>Some of the descriptions on page 13/14 about the need for tunnel 
>mode are indeed needs for tunnels (e.g., reassembly), but not 
>necessarily need tunnel mode, e.g.:
>
>tunnels; the packets that are fragmented are encapsulated in IP 
>headers that do not indicate them as fragments (the outer packet 
>doesn't necessarily have an offset when the inner one does).
>
>Joe

You seem to be addressing two distinct issues above.

The first is that the text on page 13/14 emphasizes the traditional 
use of tunnel mode in IPsec, and does not address the possible use of 
IP-in-IP tunnels effected via transport mode.  That is correct, but I 
am reluctant to review the whole document to find and change every 
place where we discuss tunnel mode, with an eye toward discussing the 
traditional and the overlay network uses of this mode, and how they 
may differ.

The text in D.1 documents the rationale for the decisions the WG made 
re fragmentation. Here the concern is that fragments carried via SAs 
pose problems for the access control checks. But, as the text notes, 
this is not an issue for a transport mode SA which is using IP-in-IP 
tunneling, since IPsec does not see the inner IP header in this case. 
I agree that we should re-write the paragraph you cite to make this 
clearer.

Steve

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Oct 2004 15:09:33 -0700

Comments below...

Stephen Kent wrote:

>> have been discussed numerous times, I did not find that this 
>> particular issue had been covered. If it has, can someone please point 
>> me at the thread; if not, I'd like to raise it now (it's a minor 
>> editing issue, IMO).
>>
> The first is that the text on page 13/14 emphasizes the traditional use 
> of tunnel mode in IPsec, and does not address the possible use of 
> IP-in-IP tunnels effected via transport mode.  That is correct, but I am 
> reluctant to review the whole document to find and change every place 
> where we discuss tunnel mode, with an eye toward discussing the 
> traditional and the overlay network uses of this mode, and how they may 
> differ.

It's more specific than that; it has only to do with the relationship
between tunneling and fragmentation. I don't think this issue pervades
the doc, but rather it ties in with the second item.

> The text in D.1 documents the rationale for the decisions the WG made re 
> fragmentation. Here the concern is that fragments carried via SAs pose 
> problems for the access control checks. But, as the text notes, this is 
> not an issue for a transport mode SA which is using IP-in-IP tunneling, 
> since IPsec does not see the inner IP header in this case. I agree that 
> we should re-write the paragraph you cite to make this clearer.
> 
> Steve

Agreed; the last sentence is the one that appears to be confusing.

Joe