Re: Need some clarification on how to "locate the start of theFPDU unambiguously"
Sukanta ganguly <[email protected]> Tue, 30 Nov 2004 07:20:54 -0800 (PST)
| Newsgroups | gmane.ietf.rddp |
|---|---|
| Message-ID | <[email protected]> |
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