Scott C Moonen writes:
Tero, I am not comfortable with the following statement:
. . . thus it will send back traffic selectors having IPN1 and IP2
as their IP addresses . . .
I would prefer that the server re-map the TS values back to IP1 and IPN2
when sending its response.
All of which taken together indicates the Sec. 3.6 needs to be rewritten.
It'll be hard enough to get interoperability with all these options, but
certainly if much remains undocumented.
We might even need to resort to defining what the mythical minimal
implementation is allowed to do.
Thanks,
I would repeat my comment from April:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.html
If we continue to allow CP in INFORMATIONAL exchange (and IMHO we should), it
should be allowed in CREATE_CHILD_SA, too (with exactly same semantics).
Best regards,
Pasi
From:
I'll second that.
Yaron
_
From: pasi.ero...@nokia.com [mailto:pasi.ero...@nokia.com]
Sent: Thursday, August 27, 2009 14:06
To: Yaron Sheffer; ipsec@ietf.org
Subject: RE: #79: Remove CP from Create_Child_SA?
I would repeat my comment from April:
I disagree.
Payloads in a particular CREATE_CHILD_SA exchange should be specifically
related to the SA being created. The IKE_AUTH exchange is different, because
it is used to set up everything we need to get an IPsec SA going.
We do not use the CREATE_CHILD_SA to delete old SAs, to query
David Wierbowski writes:
I agree with Tero that Yoav's proposed text adds clarity and effectively
it
does not add a new MUST; however, to address Paul's concern can we just
change the words MUST be to the word are or lower case should be?
For example:
o X.509 Certificate - Signature (4)
On Thu, Aug 27, 2009 at 5:43 PM, Tero Kivinen kivi...@iki.fi wrote:
Bhaskar Dutta writes:
Does any IPSec implementation support RFC 3554 (On the Use of Stream Control
Transmission Protocol (SCTP) with IPsec)?
Yes. Altough I do not know if it has been really tested (mostly just
using
Hi Bhasker,
This document will help you:
http://www.ipsec-howto.org/ipsec-howto.pdf
*It has sample configs for racoon.
*Thanks Regards,
Raj
On Thu, Aug 27, 2009 at 6:53 PM, Bhaskar Dutta bhas...@gmail.com wrote:
On Thu, Aug 27, 2009 at 5:43 PM, Tero Kivinen kivi...@iki.fi wrote:
Yoav Nir wrote:
I disagree.
Payloads in a particular CREATE_CHILD_SA exchange should be
specifically related to the SA being created. The IKE_AUTH exchange
is different, because it is used to set up everything we need to get
an IPsec SA going.
If we were designing IKEv2 from scratch, I
Tero, in short:
1) I still prefer to echo back TS payloads as I described. I realize that
the TS payloads are the only opportunity that IKEv2 has to reproduce the
effect of IKEv1's NAT-OA payloads. But using the traffic selectors in
this way -- and only if the responder ends up agreeing to
On Thu, Aug 27, 2009 at 10:36 PM, Raj Singhrsjen...@gmail.com wrote:
Hi Bhasker,
This document will help you:
http://www.ipsec-howto.org/ipsec-howto.pdf
It has sample configs for racoon.
Thanks Regards,
Raj
Hi Raj,
I'd already gone through this howto as well as several others. I
11 matches
Mail list logo
