Re: Cisco GET VPN in transport mode

Sorry mark, didn't know you were under that rock... The humble request was for everybody, not subhumans.

Sorry for being honest!

Sent via BlackBerry from T-Mobile

-----Original Message-----
From: mark jackson <markcciejackson_at_gmail.com>
Date: Tue, 3 Nov 2009 15:16:51
To: itguy.pro_at_gmail.com<itguy.pro_at_gmail.com>
Cc: Tony Varriale<tvarriale_at_flamboyaninc.com>; ccielab_at_groupstudy.com<ccielab_at_groupstudy.com>; pborghese_at_groupstudy.com<pborghese_at_groupstudy.com>
Subject: Re: Cisco GET VPN in transport mode

I'm using 'reply all'.
But since I know your so fond of it. I'll use forward going forward. I
might even create a forward rfc.
Sorry to be so stright forward...

Mark Jackson, CCIE#4736

Sent from my iPhone
Please excuse spelling errors

On Nov 3, 2009, at 3:12 PM, itguy.pro_at_gmail.com wrote:

> Can you ladies not use forward link when replying to these emails?
> Try the "reply all," really, it works, no RFCs required.
>
>
> Sent via BlackBerry from T-Mobile
>
> -----Original Message-----
> From: Mark Jackson <markcciejackson_at_gmail.com>
> Date: Tue, 3 Nov 2009 15:05:55
> To: Tony Varriale<tvarriale_at_flamboyaninc.com>
> Cc: <ccielab_at_groupstudy.com>; <pborghese_at_groupstudy.com>
> Subject: Re: FW: Cisco GET VPN in transport mode
>
> Now Paul,I know my words were not inline with the code of conduct
> put forth
> by Group Studies.
> For that I understand if you remove me from the list.
> I am only here to be helpful and learn.
> Tony, while never violating the terms. Has come off as arrogant,
> abrasive
> and while providing limited help. I see him provoding no real benefit.
> My .cents.
> I will go away now.
> Sorry to have cluttered up every ones inbox with my negative email.
> Thanks kindly.
>
> On Tue, Nov 3, 2009 at 3:02 PM, Mark Jackson
> <markcciejackson_at_gmail.com>wrote:
>
>> 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]
>>> 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]
>>> 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] 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&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&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&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>
>>>> 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&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
>>
>
>
>
> --
> 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
Received on Tue Nov 03 2009 - 23:19:52 ART