Did a wiresharp capture and observed the following with both tunnel and
transport mode:

ESP Encryption + ESP Authentication
---- >  ESP encrypts ESP authenticated data
ESP Encryption + AH Authentication
---- >  AH authenticates ESP encrypted data.
ESP Encryption + ESP Authentication + AH Authentication         ---- >  AH
authenticates ESP encrypted ESP authenticated data


With regards
Kings

On Sat, Jun 11, 2011 at 5:17 PM, Kingsley Charles <
[email protected]> wrote:

> Just did a bit of thinking and arrived at the  following understanding for
> ESP Encryption + AH Authentication based on the snippet from the RFC.
>
>  + transport mode  -----> ESP does encryption first and then AH
> authenticates the entire packet
>
> ESP Encryption + AH Authentication + tunnel mode  -----> AH does
> authentication first and then ESP encapsulates the authenticated packet.
>
>
> Wireshark should give a better picture...
>
>
> With regards
> Kings
>
>
> On Sat, Jun 11, 2011 at 4:58 PM, Kingsley Charles <
> [email protected]> wrote:
>
>> Hi all
>>
>> When IPSec uses ESP encryption with ESP authentication or ESP encryption
>> with AH authentication, what would be order of encryption and
>> authentication? Will the encryption be done first and then authentication or
>> the vice versa?
>>
>> For ESP encryption with ESP authentication, my understanding is that the
>> data is first encrypted and then authentication is done.. The authentication
>> happens from the ESP header to the ESP trailer. So with transport mode, the
>> original IP address is not authentication and in tunnel mode, the new IP
>> header is not authenticated.
>>
>> When ESP encryption and AH authentication is used, what would be the
>> order? The following snippet confuses me a bit.
>>
>> The following snippet
>>
>> Snippet  from http://www.faqs.org/rfcs/rfc1827.html
>>
>> 4.3. Authentication
>>
>>    Some transforms provide authentication as well as confidentiality and
>>    integrity.  When such a transform is not used, then the
>>    Authentication Header might be used in conjunction with the
>>    Encapsulating Security Payload.  There are two different approaches
>>    to using the Authentication Header with ESP, depending on which data
>>    is to be authenticated.  The location of the Authentication Header
>>    makes it clear which set of data is being authenticated.
>>
>>    In the first usage, the entire received datagram is authenticated,
>>    including both the encrypted and unencrypted portions, while only the
>>    data sent after the ESP Header is confidential.  In this usage, the
>>    sender first applies ESP to the data being protected.  Then the other
>>    plaintext IP headers are prepended to the ESP header and its now
>>    encrypted data. Finally, the IP Authentication Header is calculated
>>    over the resulting datagram according to the normal method.  Upon
>>    receipt, the receiver first verifies the authenticity of the entire
>>    datagram using the normal IP Authentication Header process.  Then if
>>    authentication succeeds, decryption using the normal IP ESP process
>>    occurs.  If decryption is successful, then the resulting data is
>>    passed up to the upper layer.
>>
>>    If the authentication process were to be applied only to the data
>>    protected by Tunnel-mode ESP, then the IP Authentication Header would
>>    be placed normally within that protected datagram.  However, if one
>>    were using Transport-mode ESP, then the IP Authentication Header
>>    would be placed before the ESP header and would be calculated across
>>    the entire IP datagram.
>>
>>    If the Authentication Header is encapsulated within a Tunnel-mode ESP
>>    header, and both headers have specific security classification levels
>>    associated with them, and the two security classification levels are
>>    not identical, then an error has occurred.  That error SHOULD be
>>    recorded in the system log or audit log using the procedures
>>    described previously.  It is not necessarily an error for an
>>    Authentication Header located outside of the ESP header to have a
>>    different security classification level than the ESP header's
>>    classification level.  This might be valid because the cleartext IP
>>    headers might have a different classification level after the data
>>    has been encrypted using ESP.
>>
>>
>>
>> With regards
>> Kings
>>
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

Reply via email to