From: Brian Lodwick (xpranax@xxxxxxxxxxx)
Date: Wed Mar 13 2002 - 20:20:38 GMT-3
I'm glad someone bit off on that question.
As you stated below that IPsec is connectionless is what I had suspected was
the case as well at first read of the RFC, but there is a part to pay close
attention to. What actually led me to the answer was actually in an IETF
draft. This is almost identical to the RFC, but for some reason in this
draft they look a tiny bit closer at the packet format, and give an example.
Here is the link:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-02.txt
>>>Brian
>From: Jason Sinclair <sinclairj@powertel.com.au>
>To: 'Brian Lodwick' <xpranax@hotmail.com>, nshah@connect.com.au,
>neiby@ureach.com, ccielab@groupstudy.com
>Subject: RE: IPSec, GRE, and Transport Mode
>Date: Thu, 14 Mar 2002 10:09:02 +1000
>
>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.
>
>
>Jason Sinclair
>Manager, Network Support Group
>POWERTEL
>Ground Level, 55 Clarence Street,
>SYDNEY NSW 2000
>AUSTRALIA
>office: + 61 2 8264 3820
>mobile: + 61 416 105 858
>* sinclairj@powertel.com.au
>
>
>
> -----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