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 - Si
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. This is consistent with the genera
The ipsecme WG will have a virtual interim WG meeting in about a month. We
will have a conference call on Tuesday September 22, 15:00 GMT (18:00
Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on
the same format as the previous time: a VoIP conference bridge and posted
slides
Hi Yoav,
This text (to be added for this specific encoding) duplicates the existing
text at the end of this same section.
Moreover, we keep saying "multiple certificates" without mentioning the
semantics of these multiple certs, i.e. they should form a trust chain.
Thanks,
Yaron
> -
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) contains a DER encoded X
On Wed, Aug 26, 2009 at 03:52:11PM +0300, Tero Kivinen wrote:
> I wrote better long description about the problem, and also proposed
> solution text at 2009-04-07:
> http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html
The text referenced above summarizes the problem AND solution qu
Thanks Tero. Good catches. We'll address them in the upcoming revision.
> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Monday, 24 August, 2009 6:03 AM
> To: ipsec@ietf.org
> Cc: draft-ietf-ipsecme-traffic-visibil...@tools.ietf.org; ipsecme-
> cha...@tools.ietf.or
We use multiple certificate payloads when using X.509 Certificate -
Signature (4) encoding.
I do not really see how this could be questioned. RFC 4306 clearly says
X.509 Certificate - Signature (4) encoding contains a single certificate as
pointed out below. The logical conclusion is that if y
Yaron Sheffer writes:
> What this doesn't say is how we send this chain of certificates. Is it
> multiple separate CERT payloads (in that case it should say so) or is it a
> single CERT payload (and then we should also say so)
If you use format that can only store one certificate (for example
X.5
Good. So how about we close this issue by adding the last sentence
below:
If
multiple certificates are sent, the first certificate MUST contain
the public key used to sign the AUTH payload. The other
certificates
may b
Martin Willi writes:
> It is not even clear from the spec how to encode multiple certificates
> in a single cert payload with type 4 (just concatenate?).
There is no way to encode more than one certificate with X.509
Certificate - Signature (#4) format in one certificate payload.
--
kivi...@iki.
Yaron Sheffer writes:
> [2.23, NAT Traversal]
> > o Implementations MUST process received UDP-encapsulated ESP packets
> >even when no NAT was detected.
> >
> > o The original source and destination IP address required for the
> >transport mode TCP and UDP packet checksum
Yoav Nir writes:
> But if it's different IP addresses for different applications, then
> there are probably also different traffic selectors for these
> applications, and then possibly different IPsec SAs.
Most likely, but it is still most likely going to be few -> many
mapping, i.e. you have few
Interesting.
But if it's different IP addresses for different applications, then there are
probably also different traffic selectors for these applications, and then
possibly different IPsec SAs.
If that's the case, then maybe it does make sense to get IP addresses in the
Create_Child SA excha
Hi Yoav,
These applications are using same IKE SA for allocating IP to the
application specific virtual interfaces, which can be more than one. Let me
know if you further clarification.
Thanks & Regards,
Raj
2009/8/26 Yoav Nir
> Hi Raj.
> The issue is concerned with Config payload in Child SA
Hi,
> Input from actual implementations (and bakeoffs) will be most valuable
> here.
We and I think all vendors I have tested against use multiple
certificate payloads (however, multi-level CA is a feature not tested
with many participants).
It is not even clear from the spec how to encode multi
16 matches
Mail list logo
