[IPsec] IKEv2-only implementation question

[Tero Kivinen]

Scott C Moonen writes:
 I'm curious how IKEv2-only implementations have approached the problem of
 dealing with IKEv1 proposals. IKEv2 defines an INVALID_MAJOR_VERSION
 notify, but it only carries a maximum version and not a minimum version. (I
 wonder if that is an oversight.) IKEv1 (in RFC 2408) defines an
 INVALID-MAJOR-VERSION notify which MAY be sent. The RFC does not discuss
 whether the notify carries any data.

If you have IKEv2-only implementation then you do not support IKEv1,
thus you cannot really even parse incoming IKEv1 messages or generate
response IKEv1 messages, so most likely you should silently discard
the packet.

 If I wanted to send an IKEv1 not supported indication from an IKEv2-only
 daemon, I think I would use the IKEv1 INVALID-MAJOR-VERSION notify and not
 send any SPI or notification data in the payload.

I.e. you implement minimal IKEv1 implementation in your IKEv2-only
implementation which knows how to get IKEv1 packet in, and response to
it that INVALID-MAJOR-VERSION in IKEv1. 

 How have existing IKEv2-only implementations approached this? Do you ignore
 IKEv1 messages, or do you send an error notification in response?

In our case we do response with the same protocol (i.e if incoming
messages are in IKEv1, we reply with IKEv1). As our implementation
also do support IKEv1, even when it is disabled by policy, we do not
answer with INVALID-MAJOR-VERSION. In our case we just reply with
similar error which we use when the policy does not match
(NO-PROPOSAL-CHOSEN), i.e. we interpret the IKE version as part of the
policy, just as encryption algorithm etc would be.

For your case if you really have IKEv2-only implementation, I do not
think there is any good interoperable way to solve the issue. Most
likely sending the minimal IKEv1 reply with INVALID-MAJOR-VERSION
would be best, as at least that can be parsed by the initiator sending
IKEv1 messages, and will most likely be shown in the logs, so
adminstrators can then reconfigure the system to try with IKEv2,
provided the implementation supports IKEv2. On the other hand if the
implementation supports IKEv2, it should first try with that as there
is clearly defined fall-back mechanims from IKEv2 to IKEv1.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Fwd: New Version Notification for draft-nir-ipsecme-erx-03.txt

[Yoav Nir]

Hi all.

This is the 3rd iteration of the draft I presented about in Paris.

We would like this working group to accept this, and have it added to charter. 
Of course, if it gets accepted, we volunteer to be authors. If it is not 
accepted, we will try to progress it as an individual submission, but we 
believe that this changes IKE enough that it should come from the working group.

Yoav  Qin

Begin forwarded message:

 From: internet-dra...@ietf.org internet-dra...@ietf.org
 Subject: New Version Notification for draft-nir-ipsecme-erx-03.txt
 Date: April 12, 2012 1:33:48 PM GMT+03:00
 To: Yoav Nir y...@checkpoint.com
 Cc: sunse...@huawei.com sunse...@huawei.com
 
 A new version of I-D, draft-nir-ipsecme-erx-03.txt has been successfully 
 submitted by Yoav Nir and posted to the IETF repository.
 
 Filename:  draft-nir-ipsecme-erx
 Revision:  03
 Title: An IKEv2 Extension for Supporting ERP
 Creation date: 2012-04-12
 WG ID: Individual Submission
 Number of pages: 7
 
 Abstract:
   This document describes an extension to the IKEv2 protocol that
   allows an IKE Security Association (SA) to be created and
   authenticated using the EAP Re-authentication Protocol extension as
   described in RFC 5296bis.
 
   NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with
   the RFC number assigned to that document.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.txt

[Paul Hoffman]

On Apr 12, 2012, at 11:17 AM, Yoav Nir wrote:

 We would like this working group to accept this, and have it added to 
 charter. Of course, if it gets accepted, we volunteer to be authors. If it is 
 not accepted, we will try to progress it as an individual submission, but we 
 believe that this changes IKE enough that it should come from the working 
 group.


Statements of interest and disinterest on this document are welcome. If you 
prefer to make such a statement off-list please send it to me or Yaron.

A statement of interest that include a promise to review in WG LC count for 
more than a bare statement of interest.

--Paul Hoffman

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec