Re: FW: Cisco GET VPN in transport mode

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