Re: Cisco GET VPN in transport mode

I guess my next question is where does that leave me???
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
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.
I have always made sure to not only explain myself technically but
present a real-world example.
Also show where I have said anythig in terms of best practice that is
not specfically detailed within Cisco's lifecycle.
So if you can't provide where I have in fact done what you are saying
I did, I'd suggest you be quite.
And yes, I let me temper show. Not good. I'm human.
Since you feel you are the GS police into what is acceptable. I humbly
will no longer answer emails.
If anyone does want to ask me a question:

markcciejackson_at_gmail.com

Go day Tony.
Good luck all, I wish you the best.

Mark Jackson, CCIE#4736

Sent from my iPhone
Please excuse spelling errors

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 - 15:55:40 ART