Graham Bartlett (grbartle) writes:
> There’s many references to IKEv2 in the paper. E.g.
There is references to the IKEv2, but the paper is not talking about
the IKEv2. It is clear from the packet traces (see version number),
and the retransmission behavior seen.
In the IKEv2 the responder will
This version has many significant changes from the previous draft.
Please review it soon so we don't have a lot of surprises in WG Last
Call.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
The problem is that the last message comes from the initiator, and if this
message
got lost, the initiator never knew about it it unless the responder
retransmits the response
to the very first message from the initiator. It's an immanent feature of
IKEv1
caused by odd number of messages in
On Wed, 16 Mar 2016, internet-dra...@ietf.org wrote:
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-04
This version introduces an RSA key size table and a
I still do not see that:
AggrOutI1 --->
< AggrOutR1
[ rest of exchange ]
If AggrOutI1 is dropped:
AggrOutI1 ---> X
AggrOutI1 --->
< AggrOutR1
[ rest of exchange ]
If AggrOutR1 is dropped:
AggrOutI1 --->
X <
On Wed, 16 Mar 2016, Yoav Nir wrote:
Really? Granted, it’s been a couple of years since I’ve checked the VPN
capabilities of an iPhone, but I remember it having L2TP (using IKEv1) and
XAuth (A Cisco extension to IKEv1). We have some people from Apple in the
working group who are talking
On Wed, 16 Mar 2016, Valery Smyslov wrote:
No, because it is perfectly possible to implement IKEv1 without this
problem. Libreswan is moving towards that, see:
https://lists.libreswan.org/pipermail/swan-dev/2016-March/001394.html
Making only the initiator be responsible for
>
> Or perhaps we need the IKEv1 considered harmful draft /
> ikev1-diediediediedie...
I don't think that will help. I've seen how reluctant people are to change
their 10 year old working VPN.
IKEv1 is dying pretty quickly now, thanks to mobile phones. But it will be
another year or two.
Tero Kivinen wrote:
> What we could say in the DDoS draft is to add saying that IKEv1
> protocol is obsoleted, and will be common avenue for the DDoS attacks,
> and because of that it MUST be disabled.
> Or perhaps we need the IKEv1 considered harmful draft /
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 of the
IETF.
Title : Algorithm Implementation Requirements and Usage
Guidance for IKEv2
Authors : Yoav Nir
at this point initiator completed the exchange and has working IKE SA.
However, since AggOutI2 is lost, then responder doesn't have IKE SA yet.
Since initiator has ready IKE SA it has no reasons to retransmit AggOutI2.
The only way responder can force initiator to retransmit AggOutI2 is
to
These are all backwards compatible things. The cool things are happening at
IKEv2, and the management tools and required features will push users to v2.
Sure static v1 site to site will remain in place until 3des or hmac-md5 is
broken (and they'd still not upgrade)
Just make sure people don't
This is just a friendly reminder that the WGLC on
draft-ietf-ipsecme-ddos-protection-04.txt ends on March 18th, 2016.
The list discussion has been good on the draft. Thank you to everyone that
commented so far.
If you have any additional comments, please send them to the list by the end of
13 matches
Mail list logo