Per my recollection, during the interim last week, Yaron clarified that even
though he had made
the suggestion to do away with the Next Header field, he did not feel strongly
about it.
His point is valid, though: if it is not found to be useful, then the field
should not be included.
Your po
Hi,
I'd personally like to see the "Next Header" field retained in the WESP header.
It becomes extremely easy for the ASICs (even off the shelf ones like Broadcom,
Wintegra, etc) to look at a fixed offset in the packet for a particular byte
pattern and decide on what it needs to do with that pa
At 12:19 AM +0300 5/12/09, Yaron Sheffer wrote:
>In two words, why not? What is the exact new requirement you are referring
>to?
"multiple CERT payloads of type 4 MUST be used". That is a new requirement.
>More generally, this is not some obscure part of the RFC that we're
>discussing. This is p
In two words, why not? What is the exact new requirement you are referring
to?
More generally, this is not some obscure part of the RFC that we're
discussing. This is possibly the most mainstream usage scenario. And we need
to make every effort possible in order to ensure interoperability.
Thanks
At 7:40 PM +0530 5/11/09, ss murthy nittala wrote:
Hi,
Is it required for IV to be randomly generated for each ESP packet
in case of AES-CTR and AES-CBC methods?
AES-CTR:My understanding is that IV is to be generated randomly for
the first packet.For each new outgoing packet increment IV and
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working
Group of the IETF.
Title : Redirect Mechanism for IKEv2
Author(s) : V. Devarapalli, K. Weniger
F
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 sent, multiple CERT
>payloads of ty
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 sent, multiple CERT
payloads of type 4 MUST be used, the first of which holds the publi
At 3:23 PM +0300 5/11/09, Tero Kivinen wrote:
>There is text about this in multiple places in the RFC4306.
...barely. It is only clear in section 1.2, not in subsections of Section 3.
The topic of cert chains is barely discussed. I will clear this up in the next
draft.
--Paul Hoffman, Director
At 8:22 PM +0530 5/11/09, ss murthy nittala wrote:
>The following sentence present in RFC 3602 creates some doubts whether IV in
>each packet is mandatory or not?
>
>"Including the IV in each datagram ensures that decryption of each
> received datagram can be performed, even when some datagrams ar
At 5:23 PM +0300 5/11/09, Tero Kivinen wrote:
>I think it is quite obvious that you are not supposed to use multiple
>hash and url of X.509 bundle payloads, even when it is not
>specifically forbidden.
Fully disagree. We have no prohibition against this, and I can imagine corner
cases where it wo
On Mon, May 11, 2009 at 08:22:05PM +0530, ss murthy nittala wrote:
>
> The following sentence present in RFC 3602 creates some doubts whether IV
> in each packet is mandatory or not?
>
> "Including the IV in each datagram ensures that decryption of each
> received datagram can be performed, even
> "ss" == ss murthy nittala writes:
ss> The following sentence present in RFC 3602 creates some doubts
ss> whether IV in each packet is mandatory or not?
ss> "Including the IV in each datagram ensures that decryption of
ss> each received datagram can be performed, even when some datagram
The following sentence present in RFC 3602 creates some doubts
whether IV in each packet is mandatory or not?
"Including the IV in each datagram ensures that decryption of each
received datagram can be performed, even when some datagrams are
dropped, or datagrams are re-ordered in transit."
ss murthy nittala writes:
> Is it required for IV to be randomly generated for each ESP packet in
> case of AES-CTR and AES-CBC methods?
>
> AES-CTR:My understanding is that IV is to be generated randomly for
> the first packet.For each new outgoing packet increment IV and use it.
>From RFC3686
On Mon, May 11, 2009 at 07:40:22PM +0530, ss murthy nittala wrote:
> Hi,
> Is it required for IV to be randomly generated for each ESP packet in
> case of AES-CTR and AES-CBC methods?
I don't know about AES-CTR, but definitely in AES-CBC.
> AES-CBC:Is it required for IV to be randomly generated
David Wierbowski writes:
>
> > Tero said:
> >
> > For the X.509 bundle I think the format is more clear and only one
> > CERT payload is sent containing hash and url of all certificates and
> > crls needed (and first certificate there is the one used for AUTH
> > payload).
>
> Tero, I do not agre
Hi,
Is it required for IV to be randomly generated for each ESP packet in
case of AES-CTR and AES-CBC methods?
AES-CTR:My understanding is that IV is to be generated randomly for
the first packet.For each new outgoing packet increment IV and use it.
AES-CBC:Is it required for IV to be random
> Tero said:
>
> For the X.509 bundle I think the format is more clear and only one
> CERT payload is sent containing hash and url of all certificates and
> crls needed (and first certificate there is the one used for AUTH
> payload).
Tero, I do not agree that it is more clear that only one CERT
Yoav Nir writes:
> Or I can go with option (d) and send multiple CERT payloads, as Pasi
> suggested here:
> http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html
This is what most implementations currently do.
> Either way, we should have it clear what is and is not allowed in
> section 3.6.
Th
Yoav Nir writes:
> I've submitted issue #107 about certificate encoding.
>
> IMO it's not clear how certificate chains are to be encoded in IKEv2.
>
> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107
If certificate chain is sent using X.509 certificate - signature (4)
format, then it is sen
Pasi.Eronen wrote:
>
> Yoav Nir wrote:
> > > You can:
> > >
> > > a) start using hash-and-url
> > >
> > > b) hope your peer has the sub-CA
> > >
> > > c) write an extension to 4306 that allows bundles in CERT
> > >
> > > Doing (a) is the most interoperable, but you're probably
> save with
> > >
Yoav Nir wrote:
> > You can:
> >
> > a) start using hash-and-url
> >
> > b) hope your peer has the sub-CA
> >
> > c) write an extension to 4306 that allows bundles in CERT
> >
> > Doing (a) is the most interoperable, but you're probably save
> > with (b) in a typical closed network.
>
> Or I can g
23 matches
Mail list logo
