Is there a new draft/rfc posted with the change incorporated?
-ns murthy
From: ipsec-boun...@ietf.org on behalf of Stephen Kent
Sent: Tue 5/12/2009 8:39 PM
To: Murthy N Srinivas-B22237
Cc: ipsec@ietf.org
Subject: Re: [IPsec] IV in ESP packets for DES and 3DES me
If we elect to keep the next header field, to help middle boxes
quickly locate header fields of interest to them, then we MUST
require the recipient of each message to do a (well-defined)
consistency check on the packet, for the reasons I cited in SF.
Steve
___
2405 is out of date. Its recommendation re using the last 8 octets of
ciphertext from the previous packet has been replaced with one of
using a randomly-generated IV for each packet.
Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mai
Let me draw a time-sequence diagram to explain things as I understand
them (fixed-width font alert)
site to site policy
policy: 1.0.0.0/8 <-> 2.0.0.0/8
Alice-GW Bob-GW
--Trigger--> (1.2.3.4->2.3.4.5)
(1)
> > There are a lot of boxes deployed in the field that cant do what you
> > seem to be suggesting.
>
> Those deployed boxes will need updates anyways, as they do not support
> WESP either...
I had meant that there are boxes currently deployed in the field which would
have HW capable of only
Bhatia, Manav (Manav) writes:
> There are a lot of boxes deployed in the field that cant do what you
> seem to be suggesting.
Those deployed boxes will need updates anyways, as they do not support
WESP either...
> If we are to pick up the "Next Header" from the ESP trailer then we
> need to pa
> -Original Message-
> From: Yoav Nir [mailto:y...@checkpoint.com]
> Sent: Tuesday, May 12, 2009 3:42 AM
> To: ssmurthy.nitt...@freescale.com
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods
>
> On Tue, 2009-05-12 at 10:05 +, ss murthy nittala
There are a lot of boxes deployed in the field that cant do what you seem to be
suggesting.
If we are to pick up the "Next Header" from the ESP trailer then we need to
parse the entire packet with the variability in the ICV length. This would
entail storing the entire IPv4/Ipv6 packet (coming
gabriel montenegro writes:
> Your point below about Next Header being useful is specially
> valuable as it is from someone involved in developing these boxes.
If the box can do IPv6 header processing (which do require similar
offset calculations) to find the WESP header in the first place, then
do
On reconsideration, I agree with Manav that the NH field will be useful for
hardware implementations. Let's keep it.
Thanks,
Yaron
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> gabriel montenegro
> Sent: Tuesday, May 12, 2009 2:
Paul Hoffman writes:
> At 3:09 PM +0300 5/11/09, Yaron Sheffer wrote:
> >Or possibly:
> >
> >X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate
> >whose public key is used to validate the sender's AUTH payload. With this
> >encoding, if a chain of certificates needs to be se
WARNING: contains banned part
--- Begin Message ---
On Tue, 2009-05-12 at 10:05 +, ss murthy nittala wrote:
> Hi
>
> Thanks for the clarifications regarding IV usage for AES methods.
>
> RFC 2405 (DES) in its implementation note says
>
> "Common practice is to use random data for the first I
Hi
Thanks for the clarifications regarding IV usage for AES methods.
RFC 2405 (DES) in its implementation note says
"Common practice is to use random data for the first IV and the last
8 octets of encrypted data from an encryption process as the IV for
the next encryption process; this logic
13 matches
Mail list logo
