From: Jason Sinclair (sinclairj@xxxxxxxxxxxxxxx)
Date: Wed Mar 13 2002 - 23:37:31 GMT-3
Howard,
You are of course correct - I guess I am looking at the forwarding aspect.
We would need to clarify at what level we are talking about when discussing
connection-oriented/connectionless.
Regards,
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: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
Sent: Thursday, 14 March 2002 10:59
To: ccielab@groupstudy.com
Subject: RE: IPSec, GRE, and Transport Mode
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