Subject: [IPsec] Issue #130: Do we need to bump the minor version number?

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Dec 2009 14:21:28 -0800

Section 1.7 (Differences Between RFC 4306 and This Document) states:

   The protocol described in this document retains the same major
   version number (2) and minor version number (0) as was used in RFC
   4306.  That is, the version number is *not* changed from RFC 4306.

Section 2.5 (Version Numbers and Forward Compatibility) states

   The minor
   version number indicates new capabilities, and MUST be ignored by a
   node with a smaller minor version number, but used for informational
   purposes by the node with the larger minor version number.  For
   example, it might indicate the ability to process a newly defined
   notification message.  The node with the larger minor version number
   would simply note that its correspondent would not be able to
   understand that message and therefore would not send it.

New notifies have been added to the bis draft.   Is a bump in the minor
number warranted?  Is there a down side to bumping the minor number?

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 17 Dec 2009 12:58:26 +0200

Or else, we could remove the sentence "For example, it might indicate the ability to process a newly defined notification message." I thinking bumping the minor version number would be extremely risky. We know that everybody can ignore unknown notifications. We don't know that everybody can deal correctly with version number, simply because this has been tested less frequently.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Thursday, December 17, 2009 0:21
To: IPsecme WG
Subject: [IPsec] Issue #130: Do we need to bump the minor version number?

   The minor

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Dec 2009 14:20:33 +0200

Yaron Sheffer writes:
> Or else, we could remove the sentence "For example, it might
> indicate the ability to process a newly defined notification
> message."

That is example what changing minor number might mean. All current
conforming implementations already know how to process our newly
defined error notifications (they assume exchange failed), thus there
is no need to update minor number, as there is no new ability needed
for implementations to process those notifications.

There is no reason to change that text. It does not require us to do
something, it is just example.

> I thinking bumping the minor version number would be
> extremely risky. We know that everybody can ignore unknown
> notifications. We don't know that everybody can deal correctly with
> version number, simply because this has been tested less frequently.

Agree on that.
-- 
[email-masked]

---

From: Richard Graveman <[email-masked]>
Date: Thu, 17 Dec 2009 07:41:03 -0500

I think the criterion should be:

Would a reasonable and correct implementation need to have an IF
statement, e.g., if(minor_number == 1) ...

I do not not think the criterion should be whether bumping the number
breaks older implementations.

>From the discussion, leaving the number alone seems fine.

Richard

---

From: David Wierbowski <[email-masked]>
Date: Thu, 17 Dec 2009 11:13:08 -0500

I think it is reasonable to expect that an IKEv2 bis implementation would
use an IF statement to control sending the new Notify types.  If the minor
number was changed an implementation could check the minor version and send
the new notify types when the minor version was 1 and send the notify types
recommended in RFC 4718 if the minor number was 0.  That is what my
implementation plans to do if the minor version number is bumped.

I'm not sure I agree with Tero that an implementation getting an unknown
TEMPORARY_FAILURE notify would always take the same action that it would if
it received NO_PROPOSAL_CHOSEN as suggested by RFC 4718.

Dave Wierbowski

  From:       Richard Graveman <[email-masked]>                                                       
                                                                                                            
  To:         Tero Kivinen <[email-masked]>                                                                 
                                                                                                            
  Cc:         IPsecme WG <[email-masked]>, Paul Hoffman <[email-masked]>                             
                                                                                                            
  Date:       12/17/2009 07:41 AM                                                                           
                                                                                                            
  Subject:    Re: [IPsec] Issue #130: Do we need to bump the minor version number?                          
                                                                                                            
  Sent by:    [email-masked]                                                                        

Richard

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Dec 2009 12:30:02 +0200

David Wierbowski writes:
> use an IF statement to control sending the new Notify types.

No they should just use new notifies, as all old complient
implementations will work with those new error messages also.

There is no reason to send old error notifications.

> If the minor number was changed an implementation could check the
> minor version and send the new notify types when the minor version
> was 1 and send the notify types recommended in RFC 4718 if the minor
> number was 0.

There is no point of supporting old RFC4718 error notifications after
you implement IKEv2bis as new error notifications are backward
compatible with old ones. Also RFC4718 used text like "thus failing
the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems
like a reasonable approach." which clearly indicates that other error
notifications are also possible, thus whether other end sends
NO_PROPOSAL_CHOSEN or CHILD_SA_NOT_FOUND error notification, as
recipient will process them both in a same way, and expect that
exchange failed. 

> That is what my implementation plans to do if the minor version
> number is bumped.

I do not think I will ever implement RFC4718 error notifications (we
have not implemented it yet, and now when we have IKEv2bis almost
ready, I do not think we ever will), thus for me it does not really
matter, but I think it would be much easier to just change those error
notifications you already have in the code to use CHILD_SA_NOT_FOUND
and TEMPORARY_FAILURE instead of NO_ADDITIONAL_SAS and
NO_PROPOSAL_CHOSEN without adding any extra logic based on the minor
version number.

> it received NO_PROPOSAL_CHOSEN as suggested by RFC 4718.

Then it is not complient to RFC4306, as RFC4306 clearly says that if
you get uknown error notification then you "MUST assume that the
corresponding request has failed entirely".

RFC4718 does not (and cannot) modify the meaning of NO_PROPOSAL_CHOSEN
error notification it just gives you examples what kind error
notifications could be used in which case, but I do not think it gives
you instructions what to do when you receive such error notifications.

This was one of the things needed to be added to the IKEv2bis, and
that was the reason we needed to have separate error notifications as
we wanted to be sure that it is easy to decide what to do when you get
error notification back (i.e. in addition to assuming that exchange
failed). 
-- 
[email-masked]