On Fri, 2 Nov 2012, Paul Hoffman wrote:
: The design team decided it is best to add just one new authentication
: method, that will support all kinds of signature methods. This
: includes all ECDSA and other EC-based methods (ECGDSA) and can also
: support other algorithms too (RSA-PSS or even ElG
Hi Tero, thank you for your comments.
A general comment: I think we already decided in the WG that we will
go with the tcp approach, not with this fragmentation layer in the
IKEv2. Why do we have this document here?
As others pointed out this draft is not a WG item.
Some other comments
In s
Tero Kivinen wrote:
TK> In addition to the IKE_AUTH there is another big class of UPD
TK> packets which can be large, and which might get fragmented, i.e
TK> udp encapsulated nat traversal IPsec UDP packets. If the
>> I don't think you are suggesting any specific technical change
I have forwarded this to the IETF, and left out the IPsec mailing list on
purpose, so that future messages are not copied here.
Please reply to that list.
Yoav
Begin forwarded message:
From: Yoav Nir mailto:y...@checkpoint.com>>
Subject: Re: Comments to the draft-nir-ipsecme-erx-07.txt
Date:
Michael Richardson writes:
> Tero Kivinen wrote:
> TK> In addition to the IKE_AUTH there is another big class of UPD
> TK> packets which can be large, and which might get fragmented, i.e
> TK> udp encapsulated nat traversal IPsec UDP packets. If the
>
> I don't think you are suggestin
draft-kivinen-ipsecme-oob-pubkey -- 15 mins
Motivations
Description of problem that is being solved
Question about whether this updated 5996 to replace RSA raw key format
The question is, I think whether this is an extension to 5996, or an
update?If an update, then it
What in practice, for an implementer and/or his marketing manager, is
the difference between "MAY" for algorithm and not listing it at all?
I would understand if we had "MAY+", but really, that is what "SHOULD" means.
Could there implications on UIs, such that things listed SHOULD/MUST
are list
I read ipsec-ike-tcp-00. I found it very clear.
section 3 says:
> An initiator using this policy MUST NOT go to TCP if the responder
> has not indicated support by sending the IKE_TCP_SUPPORTED
> notification (Section 2.5) in the Initial response.
...
> Yet another policy would be to b
Tero Kivinen wrote:
TK> --
TK> Specifically, the messages of the IKE_AUTH exchange can become
TK> quite large, as they may contain a chain of certificates, an
TK> "Auth" payload (that may contain a public key sign
As Tero mentioned on another thread, the "related docs" section is
created automatically based on keyword matching. You'll need to rename
the I-D to draft-harkins-ipsecme-ikev3.
Thanks,
Yaron
On 11/04/2012 05:35 PM, Dan Harkins wrote:
On Sun, November 4, 2012 5:29 am, Paul Hoffman w
Paul Hoffman writes:
> On Nov 3, 2012, at 10:37 PM, Tero Kivinen wrote:
> > A general comment: I think we already decided in the WG that we will
> > go with the tcp approach, not with this fragmentation layer in the
> > IKEv2. Why do we have this document here?
> We don't. Documents listed as "Rel
On 11/2/12 2:27 PM, Paul Hoffman wrote:
Greetings again. Here is the long-sought-after consensus report from the design
team that was tasked with a proposal for better supporting ECDSA certificates
in IKEv2.
If you have any concern for this topic, please read the proposal below and send
comme
On Sun, November 4, 2012 5:29 am, Paul Hoffman wrote:
> On Nov 3, 2012, at 10:37 PM, Tero Kivinen wrote:
>
>> A general comment: I think we already decided in the WG that we will
>> go with the tcp approach, not with this fragmentation layer in the
>> IKEv2. Why do we have this document here?
>
I am afraid that only multi-paths cannot enhance the security.
As Tero commented, if one can decrypt one path, then it is a successful
security breach already.
I think the point is that what is the definition of "insecure network", and the
definition of the "security" here.
From a cryptographic
On Nov 3, 2012, at 10:37 PM, Tero Kivinen wrote:
> A general comment: I think we already decided in the WG that we will
> go with the tcp approach, not with this fragmentation layer in the
> IKEv2. Why do we have this document here?
We don't. Documents listed as "Related Documents" on the Datatr
15 matches
Mail list logo
