From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Wed Mar 13 2002 - 21:58:55 GMT-3
At 10:09 AM +1000 3/14/02, Jason Sinclair wrote:
>From RFC 2406:
>
>In transport mode, ESP is inserted after the IP header and before an upper
>layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers
>that have already been inserted. In the context of IPv4, this translates to
>placing ESP after the IP header (and any options that it contains), but
>before the upper layer protocol.
>......
>When ESP is implemented in a security gateway (to protect subscriber transit
>traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header
>carries the ultimate source and destination addresses, while an "outer" IP
>header may contain distinct IP addresses, e.g., addresses of security
>gateways. In tunnel mode, ESP protects the entire inner IP packet, including
>the entire inner IP header. The position of ESP in tunnel mode, relative to
>the outer IP header, is the same as for ESP in transport mode.
>
>
>Thus I would say that it must be connectionless from a protocol perspective
>as it is basically an IP datagram which is connectionless.
It's not cleanly one way or the other. Your argument is legitimate
for the data/forwarding plane of IPsec, but what about its control
plane? Surely the security association is connection-oriented, albeit
one-way.
>
> -----Original Message-----
> From: Brian Lodwick [mailto:xpranax@hotmail.com]
> Sent: Thursday, 14 March 2002 08:36
> To: nshah@connect.com.au; neiby@ureach.com;
>ccielab@groupstudy.com
> Subject: Re: IPSec, GRE, and Transport Mode
>
> This same question came up just a little while ago.
>
> When using IPsec ESP in Tunnel mode it will append a new IP
>header (and an
> ESP header) to the front of the original IP packet in
>addition to encrypting
> everything from the ESP header in.
>
> When using IPsec ESP in Transport mode it will not append an
>additional IP
> header to the front of the original IP packet. It will only
>encrypt the
> packet from the ESP header in (and ofcourse will add an ESP
>header in
> between the original IP header and the upper-layer protocol
>information).
> So if you were using IPsec ESP in transport mode (no GRE
>tunnel) and the
> source address of a packet was 10.0.0.1, because it was from
>one of the
> hosts within your internal network the packet would never
>return, and like
> the guy below said the real address of the host would be
>exposed.
>
> If you are encapsultating the original IP packet inside of
>GRE (then
> encrypting the GRE packets by using IPsec) GRE will append
>an additional IP
> header to the front of the original IP packet, and the
>source address will
> then become whatever the source address of the GRE tunnel
>is. In this case
> there is no reason to use IPsec ESP Tunnel mode to append
>another IP header
> on the front because GRE has done that work already.
>
> in short the reason is that IPsec ESP Tunnel mode appends a
>new IP header
> onto the front of the original IP packet.
> GRE also appends a new IP header to the front of the
>original IP packet, so
> there is no need to add additional work for the routers by
>wrapping layer 3,
> 3 times.
>
> New IPsec question of the day for those interested:
>
> Is IPsec ESP in Tunnel mode connection-oriented or
>connectionless?
>
>
> >>>Brian
>
>
> >From: "Nick Shah" <nshah@connect.com.au>
> >Reply-To: "Nick Shah" <nshah@connect.com.au>
> >To: "John Neiberger" <neiby@ureach.com>,
><ccielab@groupstudy.com>
> >Subject: Re: IPSec, GRE, and Transport Mode
> >Date: Thu, 14 Mar 2002 08:38:20 +1100
> >
> >When using IPSEC in tunnel mode, the original IP header is
>encrypted. This
> >is good in a way, since it protects the inside of the
>network, by
> >encrypting
> >the original source ip address and dest. ip address. The
>world can see only
> >the source and dest. of 2 ipsec peers (not of the
>communicating devices).
> >
> >In transport mode, the end user would be initiating the VPN
>with an IPSEC
> >terminating device, so the IP address of client would be
>the address of teh
> >VPN initiator, exposing the actual ip address to the
>public.
> >
> >You can prolly use tunnel mode when providing LAN-2-LAN
>connectivity,
> >essentially hiding the addresses of vpn clients.
> >
> >Dont know of any gotchas, purely functional differences,
>and can be
> >justified only in real world.
> >
> >hth.
> >Nick
> >
> >-----Original Message-----
> >From: John Neiberger <neiby@ureach.com>
> >To: ccielab@groupstudy.com <ccielab@groupstudy.com>
> >Date: Thursday, 14 March 2002 6:00
> >Subject: IPSec, GRE, and Transport Mode
> >
> >
> > >I'm looking at an example on CCO that is encrypting a GRE
> > >tunnel, but this is the first time I've noticed the
>addition
> > >of 'mode transport' in the configuration.
> > >
> > >I was under the impression that transport mode was for
>use only
> > >when the tunnel endpoints were creating the traffic.
>Does that
> > >apply here because the router endpoints are creating the
>GRE
> > >packets and are therefore the end hosts? That kind of
>makes
> > >sense.
> > >
> > >What would be the functional different in this case
>between
> > >tunnel mode and transport mode? If we're using a GRE
>tunnel,
> > >would there be any significant difference? Any gotchas
> > >regarding either method with GRE?
> > >
> > >Thanks,
> > >John <-- IPsec neophyte
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:04 GMT-3