Re: Cisco GET VPN in transport mode

Sorry I said that. That was wrong of me and I apologize.
The Tony guy brought out the wrong person. That is not the real me.
Again, I truely apologize.

Mark Jackson, CCIE#4736

Sent from my iPhone
Please excuse spelling errors

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

> 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 - 15:22:02 ART