RE: Cisco GET VPN in transport mode

-----Original Message-----
From: Tony Varriale <tvarriale_at_flamboyaninc.com>
Sent: November 03, 2009 18:43
To: ccielab_at_groupstudy.com
Subject: RE: Cisco GET VPN in transport mode

Actually, this was the exact reason why I specifically asked him to clarify
his answer(s).

The problem is that, like Mark, some people in this group post stuff as
fact/best practice/etc. When in fact, it's none of those things. Some of
the people here also use their status (CCIE or otherwise) to back up the
misinformation.

When presented to beginners and/or not well-knowing people (maybe not well
versed on the subject), it spreads misinformation. Especially claiming to
be some sort of teacher before, this is the worst possible case scenario for
any community. In fact, that's a betrayal of the position and implied
power.

If you want to grow up and spread misinformation amongst people that are
willing to listen, that's up to you. If you want to resort to name calling
and not have the ability to present your case and use smoke and mirrors to
divert attention away from the questions, then the best may be with you.

tv

From: armylegionmedic_at_aol.com [mailto:armylegionmedic_at_aol.com]
Sent: Tuesday, November 03, 2009 5:26 PM
To: markcciejackson_at_gmail.com; tvarriale_at_flamboyaninc.com
Cc: ccielab_at_groupstudy.com; pborghese_at_groupstudy.com
Subject: Re: Cisco GET VPN in transport mode

I just wanted to say, this was amazingly impressive. I mean, not the
insulting part, but this is what a CCIE should be like, who can detail out
and explain the information. There are so many CCIE's now who can just pull
configs from their A$$, but dont know two sh!ts about it or why. It would be
a tragic shame to loose a person like this. I wish more postings could be
this comprehensive in explaining something and why, I think we would learn a
lot more.

When I grow up to be a CCIE, I hope to be this smart.

-----Original Message-----
From: Mark Jackson <markcciejackson_at_gmail.com>
To: Tony Varriale <tvarriale_at_flamboyaninc.com>
Cc: ccielab_at_groupstudy.com; pborghese_at_groupstudy.com
Sent: Tue, Nov 3, 2009 3:02 pm
Subject: Re: FW: Cisco GET VPN in transport mode

RFC2402, hopefully I dont have to explain it to you, otherwise I will have
to go back to teaching.But to touch lightly on it, because apparently your
are getting paid to just oversee at your company. God forbid, you are
actually doing any technical design or implementation. That would just scare
me as well as welcome everyone to the FAIL. That is where words cannot
describe how stupid you actually are.Now Jr, IPSec suffers from a lack of
vectors. The AH and ESP can be used together, but should only be used in a
particular order. In transport mode, ESP by itself provides only partial
auth pf the IP packet, and using AH too is also good. In tunnel mode the ESP
auths the inner headers, so the use of AH is no longer required. These reqs
between choices clearly shows these options are not independent of each
other.Another reason is the TOS field in the IP header (Here come the real
soup to nuts on RFC2402). Although this is supposed to be unchanged during
transmission of a packet (again, according to the IP specs), some routers
are known to changes this field. IPSec chooses to exclude the TOS field from
the authentication provided by AH to avoid error introed by rogue routers.
This results in the transport/AH packets that have an auth header, the TOS
field is not authed. This is clearly enexpected from the app point of view.
The problem does not occur in tunnel mode. Now Im assuming youre a wee bit
slower then that. Lets go with a real-world example. Suppose two host have
a manually keyed trans-mode AH-proto SA, which we will call saah. Due to the
manual keying, the AH does not provide any replay protection (you do know
what replay is???maybe another lesson. My rate is $375 an hour). Now where
was I.Ahh yeah! These two host now neg a trans-mode encrypt-only ESP SA
(which I will call saesp1) and use this to send info using both saah &
saesp1. The app can expect to get secret and auth on this channel, but no
replay safety. A few hours later, the 2 host start the trans-mode
encrypt-only easp sa, and the receiver chooses the same spi value for saesp2
as was used for saesp1. Again, the info is transmitted using both saesp1 and
saah. Now if your even 1% the CCIE you claim to be, then I do not have to
explain what an attacker can do. This type of transmittal is where Cisco
choose to follow the esp operation ordering. That in itself is in stark
contrast to what was allowed by both rfc 2401 and 2402.

   - Tunnel mode is most commonly used to encrypt traffic between secure
   IPSec gateways, such as between the Cisco router and PIX Firewall. The
