RE: Cisco GET VPN in transport mode

TV,
        So we are all clear, exactly what "good" information are you
providing in regards to the question? At least Mark is making an effort
to satisfy the quest for an answer among all the experts on here. You
reference an RFC and try to poke holes in his brief explanation, but
provide no benefit in answering the question yourself. Had you not poked
the wolverine in the first place, that might have saved you the public
tongue-lashing you just received. On the flip side, it also provided a
much more detailed response from Mark; which does show his depth and
understanding of the subjects. Not sure I saw in there where he told us
how great he was, what a great instructor he is, and why his CCIE # is
superior to anyone else's. You call it misinformation, but lack the
substance to point out exactly what is wrong with the explanation. You
see where I am going with this? Now the good folks reading these posts
have just had to read mine + the 4 or so that you posted with no real
benefit to anyone.

Let's stop wasting time with posts that provide no real help or provide
no real solutions and get back to studying/helping. (like this one I
felt compelled to write.) Another idea would be to unicast the person
you have the issue with so as to not seem like some sort of drama queen.
I am not sure if that is in the GS regs/rules, but it does seem like it
should be.

-R

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Tony Varriale
Sent: Tuesday, November 03, 2009 3:43 PM
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 Tue Nov 03 2009 - 16:06:43 ART