Re: Cisco GET VPN in transport mode

Your the one who asked for a clearification. I gave it.
Now if you have better information to add or correct me on. Kindly do
so.
If you want to try and make a statement, do so as well.
But it's a real small world this cisco business. Don't cut off you
nose to spite your face the old saying goes.
My signature is here because I achived something over 10 years ago and
continue to do so. I take pride in that.
And the fact I didn't give the right link to a wireless guide does not
mean anything. Added to the fact I openly admitted giving the wrong
link. In an open fourm.
I answered your question. I fact I answered the post. You felt
entitled to correct me but offered no correction to anything I have
said. Drawing a hungry crowd but leaving them empty...
Re read your email skippy, your brought up best practices.
I never claimed to be a teacher (although I am a certified trainer for
Cisco if you must know). I was schooling you and you alone. Reason?
because you said I was wrong. But didn't say why.
Now I could answer your questions, but your a CCIE right? I mean you
call your self an architect. At least on Linkedin you do. so I assume
you have certified. Please correct me if I'm wrong...
And after going back and looking over your post on the archives, I see
you have no real value here. All you have done is argued with just
about everyone from who should be in the Hall of Fame (oh, I'm I
there. You?) to how VTP is used. CCNA level there Richard, sorry. Tony.
Also did some looking at your company.
Come on, dude. Your talking smoke and mirrors. Your and Darby Weaver
are a match made in I wanna be a CCIE heaven. I consider you a groupie.
So with that, talk all you want. Go home and pretend.
I'll still be here helping out and learning. Got my CCDE practicle
coming up.

Mark Jackson, CCIE#4736

Sent from my iPhone
Please excuse spelling errors

On Nov 3, 2009, at 4:21 PM, "Tony Varriale"
<tvarriale_at_flamboyaninc.com> wrote:

> Replies inline.
>
> -----Original Message-----
> From: mark jackson [mailto:markcciejackson_at_gmail.com]
> Sent: Tuesday, November 03, 2009 5:56 PM
> To: Tony Varriale
> Cc: ccielab_at_groupstudy.com
> Subject: Re: Cisco GET VPN in transport mode
>
>> I guess my next question is where does that leave me???
>
> I have no clue. Only you can answer that.
>
>> While I can only think of one instance o gave a outdated link to a
>> wireless hardware lab guide, I can't think of providing
>
> It's not only did you give out a link that had nothing to do with
> the CCIE
> Wireless lab or any up-to-date equipment, you as a CCIE somehow
> didn't link
> that person to the CCIE Wireless page. That's very odd.
>
>> misinformation, calling myself a 'teacher' I ever using my status
>> or #
>> in any of my replies. I kindly ask for you to provide such proof.
>
> You apparently schooled me. And, you provided "facts" to the list.
> There
> are many that look at your signature (you have your CCIE # in there)
> and
> automatically think that the information you provide as gospel.
> Those are
> teacher positions.
>
>> I have always made sure to not only explain myself technically but
>> present a real-world example.
>
> You haven't. I asked you to explain your comments. Instead, you
> insulted
> me, called me names and dodged the question. Then, you went on and
> copied
> and pasted a bunch of info not related to your original comments in
> order to
> shift focus.
>
>> Also show where I have said anythig in terms of best practice that is
>> not specfically detailed within Cisco's lifecycle.
>
> We aren't even discussing that.
>
>> So if you can't provide where I have in fact done what you are saying
>> I did, I'd suggest you be quite.
>
> It's all above. You still have yet to respond to your original
> comments.
> You said you were going to school me and you just reposted your
> original
> comments.
>
> Care to explain those?
>
> I'll actually clarify myself and give you more detail on your
> statements:
>
> 1. IPSec has compatibility req - What does this mean? Compatibility
> request? Compatibility requirements? And to what? How is that
> related to
> GETVPN.
> 2. The TOS field in the header - What does this have to do frag and
> reassembly. That was the posters question.
> 3. Lack of vectors such as the use of AH and ESP protocols - Lack of
> what?
> You mean the protocols that IPSec uses? How is that related to the
> original
> posters question? And why even mention AH...does GETVPN use AH or
> ESP?
>
> And lastly, you said something about RFC2402. What does the AH RFC
> have to
> do with frag and reassembly in IPSec? That RFC explains how and
> where it
> occurs but certainly does not state how Cisco implements it (and
> doesn't
> answer the question of the original poster).
>
> And, how exactly is Cisco not following that RFC like you stated?
> Which
> section(s) specifically?
>
>
> On Nov 3, 2009, at 3:44 PM, "Tony Varriale"
> <tvarriale_at_flamboyaninc.com> wrote:
>
>> 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/>
>>>>>>
>>>>>>
>> _______________________________________________________________________

>
>
>
>>>
>>>
>>>>>
>>>>>
>>>>>> Subscription information may be found at:
>>>>>>
>>>>
>>> <http://www.groupstudy.com/list/CCIELab.html
>> <http://www.groupstudy.com/list/CCIELab.html%3e%3c> ><
>>> http://www.groupstudy.com/list
>>>> /CCIELab.html>
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> ------------------------------
>>>> Bing brings you maps, menus, and reviews organized in one place.
>>>> Try
>>>> it
>>>>
>>> now.<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=
>>>
>> &form=MFESRP&publ=WLHMTAG&crea=>
>>> &form=MFESRP&publ=WLHMTAG&crea=
>>>> TEXT_MFESRP_Local_MapsMenu_Resturants_1x1>
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net <http://www.ccie.net/
>>>>>
>>>>
>>>> _______________________________________________________________________

>
>
>
>>>
>>>
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net <http://www.ccie.net/
>>>>>
>>>>
>>>> _______________________________________________________________________

>
>
>
>>>
>>>
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Mark Jackson, CCIE #4736
>>> Senior Network, Security and Voice Architect
>>>
>>> 858.705.1861
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________

>
>
>
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Mark Jackson, CCIE #4736
>> Senior Network, Security and Voice Architect
>>
>> 858.705.1861
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________

>
>
>
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________

>
>
>
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________

> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Nov 03 2009 - 16:43:10 ART