RE: Cisco GET VPN in transport mode

Thanks Peter for your reply.

Original packet iphearder+data

first frag before encryption: ipheader+data1, ipheader+data2
(data1+data2=data)

after encryption with esp in transport mode:

ipheader+esp+data1, ipheader+esp+data2

second frag en route:

ipheader+esp+data3, ipheader+esp+data4, ipheader+esp+data2
(data3+data4=data1)

I did not see anything wrong will happen after the second frag. Can you be
more specific?

Also, another quick question, what will be the protocol ID for fragmented
packet, what I mean is, if the original packet is tcp, the protocol ID in the
original header should be 6, when fragmented, the second part of the packet
will not have a tcp header inside, what will be used by ip header to indicated
the fragmented packet?

Thanks,

Hans

> Date: Wed, 4 Nov 2009 00:47:17 -0800
> Subject: Re: Cisco GET VPN in transport mode
> From: petr_at_internetworkexpert.com
> To: acsyao_at_hotmail.com
> CC: ccielab_at_groupstudy.com
>
> Small correction here, "the use of IPsec transport mode" should of
> course read as "the use of IPsec tunnel mode" which is pretty much
> equivalent of using extra tunneling layer like GRE or IPIP.
>
> 2009/11/4 Petr Lapukhov <petr_at_internetworkexpert.com>:
> > Hans,
> >
> > per my understanding, the inherent problem with IPsec transport mode
> > is lack of second encapsulating IP header. When an IP packet is
> > fragmented prior to IPsec encapsulation, and then fragmented en-route
> > after IPsec encapsulation, two IP headers are required to properly
> > maintain two separate fragmentation states. The outer header maintains
> > post-IPsec fragmentation and the inner header maintains pre-IPsec
> > fragmentation.
> >
> > It is possible to implement extra tunneling layer e.g. GRE or IPIP
> > under IPsec transport mode header to avoid this issue. This is the way
> > it's being done with DMVPN, for example. However, per GET VPN nature,
> > original header preservation dictates simple duplication of IP header
> > and the use of IPsec transport mode, which allows avoiding the above
> > mentioned fragmentation issue.
> >
> > You may find this information in RFC 4301 (Security Architecture for
> > the Internet Protocol), which was my primary source of information
> > when I was trying to figure out the answer myself.
> >
> > HTH
> > --
> > Petr Lapukhov, petr_at_INE.com
> > CCIE #16379 (R&S/Security/SP/Voice)
> >
> > Internetwork Expert, Inc.
> > http://www.INE.com
> > Toll Free: 877-224-8987
> > Outside US: 775-826-4344
> >
> > 2009/11/3 Hans None <acsyao_at_hotmail.com>:
> >> All,
> >>
> >>
> >>
> >> Does anyone know why Cisco GET VPN does not work in IPSEC transport
mode?
> >>
> >>
> >>
> >>
> >>
> >> Thanks,
> >>
> >> _________________________________________________________________
> >> Bing brings you maps, menus, and reviews organized in one place.
> >>
http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT_M
> >> FESRP_Local_MapsMenu_Resturants_1x1
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
>
>
> --
> Petr Lapukhov, petr_at_INE.com
> CCIE #16379 (R&S/Security/SP/Voice)
>
> Internetwork Expert, Inc.
> http://www.INE.com
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
Received on Wed Nov 04 2009 - 19:23:10 ART