IPsec

IPsec with encryption alone provides no integrity protection
(if the ciphertext is modified, junk is decrypted); this is
not a good idea, as there a need for integrity protection
usually accompanies needs for encryption.

For some forms of encryption, the cipher doesn't
scramble bits (each bit of ciphertext depends on only the
corresponding bit of plaintext), and hence integrity protection
is needed to prevent ciphertext changes that have predictable
plaintext effects.  AES counter-mode is one example.

Thanks,
--David

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Sukanta ganguly
> Sent: Tuesday, November 30, 2004 10:21 AM
> To: Michael C. Cambria; RDDP
> Subject: Re: [rddp] Need some clarification on how to "locate 
> the start of theFPDU unambiguously"
> 
> MikeC,
>   IPSec with encryption will also attain the same
> level of integrity and hence it should be OK.
> Encryption based on IPSec is a much better mechanism
> rather than just CRC32c.
>    I am not sure what you mean by "negotiating the
> policy down". Once the IPSec connection with the
> remote pair is established that is your policy, which
> is established at the time of connection setup.
> 
> SG
> 
> --- "Michael C. Cambria" <[email protected]> wrote:
> 
> > 
> > 
> > Caitlin Bestler wrote:
> > 
> > > Keep in mind that "CRC suppression" does not
> > eliminate the field,
> > > only generating it and checking it. 
> > > 
> > > So my reading has always been that when CRCs are
> > "suppressed" 
> > > that the CRC field is always "valid".
> > 
> > This has been my assumption as well.
> > 
> > > Given the scenarios identified for suppressing
> > CRCs, when there
> > > is equivalent protection from IPSEC or something
> > else, I think
> > > it is also clear that this was the intent.
> > 
> > Since I'm on the subject of making assumptions
> > explicit...
> > 
> > When IPsec is mentioned in this context, doesn't it
> > specifically mean 
> > IPsec with Authentication (or Authentication &
> > Encryption)?   IPsec with 
> > Encryption alone isn't a substitute for CRC32c.
> > 
> > This is also assuming that the IPsec SPD is setup to
> > ensure that this 
> > policy will happen, e.g. there is no way for the
> > remote peer to 
> > negotiate the security policy "down".
> > 
> > Regards,
> > MikeC
> > 
> > 
> > _______________________________________________
> > rddp mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/rddp
> > 
> 
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - Helps protect you from nasty viruses. 
> http://promotions.yahoo.com/new_mail
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>