Joe, This is the only thing related to Transport mode fragmentation that I found.
RFC 2401 "If required, IP fragmentation occurs after IPsec processing within an IPsec implementation. Thus, transport mode AH or ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied may itself be fragmented by routers en route, and such fragments MUST be reassembled prior to IPsec processing at a receiver" Now, I am guessing that taking out those reserved bits that are not used in this mode, it is still subject (as any other packet) to be bigger than 1500 bytes. I think the statement should say "IPsec transport mode MAY suffer from fragmentation and reassembly. Thus it should not be used where applications can be sensitive to them" Something funny, there was the exact same question, and there was no answer for it. Anyway... if someone has any other better explanation, would be greatly appreciated. Mike > Date: Sun, 18 Mar 2012 18:48:55 -0400 > Subject: Re: [OSL | CCIE_Security] GET VPN IPSEC Mode > From: joeastorino1...@gmail.com > To: mike_c...@hotmail.com > CC: ccie_security@onlinestudylist.com > > Thanks Mike! From that document, I have found the answer: > > "It is worth noting that tunnel header preservation seems very similar > to IPsec transport mode. However, the underlying IPsec mode of > operation is IPsec tunnel mode. While IPsec transport mode reuses the > original IP header and therefore adds less overhead to an IP packet > (5% for IMIX packets; 1% for 1400-byte packets), IPsec transport mode > suffers from fragmentation and reassembly limitations and must not be > used in deployments where encrypted or clear packets might require > fragmentation." > > Now, the ultimate question would be "OK, why does transport mode > suffer from IP fragmentation and reassumbly limitations?" But > hmmmmm.....Do I care that much today?! : ) > > On Sun, Mar 18, 2012 at 6:43 PM, Mike Rojas <mike_c...@hotmail.com> wrote: > > Hello Joe, > > > > Back on the SNRS version , yes, there is a new IP header inserted on the > > packet, but is exactly the same as the first one So it would be like this: > > > > [Original IP_Header] [ESP Header] [Original IP_Header] [Payload]. > > > > Based on the documents that I have, it was done this way in order to > > mitigate routing overlay and to preserve Qos and Multicast capabilities. > > > > Check the following doc > > http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6525/ps9370/ps7180/GETVPN_DIG_version_1_0_External.pdf > > > > And look for: > > 1.2.2 Tunnel Header Preservation > > > > Mike > > > > > > > >> Date: Sun, 18 Mar 2012 18:01:25 -0400 > >> From: joeastorino1...@gmail.com > >> To: ccie_security@onlinestudylist.com > >> Subject: [OSL | CCIE_Security] GET VPN IPSEC Mode > > > >> > >> So, I'm a bit confused -- Just started reading about GET VPN and in > >> Yusuf's book "Network Security Technologies & Solutions" there is a > >> diagram that shows an IP packet after GET VPN encapsulation and it is > >> basically IPSEC transport mode as follows > >> > >> [IP Header] [ESP] [DATA] > >> > >> Then today I am reading the 12.4T configuration guide for GETVPN and > >> it contradicts this saying that it is actually TUNNEL mode but the > >> outer and inner IP headers are identical. See > >> > >> http://www.cisco.com/en/US/i/100001-200000/170001-180000/170001-171000/170836.jpg > >> So they are saying it looks like this > >> > >> [IP Header2] [ESP] [IP Header 1] [ DATA] where both IP headers are > >> identical copies. Which is it? It seems from further research that > >> the DOC CD is correct, but I want to make sure. Further, if that IS > >> the case why in the world would they use a second IP header that is > >> identical in tunnel mode instead of just using IPSEC transport mode as > >> described in the book? > >> > >> Thanks everybody! > >> > >> -- > >> Regards, > >> > >> Joe Astorino > >> CCIE #24347 > >> http://astorinonetworks.com > >> > >> "He not busy being born is busy dying" - Dylan > >> _______________________________________________ > >> For more information regarding industry leading CCIE Lab training, please > >> visit www.ipexpert.com > >> > >> Are you a CCNP or CCIE and looking for a job? Check out > >> www.PlatinumPlacement.com > > > > -- > Regards, > > Joe Astorino > CCIE #24347 > http://astorinonetworks.com > > "He not busy being born is busy dying" - Dylan
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
