Subject: [IPsec] I-D Action: draft-harkins-ike-iana-update-00.txt

From: "Dan Harkins" <[email-masked]>
Date: Wed, 23 Nov 2011 09:03:46 -0800 (PST)

Hello,

  There is a new draft available that some of you may be interested
in looking at. Please send your comments to the list.

  regards,

  Dan.

On 11/17/11 3:18 AM, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
> 	Title           : A Modest Proposal to Update IKE's IANA Registry
> 	Author(s)       : Dan Harkins
> 	Filename        : draft-harkins-ike-iana-update-00.txt
> 	Pages           : 5
> 	Date            : 2011-11-17
>
>     The "IPSEC Authentication Methods" registry created by IKE states
>     that it can only be updated by Standards Track RFC.  In practice,
>     this has not been the case.  This memo proposed to relax that
>     requirement.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-harkins-ike-iana-update-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-harkins-ike-iana-update-00.txt
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 24 Nov 2011 15:15:15 +0200

> in looking at. Please send your comments to the list.

I see no point of just updating one registry in the isakmp-registry
(http://www.iana.org/assignments/isakmp-registry) and ipsec-registry
(http://www.iana.org/assignments/ipsec-registry).

Especially when we are talking about the protocol that was obsoleted
in 2005.

I myself would pick "Obsoleted registry, no more allocations allowed"
for all of the IKEv1 registries. Unfortunately I am sure there are too
many people objecting to that change, so I do not see it very likely.

Anyways, if something is done to the IKEv1 registries, they should be
cleaned up completely, i.e. someone would need to go through all the
registries, check out if the relevant document actually mentions
anything about the registration procedures or not, and update the IANA
registries accordingly.

For the most registries (including the "IPSEC Authentication Methods
(Value 3)") the RFC2409 says "values 6-65000 are reserved to IANA."
without giving out any hint which kind of registration procedure is
needed.

For some things like adding new attribute classes it does say that
"Standard-Track RFC", for some others like Encryption Algorithms it
says "reference to a standards-track or Informational RFC or a
reference to published cryptographic literature which describes this
algorithm." which would most likely mean "Specification Required".

As you point out in your draft there are several allocations without
any stable reference, and I would suggest we remove those. If there is
no specification how to implement it, there is no way anybody can make
interoperable implementations out of them either.

Going through the IKEv1 IANA registries has been on my todo list of
some time, but as this protocol has already been obsoleted for more
than 5 years, and the registries are very old, I have just assumed
there is no hurry...
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 25 Nov 2011 10:34:45 +0300

Hi,

I found some contradicting text in RFC5996.

Section 3.10 describes Protocol ID field in Notify Payload and
includes the following text:

   Protocol ID (1 octet) - If this notification concerns an existing
   SA whose SPI is given in the SPI field, this field indicates the
   type of that SA.  For notifications concerning Child SAs, this
   field MUST contain either (2) to indicate AH or (3) to indicate
   ESP.  Of the notifications defined in this document, the SPI is
   included only with INVALID_SELECTORS and REKEY_SA.  

On the other hand, section 2.25 describes using CHILD_SA_NOT_FOUND
notification and includes the following text:

   A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
   a request to rekey a Child SA that does not exist.  The SA that the
   initiator attempted to rekey is indicated by the SPI field in the
   Notify payload, which is copied from the SPI field in the REKEY_SA
   notification.  

>From my reading, these two pieces of text are contradicting.
The first paragraph forbids putting SPI in SPI field of Notify
Payload for all notifications other than INVALID_SELECTORS and REKEY_SA,
while the second requires to do it for CHILD_SA_NOT_FOUND.

Do I misunderstand something?

Regards,
Valery Smyslov.

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Fri, 25 Nov 2011 14:19:01 +0530

No, in my understanding, we should not send SPI value in Notify payload
telling CHILD_SA_NOT_FOUND.
As the SPI sent by the initiator of rekey has sent wrong SPI, which the
responder doesn't have.
Thus, first paragraph states correctly.

Thanks,
Prashant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Valery Smyslov
Sent: Friday, November 25, 2011 1:05 PM
To: [email-masked]
Subject: [IPsec] Contradiction in RFC5996

Hi,

Regards,
Valery Smyslov.

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 25 Nov 2011 14:42:55 +0300

Yes, paragraph 3.10 gives a generic rule, that SPI field
in Notify Payload must refer to existing SA. And
CHILD_SA_NOT_FOUND indicates that SA doesn't
exist, so we seem to be not allowed to use it.
But, on the other hand, receiver of this notification
does have that SA (otherwise he/she wouldn't previously send
notification REKEY_SA), so the rule isn't violated.
At least, it could be interpreted not to be violated...

But anyway, contradiction must be removed - either by addition
CHILD_SA_NOT_FOUND to the list of notifications
using SPI field (preferred way, IMHO, because it doesn't
break any running code) or by rewriting text about
CHILD_SA_NOT_FOUND notification directing to put SPI
somewhere else apart from SPI field (probably to notification data).

Regards,
Valery Smyslov.

----- Original Message -----
From: "Prashant Batra (prbatra)" <[email-masked]>
To: "Valery Smyslov" <[email-masked]>; <[email-masked]>
Sent: 25 ноября 2011 г. 11:49
Subject: RE: [IPsec] Contradiction in RFC5996

Thanks,
Prashant

-----Original Message-----

Hi,

Regards,
Valery Smyslov.

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Fri, 25 Nov 2011 16:22:20 +0530

Section 2.25 states-
A peer that receives a CHILD_SA_NOT_FOUND notification
   SHOULD silently delete the Child SA (if it still exists) and send a
   request to create a new Child SA from scratch (if the Child SA does
   not yet exist).

So it should delete that CHILD_SA by himself.
Regards,
Prashant

-----Original Message-----
From: Valery Smyslov [mailto:[email-masked]] 
Sent: Friday, November 25, 2011 5:13 PM
To: Prashant Batra (prbatra); [email-masked]
Subject: Re: [IPsec] Contradiction in RFC5996

Regards,
Valery Smyslov.

----- Original Message -----
From: "Prashant Batra (prbatra)" <[email-masked]>
To: "Valery Smyslov" <[email-masked]>; <[email-masked]>
Sent: 25 ноября 2011 г. 11:49
Subject: RE: [IPsec] Contradiction in RFC5996

Thanks,
Prashant

-----Original Message-----

Hi,

Regards,
Valery Smyslov.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 25 Nov 2011 16:11:57 +0300

The question is: what should SPI field of a CHILD_SA_NOT_FOUND notification contain.
>From my reading of 2.25 sender of this notification should take SPI from the SPI field of
received REKEY_SA notification and put it to the SPI field of CHILD_SA_NOT_FOUND:

    The SA that the  initiator attempted to rekey is indicated by the SPI
    field in the Notify payload, which is copied from the SPI field in the REKEY_SA
    notification.

Is it correct?

Regards,
Valery Smyslov.

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Fri, 25 Nov 2011 18:09:24 +0530

Still I think not correct,

What it tells is that,  the initiator of the rekey is trying to rekey the child_sa indicated by SPI value in REKEY_SA notify payload.
Not that, the sender of CHILD_SA_NOT_FOUND should copy the SPI sent in REKEY_SA to the spi in CHILD_SA_NOT_FOUND notify payload.

Regards,
Prashant

-----Original Message-----
From: Valery Smyslov [mailto:[email-masked]] 
Sent: Friday, November 25, 2011 6:42 PM
To: Prashant Batra (prbatra); [email-masked]
Subject: Re: [IPsec] Contradiction in RFC5996

Is it correct?

Regards,
Valery Smyslov.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 25 Nov 2011 14:45:05 +0200

Hi Valery

I believe that you are correct. The text in section 2.25 clearly says that the SPI field is populated, while section 3.10 says that this field is populated only for INVALID_SELECTORS and REKEY_SA. 

Section 3.10 was carried over from RFC 4306, while section 2.25 is new to 5996. The error is in section 3.10.

Please file an errata on the RFC Errata page.
http://www.rfc-editor.org/errata.php

Thanks

Yoav

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Fri, 25 Nov 2011 19:04:29 +0530

Hi,

I think that’s fine. You are correct. I re-read the section.

Regards,
Prashant

-----Original Message-----
From: Prashant Batra (prbatra) 
Sent: Friday, November 25, 2011 6:09 PM
To: 'Valery Smyslov'; [email-masked]
Subject: RE: [IPsec] Contradiction in RFC5996

Regards,
Prashant

-----Original Message-----
From: Valery Smyslov [mailto:[email-masked]] 
Sent: Friday, November 25, 2011 6:42 PM
To: Prashant Batra (prbatra); [email-masked]
Subject: Re: [IPsec] Contradiction in RFC5996

Is it correct?

Regards,
Valery Smyslov.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Nov 2011 16:02:26 -0500

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:
    Tero> As you point out in your draft there are several allocations
    Tero> without any stable reference, and I would suggest we remove
    Tero> those. If there is no specification how to implement it, there
    Tero> is no way anybody can make interoperable implementations out
    Tero> of them either.

<TCPDUMP HAT ON>
Yes, but at least they can decode what encryption 12345 "was"....

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 30 Nov 2011 15:41:16 +0200

> Yes, but at least they can decode what encryption 12345 "was"....

I think the normal practice is to change the removed values to
"Reserved (was xxx)", which would be enough for TCPDUMP style uses,
but would make it clear that nobody should try to implement them and
expect them to be interoperable with someone else...
-- 
[email-masked]