IPSec
   gateways proxy IPSec for the devices behind them
   - Tunnel mode is also used to connect an end-station running IPSec
   software, such as the Cisco Secure VPN Client, to an IPSec gateway.
   - tunnel mode is used to set up an IPSec tunnel between the Cisco router
   and a server running IPSec software. Note that Cisco IOS software and the
   PIX Firewall sets tunnel mode as the default IPSec mode.
   - Transport mode is used between end-stations supporting IPSec, or
   between an end-station and a gateway, if the gateway is being treated as
a
   host. In example *D*, transport mode is used to set up an encrypted
   Telnet session from Alice's PC running Cisco Secure VPN Client software
to
   terminate at the PIX Firewall, enabling Alice to remotely configure the
PIX
   Firewall securely.

* *

IPSec mode makes to AH. In transport mode, AH services protect the external
IP header along with the data payload. AH services protect all the fields in
the header that don't change in transport. The header goes after the IP
header and before the ESP header, if present, and other higher-layer
protocols.In tunnel mode, the entire original header is authenticated, a new
IP header is built, and the new IP header is protected in the same way as
the IP header in transport mode.AH is incompatible with Network Address
Translation (NAT) because NAT changes the source IP address, which breaks
the AH header and causes the packets to be rejected by the IPSec
peer.differences
that the IPSec mode makes to ESP. In transport mode, the IP payload is
encrypted and the original headers are left intact. The ESP header is
inserted after the IP header and before the upper-layer protocol header. The
upper-layer protocols are encrypted and authenticated along with the ESP
header. ESP doesn't authenticate the IP header itself.When ESP is used in
tunnel mode, the original IP header is well protected because the entire
original IP datagram is encrypted. With an ESP authentication mechanism, the
original IP datagram and the ESP header are included; however, the new IP
header is not included in the authentication.When both authentication and
encryption are selected, encryption is performed first, before
authentication. One reason for this order of processing is that it
facilitates rapid detection and rejection of replayed or bogus packets by
the receiving node. Prior to decrypting the packet, the receiver can detect
the problem and potentially reduce the impact of denial-of-service attacks.

ESP can also provide packet authentication with an optional field for
authentication. Cisco IOS software and the PIX Firewall refer to this
service as ESP *hashed message authentication code* (HMAC). Authentication
is calculated after the encryption is done. The current IPSec standard
specifies SHA-1 and MD5 as the mandatory HMAC algorithms. The main
difference between the authentication provided by ESP and AH is the extent
of the coverage. Specifically, ESP doesn't protect any IP header fields
unless those fields are encapsulated by ESP (tunnel mode).

On Tue, Nov 3, 2009 at 2:41 PM, Tony Varriale
<tvarriale_at_flamboyaninc.com>wrote:

> Yeah, you continually say nothing.
>
>
>
> Let me help. http://www.groupstudy.com/list/guide.html
>
>
>
>
>
> Paul, can we get some assistance here?
>
>
>
> tv
>
> From: Mark Jackson [mailto:markcciejackson_at_gmail.com
<mailto:markcciejackson_at_gmail.com?> ]
> Sent: Tuesday, November 03, 2009 4:16 PM
> To: tvarriale_at_flamboyaninc.com
> Cc: ccielab_at_groupstudy.com
> Subject: Re: Cisco GET VPN in transport mode
>
>
>
> Well, you sure are an abrasive little elf...also, if your not part of a
> general solution, your part of the problem and the problem I see with you
> is
> you just are not nice! Get a life, get some sunshine and maybe your
overall
> demeanor with change.
>
> on that note...allow me to school you asshole! (queue the school bell)
>
>
>
> I said the following:
>
>
>
> 1. IPSec has compatibility req
> 2. The TOS field in the header
> 3. Lack of vectors such as the use of AH and ESP protocols
>
>
>
> That was in response to the question of:
>
>
>
> 1. I do not understand why transport mode suffer fragmentation and
> reassembly.
>
>
>
> So, hopefully you are following along. I know being a Network Architect at
> Presidio has dulled your 'technical' edge.
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Nov 3, 2009 at 1:53 PM, Tony Varriale <tvarriale_at_flamboyaninc.com>
> wrote:
>
> Your reasons make no sense.
>
> And, please feel free to point out portion of RFC2402 that Cisco is not
> following in their implementation.
>
> tv
>
>
>
> -----Original Message-----
> From: mark jackson [mailto:markcciejackson_at_gmail.com
<mailto:markcciejackson_at_gmail.com?> ]
> Sent: Tuesday, November 03, 2009 3:47 PM
> To: Tony Varriale
> Cc: ccielab_at_groupstudy.com
> Subject: Re: Cisco GET VPN in transport mode
>
> Not sure I understand...
>
> Mark Jackson, CCIE#4736
>
> Sent from my iPhone
> Please excuse spelling errors
>
> On Nov 3, 2009, at 1:45 PM, "Tony Varriale"
> <tvarriale_at_flamboyaninc.com> wrote:
>
> > Dare I ask what?
> >
> > tv
> >
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com
<mailto:nobody_at_groupstudy.com?> ] On Behalf
> > Of mark
> > jackson
> > Sent: Tuesday, November 03, 2009 3:02 PM
> > To: Hans None
> > Cc: ccielab_at_groupstudy.com
> > Subject: Re: Cisco GET VPN in transport mode
> >
> > A few reason for this are:
> >
> > 1. IPSec has compatibility req
> > 2. The TOS field in the header
> > 3. Lack of vectors such as the use of AH and ESP protocols
> >
> > All in all, cisco did not follow the specs define in rfc 2402. Kind
> > of sad
> >
> > Mark Jackson, CCIE#4736
> >
> > Sent from my iPhone
> > Please excuse spelling errors
> >
> > On Nov 3, 2009, at 12:53 PM, Hans None < <acsyao_at_hotmail.com>
> > acsyao_at_hotmail.com> wrote:
> >
> > I have read the following on GET VPN in transport mode:
> >
> >
> > IPsec transport mode suffers from fragmentation and reassembly
> > limitations
> > and must not be used in
> > deployments where encrypted or clear packets might require
> > fragmentation.
> >
> >
> > I do not understand why transport mode suffer fragmentation and
> > reassembly.
> >
> >
> >> From: <markcciejackson_at_gmail.com> <markcciejackson_at_gmail.com>
> > markcciejackson_at_gmail.com
> >> Date: Tue, 3 Nov 2009 12:44:46 -0800
> >> Subject: Re: Cisco GET VPN in transport mode
> >> To: <acsyao_at_hotmail.com> <acsyao_at_hotmail.com>acsyao_at_hotmail.com
> >> CC: <ccielab_at_groupstudy.com> <ccielab_at_groupstudy.com>
> > ccielab_at_groupstudy.com
> >>
> >> It is mainly because Cisco cannot initate/terminate transport mode
> >> IPSec tunnel. Getvpn works mainly in changing the header, it's
> >> actually not changing but the same idea. Mire a copy and paste.
> >>
> >> Mark Jackson, CCIE#4736
> >>
> >> Sent from my iPhone
> >> Please excuse spelling errors
> >>
> >> On Nov 3, 2009, at 12:39 PM, Hans None < <acsyao_at_hotmail.com>
> > acsyao_at_hotmail.com> wrote:
> >>
> >>> 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
> <
> http://www.bing.com/search?q=restaurants
<http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT
> &form=MFESRP&publ=WLHMTAG&crea=TEXT
> > &form=MFESRP&publ=WLHMTAG&crea=TEXT
> >
> _M><http://www.bing.com/search?q=restaurants
> <http://www.bing.com/search?q=restaurants
<http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=T>
&form=MFESRP&publ=WLHMTAG&crea=T>
> &form=MFESRP&publ=WLHMTAG&crea=T
> > EXT_M>
> >
> http://www.bing.com/search?q=restaurants
> <
> http://www.bing.com/search?q=restaurants
<http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT
> &form=MFESRP&publ=WLHMTAG&crea=TEXT
> _> &form=MFESRP&publ=WLHMTAG&crea=TEXT_
> > M
> >>> FESRP_Local_MapsMenu_Resturants_1x1
> >>>
> >>>
> >>> Blogs and organic groups at <http://www.ccie.net <http://www.ccie.net/
> >
> > <http://www.ccie.net <http://www.ccie.net/>
> >>> >
> > http://www.ccie.net <http://www.ccie.net/>
> >>>
> >>>
Received on Wed Nov 04 2009 - 00:40:32 ART