RE: Cisco GET VPN in transport mode

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
Received on Tue Nov 03 2009 - 18:19:49 ART