Subject: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Nov 2009 16:37:22 -0800

This has flummoxed a few reviewers. Tables such as those in section 3.3.2 are already out of date because things have been added since RFC 4306. I propose that we remove all these tables from IKEv2bis, and add notes pointing to the current IANA registries. I cannot see how doing this lookup will hurt developers: in fact, it forces them to actually look at the up-to-date tables. I can see how we might want to leave the tables in, but it really is confusing.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan McDonald <[email-masked]>
Date: Mon, 23 Nov 2009 20:12:28 -0500

On Mon, Nov 23, 2009 at 04:37:22PM -0800, Paul Hoffman wrote:

> This has flummoxed a few reviewers. Tables such as those in section 3.3.2
> are already out of date because things have been added since RFC 4306. I
> propose that we remove all these tables from IKEv2bis, and add notes
> pointing to the current IANA registries. I cannot see how doing this lookup
> will hurt developers: in fact, it forces them to actually look at the
> up-to-date tables. I can see how we might want to leave the tables in, but
> it really is confusing.

Can you move 'em to an appendix, with a permanent URL reference to the IANA
up-to-date versions?

Dan

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Nov 2009 17:27:36 -0800

>Can you move 'em to an appendix, with a permanent URL reference to the IANA

As long as you mean "an appendix that clearly says 'these were in RFC 4306 but are now out-of-date but are here just for reference and you want to look at <URL>'", I'm OK with that as well.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan McDonald <[email-masked]>
Date: Mon, 23 Nov 2009 20:37:32 -0500

On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote:
> As long as you mean "an appendix that clearly says 'these were in RFC 4306
> but are now out-of-date but are here just for reference and you want to
> look at <URL>'", I'm OK with that as well.

I'd actually go one better -- snapshot what's on IANA today (or the day
before RFC-editor pulls the switch) with the warning you quote ('... just
for reference and you want to look at <URL>').  The warning and URL is the
critical part.

Dan

---

From: Dan McDonald <[email-masked]>
Date: Mon, 23 Nov 2009 20:41:27 -0500

On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote:
<SNIP!>

> The warning and URL is the critical part.

"are the critical part," - uggh, mustn't press Send so quickly.

Dan

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Nov 2009 17:46:12 -0800

>for reference and you want to look at <URL>').  The warning and URL is the

Oh, yuck. No. I could see doing this to keep the "bis" nature of the document intact by providing the old tables, but not creating a clone of the IANA registry. I *really* don't think it is that hard for a developer to resolve a URL and read the tables there.

--Paul Hoffman, Director
--VPN Consortium

---

From: Steven Bellovin <[email-masked]>
Date: Mon, 23 Nov 2009 22:20:29 -0500

On Nov 23, 2009, at 8:46 PM, Paul Hoffman wrote:
> I *really* don't think it is that hard for a developer to resolve a URL and read the tables there.

Leave out the table; give the URL and mention 4306.  If you have two more-or-less authoritative sources for the same information, some folks will use one and some the other.  Point to the URL as *the* source, and say that it subsumes all values given in 4306.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 24 Nov 2009 08:54:29 +0200

Hi Paul,

Please add to Issue #123 a list of the affected tables. For example, I wouldn't imagine the list of notification types moving away, even though it's already been extended by IANA. Similarly for the stuff in Sec. 3.6, which is strongly related to descriptive text.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Steven Bellovin
> Sent: Tuesday, November 24, 2009 5:20
> To: Paul Hoffman
> Cc: [email-masked]; Dan McDonald
> Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from
> IKEv2bis
> 
> 
> Leave out the table; give the URL and mention 4306.  If you have two more-
> or-less authoritative sources for the same information, some folks will
> use one and some the other.  Point to the URL as *the* source, and say
> that it subsumes all values given in 4306.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: <[email-masked]>
Date: Tue, 24 Nov 2009 13:31:58 +0100

Typically IETF specs don't require someone implementing RFC NNNN to
actually find and read the IANA registry -- all the needed numbers are
in the RFC. (The IANA registry is just an IETF process tool for making 
sure the same number doesn't get used for multiple purposes, not
part of the actual protocol specification.)

Perhaps the "reserved to IANA: 12-200" etc. lines are slightly
confusing, and we could omit them (and say something like "this
document specifies the meaning of these values; to find what
values are specified in other documents, go look at the IANA
registry")

Best regards,
Pasi

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Paul Hoffman
> Sent: 24 November, 2009 02:37
> To: IPsecme WG
> Subject: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
> 
> This has flummoxed a few reviewers. Tables such as those in section
> 3.3.2 are already out of date because things have been added since RFC
> 4306. I propose that we remove all these tables from IKEv2bis, and add
> notes pointing to the current IANA registries. I cannot see how doing
> this lookup will hurt developers: in fact, it forces them to actually
> look at the up-to-date tables. I can see how we might want to leave the
> tables in, but it really is confusing.
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 24 Nov 2009 16:17:11 +0200

Paul Hoffman writes:
> 3.3.2 are already out of date because things have been added since
> RFC 4306. I propose that we remove all these tables from IKEv2bis,
> and add notes pointing to the current IANA registries. I cannot see
> how doing this lookup will hurt developers: in fact, it forces them
> to actually look at the up-to-date tables. I can see how we might
> want to leave the tables in, but it really is confusing. 

I would be in favor of removing the tables which are updated
frequently, but I think most of the tables should still stay in the
IKEv2bis. For example I think IKEv2 exchange types, Next Payload
Types, Protocol ID, Transform type values etc should stay, but for
example tables like Transform type 1 (Encryption Algorithm) could
point to the IANA registry.

I.e if table is integral part of the protocol, then it should stay in
the IKEv2bis document, but if it is something like listing of crypto
algorithm etc, then it can be changed to point to the IANA registry.

Mostly that means that if the IANA registry has some other RFC(s) as
reference for the values in the registry (ENCR_3DES points ot RFC2451
etc, PRF_HMAC_MD5 points to RFC2104) then it it is useful to put
references to the IANA registry.

On the other hand if only references in the IANA registry is back to
the RFC4306 (or IKEv2bis document in future), then its bit pointless
to ask people to go to the iana registry to see that they should read
this document they are reading to get more information :-)

For examples of such registries are Next Payload Type, Transform Type
Values, IKEv2 Transform Attribute Types, IKEv2 Identification Payload
ID Types, IKEv2 Certificate Encodings...
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Nov 2009 09:30:56 -0800

Yes, I should have worked this out more fully before posting.

In all cases, I would add a reference to the IANA registry.

Only lists code points: remove the whole table
  2.22: IPComp Tranform IDs
  3.1: Exchange types
  3.3.1: Protocol ID
  3.3.2: Encryption, PRF, integrity, DH group, ESN
  3.3.5: Transform attributes
  3.15: CFG type

Lists semantics, remove the code points but leave the semantics:
  3.5: Identification types
  3.10.1: Notify messages
  3.13.1: Traffic selectors

Other:
 3.2: Next payload type -- remove value
 3.3.2: Transform type -- remove type number
 3.3.3: Transform types by protocol -- leave in whole table
 3.6: Certificate encoding -- remove type number, leave in UNSPECIFIED
 3.15.1: Attribute types -- remove type number

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 24 Nov 2009 23:29:52 +0200

Hi Paul,

I have marked below with an asterisk those that I think should stay in the document, because they are important to understanding/implementing the protocol.

Overall, I'm not sure this exercise is worth our time. In particular if we strip tables of their values, there's a high risk of introducing inconsistencies between the document and the IANA registry.

Thanks,
	Yaron

> Paul Hoffman
> Sent: Tuesday, November 24, 2009 19:31
> To: IPsecme WG
>   3.1: Exchange types [*]
>   3.3.1: Protocol ID [*]
>   3.3.5: Transform attributes [* ??]
>   3.15: CFG type [*]
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 14:41:46 +0200

>   3.3.2: Encryption, PRF, integrity, DH group, ESN

I can agree removing those whole tables.

>   3.3.5: Transform attributes

These I would leave in, but remove the RESERVED, RESERVED TO IANA and
PRIVATE USE lines, i.e. leave only the values used in this document.
These are needed when developing the protocol, and having yet another
indirection there would just be annoying developers.

>   3.13.1: Traffic selectors

I would keep values for those too, but remove RESERVED/PRIVATE etc
ranges, i.e. keep numbers needed to implement this protocol (and
referenced by this RFC), but by removing the reserved and private use
range definitions, it makes it clear this is not full list, so if
someone wants to see full list, they need to go to the iana-registry.

>  3.15.1: Attribute types -- remove type number

I.e. leave number. 

>  3.3.3: Transform types by protocol -- leave in whole table

This I agree :-)
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Nov 2009 08:39:08 -0800

Based on Tero and Yaron's responses, I have a different idea:

- Leave all the tables in

- Remove the numbers from every table

- Removed the "reserved", "reserved to IANA", and "private use" lines

- Precede each table with the following boilerplate paragraph:
   The following table only lists the entries that appeared
   in [IKEV2]. There may be new entries, private use values,
   and so on; see [IKEV2IANA] for up-to-date information.

- Add [IKEV2IANA] to the Normative References; it will point to the URL of the IANA registry.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan McDonald <[email-masked]>
Date: Wed, 25 Nov 2009 11:52:55 -0500

On Wed, Nov 25, 2009 at 08:39:08AM -0800, Paul Hoffman wrote:

<mucho snippage deleted!>

> - Add [IKEV2IANA] to the Normative References; it will point to the URL of

Yes, this is better.

Dan

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Nov 2009 13:25:59 +0200

> - Leave all the tables in

I think the encryption, hash algorithm etc tables could be removed
completely, i.e. the Transform type n tables in section 3.3.2. Those
tables change quite often, and they are not really needed for
implementation, as almost every implementation will anyways only
implement some of those, and/or offer a way to easily add new
algorithms when those come.

>   URL of the IANA registry.

These all are ok for me.

> - Remove the numbers from every table

I would rather keep the numbers for those tables which are really
needed for implementing the protocol.

I hate when I am implementing something and reading the RFC, and then
suddenly I notice that I need to go and fetch some url somewhere to
find the actual numbers, even worse when I am doing that in airplane
or similar where I do not have network connectivity... Usually I
assume that if I need to implement RFCxxxx, I should be able to do it
mostly by using just that RFC or some other RFCs. This is not true
always as there are references to the crypto algorithms found in
textbooks, or standards defined by other bodies, but here I do not
think there is reason to require using external reference.

The numbers that are there in the tables are not going to change, so
they will not get outdated, they will not get to be wrong. There might
be new ones added, and the warning you propose should take care of
that.

If there would be an possiblity that for example Exchanget type
IKE_AUTH could change from its current value of 35 to something else,
then I would agree leaving it out from the RFC, but as it is going to
be that same number forever, I do not see any reason why I should use
indirection to find out what that number is.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Nov 2009 09:11:13 -0800

>needed for implementing the protocol.

And here we disagree completely.

>or similar where I do not have network connectivity...

In this case, you only need to fetch a single page from IANA for all the tables. If you did that for any of the tables, you would have it for all of them.

It does not feel appropriate to optimize for the case of someone coding IPsec without Internet access for a few hours.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 26 Nov 2009 19:24:46 +0200

Given the amount of interest on the list, I prefer the "do nothing" approach. Just add this text somewhere (maybe multiple times):

	This table is (these tables are) only current as of the publication date of RFC 4306. Other values may have been added since, or will be added after the publication of this document. Implementors are advised to refer to [IANA] for the latest values.

And be done with it.

Thanks,
	Yaron

> Sent: Thursday, November 26, 2009 19:11
> To: Tero Kivinen
> Cc: IPsecme WG
> In this case, you only need to fetch a single page from IANA for all the
> tables. If you did that for any of the tables, you would have it for all
> of them.
> 
> It does not feel appropriate to optimize for the case of someone coding
> IPsec without Internet access for a few hours.
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Nov 2009 15:28:01 -0800

At 7:24 PM +0200 11/26/09, Yaron Sheffer wrote:
>Given the amount of interest on the list, I prefer the "do nothing" approach.

That makes no sense. People seem interested in fixing the problem of the lists being confusing.

There is nothing confusing about removing the assigned numbers: it only causes a developer who is actively coding at the moment to grab one file from IANA. That file will contain all of the values needed for developing from IKEv2bis (including the two new values we are assigning), and will also contain values and pointers for other extensions in which they might be interested.

Removing the assigned numbers also causes people who will be expanding on IKEv2bis to actually fetch the IANA registry before they do their work. We have a recent example of why that would be useful.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 27 Nov 2009 11:42:51 +0300

Hi, let me pop into with my 2 cents.

As an implementer, I strongly dislike an idea to remove all the numbers from
the RFC.
In my opinion, that would confuse people even more than now, for the
following reasons:

1. Magic numbers would become splited between two sources (note, that not
all of them
    are listed in IANA, for example payload types are, but Proposal and
Transform
    substructures types are not, they are specified in the RFC only).

2. IANA registry already contains some very specific entries (like, for
example,
    those that came from RFC4595) and their number will be increasing. I
think,
    those numbers would confuse some implementers, who might be thinking
    that they need to support all of them.

3. Sometimes there might be difficulties in matching names from RFC with
IANA entries.
    For example, IANA registry has an entry named ENCR_AES-CCM_8, but in
    RFC5282 this algorithm is called AEAD_AES_128_CCM_SHORT_8. Are you sure
    these names reference the same algorithm? I prefer to check their IDs in
RFC
    and in IANA registry.

4. Some entries in Diffie-Hellman Group Transform IDs table do not really
assign
    individual numbers, but instead point to other documens, even to RFC4306
itself,
    where the numbers are assigned.

By the way, some magic numbers in RFC4306 are present not only in tables,
but
in text also (for example Payload Types, TS Types). Do they need to be
removed
from text also? What about EAP Message format and magic numbers?
Remove and just reference RFC3748 (or IANA entry for EAP)?

I think, removing all magic numbers from the RFC would make implementing
less convinient and more error-prone, so I strongly support either "do
nothing"
approach, or Tero's suggestion. Those numbers won't change, so their
presence must not hurt, just will make implementing of base protocol more
convinient.

Regards,
Smyslov Valery.

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>
To: "IPsecme WG" <[email-masked]>
Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

> There is nothing confusing about removing the assigned numbers: it only
causes a developer who is actively coding at the moment to grab one file
from IANA. That file will contain all of the values needed for developing
from IKEv2bis (including the two new values we are assigning), and will also
contain values and pointers for other extensions in which they might be
interested.
>
> Removing the assigned numbers also causes people who will be expanding on
IKEv2bis to actually fetch the IANA registry before they do their work. We
have a recent example of why that would be useful.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Nov 2009 13:07:22 +0200

> the lists being confusing. 

I agree that we should do something. 

> There is nothing confusing about removing the assigned numbers: it
> only causes a developer who is actively coding at the moment to grab
> one file from IANA. That file will contain all of the values needed
> for developing from IKEv2bis (including the two new values we are
> assigning), and will also contain values and pointers for other
> extensions in which they might be interested. 

Not only those who are coding, but also those are debugging or
supporting implementations, as quite often they do not remember all
the numbers or the packet formats exactly, so they use the RFC to
check out the packet formats and numbers, and only if numbers are not
there then they need to go to IANA. 

> Removing the assigned numbers also causes people who will be
> expanding on IKEv2bis to actually fetch the IANA registry before
> they do their work. We have a recent example of why that would be
> useful. 

I do not think this would have caused anything, as I most likely would
have also picked numbers 40, and 41 anyways because I remember that 39
was last number used in RFC4306... There is reason why there is IANA
assignment phase in the RFC assignment process, so there was no harm
done even when someone took some numbers instead of using TBA1 and
TBA2.

If we split this to three parts:

1) I think almost everybody can agree that we can remove RESERVED and
   PRIVATE use ranges and numbers from the all tables, and add notice
   saying these are partial lists and go and check IANA for full list.

2) I think quite a lot of people agree that we should remove algorithm
   tables i.e ENCR_*, PRF_*, AUTH_*, Diffie-Hellman groups, extended
   sequence number tables and IPCOMP_*, i.e. all Transform type 1-5
   tables and IPCOMP transform ID table from the RFC.

3) The thing we do not all agree on is whether to keep the numbers for
   the rest of the tables. I.e. do we want to remove numbers from rest?

I myselfo would say yes for 1, and 2, and no for 3. 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Nov 2009 09:16:33 -0800

>    substructures types are not, they are specified in the RFC only).

This is incorrect. The proposal is to remove the value numbers from the tables, not the figures that contain the substructures. Anything that is only in the RFC would obviously not be removed.

>    that they need to support all of them.

If a developer does not know how to read the IANA tables, we are all in trouble. Nothing in the tables says "you must implement every thing in these tables", of course.

Are you proposing that we get rid of the IANA registry altogether, or we hide it from developers? If not, how do you rectify this with your concern about confusion?

I am now deeply concerned with this WG's relationship to the IANA registry.

>    these names reference the same algorithm? I prefer to check their IDs in

This is a bug in the IANA registry that needs to be fixed. It is not related to the values being in the RFC. Tero has spent a lot of time trying to fix the registry, but clearly we need more effort here. I will certainly make sure that the names in the registry match those in RFC 4306, and that the exact names are used in IKEv2bis.

>    where the numbers are assigned.

Again, I am concerned that you think we should get rid of the IANA registry. That is not how the IETF works.

>from text also?

Yes, in my current draft, I already did that, and repeated the boilerplate.

> What about EAP Message format and magic numbers? Remove and just reference RFC3748 (or IANA entry for EAP)?

No, those were left in because they came from an RFC, not from a particular IANA registry where the names match what we have in IKEv2bis.

>less convinient

Yes.

>and more error-prone

No.

>, so I strongly support either "do
>nothing"
>approach, or Tero's suggestion.

This is completely inconsistent. Tero's approach would lead you to need the IANA registry to implement IKEv2.

>Those numbers won't change, so their
>presence must not hurt,

This is probably incorrect. In many WGs, when errors are found in old definitions, the error is corrected *and a new value is assigned*. That is the only way to assure interoperability.

>just will make implementing of base protocol more
>convinient.

The goal of our work is clarity and interoperability, not convenience, particularly when the inconvenience is remedied by one extra lookup.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 27 Nov 2009 23:11:17 +0300

Hi Paul,

please, see inline.

> If a developer does not know how to read the IANA tables, we are all in 
> trouble. Nothing in the tables says "you must implement every thing in 
> these tables", of course.
>
> Are you proposing that we get rid of the IANA registry altogether, or we 
> hide it from developers?

Not, of course.

> If not, how do you rectify this with your concern about confusion?

For someone, who spent quite a lot of time working in this area, it is not
difficult fo figure out what is really important and what is not. But, I 
think,
a newcomer could be confused by a long list of all possible numbers.

> This is a bug in the IANA registry that needs to be fixed. It is not 
> related to the values being in the RFC. Tero has spent a lot of time 
> trying to fix the registry, but clearly we need more effort here. I will 
> certainly make sure that the names in the registry match those in RFC 
> 4306, and that the exact names are used in IKEv2bis.

For RFC4306 that seems to be true.

> Again, I am concerned that you think we should get rid of the IANA 
> registry. That is not how the IETF works.

No, you didn't get the point. I meant that Diffie-Hellman Group Transform 
IDs table
in two cases doesn't assign individual numbers, just ranges. For example:

1-2           Defined in Appendix B               [RFC4306]
14-18        Defined in [RFC3526]               [RFC3526]

So, in first case it just points back to RFC4306 Appendix B, where the 
actual
numbers (what is 1 and what is 2) are assigned. Probably it may (and must)
be changed, but in its current form it's ridiculos - you went to IANA for
real numbers and have found only pointer back to RFC4306 where you
just have come from...

>> What about EAP Message format and magic numbers? Remove and just 
>> reference RFC3748 (or IANA entry for EAP)?
>
> No, those were left in because they came from an RFC, not from a 
> particular IANA registry where the names match what we have in IKEv2bis.

EAP numbers listed in RFC4306 might also be changed in future,
so from your logic it's better just to point to
http://www.iana.org/assignments/eap-numbers, right?

>>I think, removing all magic numbers from the RFC would make implementing

I don't agree with you. Remember, when IKEv2 was being developed,
one of the motivations for single self-contained document was complaint
from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1
was very inconvinient and provoked confusions that led to interoperability
problems. Now you suggest to make IKEv2 not self-contained again.
Of course, I understand that IANA registry is not another RFC, but
I still prefer single self-contained document for core protocol.
If you need extensions - go to IANA and look for added numbers,
but core protocol must be implementable reading as few sources,
as possible, preferrably one.

> the IANA registry to implement IKEv2.

Tero's approach is a compromise. You will need the IANA only for
few types of magic numbers, most of which don't affect protocol
logic. I can leave with it.

> This is probably incorrect. In many WGs, when errors are found in old 
> definitions, the error is corrected *and a new value is assigned*. That is 
> the only way to assure interoperability.

As far as I understand, in this case new RFC must be issued,
which will obsolete current one, won't it? If so, no contradiction.

> The goal of our work is clarity and interoperability, not convenience, 
> particularly when the inconvenience is remedied by one extra lookup.

Just out of curiosity: is such approach (removing magic numbers from RFC
completely) widely used in IETF? If memory serves me, all RFC I've read
contained their magic numbers (of course they were duplicated in IANA)
and that didn't lead to interoperability problems, I think. What is an 
origin
for your conclusion that this practice leads to the lack of interoperability
(of course if RFC and IANA are synchronized)?

Regards,
Smyslov Valery.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 28 Nov 2009 07:32:38 -0800

At 11:11 PM +0300 11/27/09, Valery Smyslov wrote:
>>Are you proposing that we get rid of the IANA registry altogether, or we hide it from developers?
>
>Not, of course.
>
>difficult fo figure out what is really important and what is not. But, I think,

This answer is inconsistent, and that's the crux of the issue I have with your concern. We very much want developers to look at the IANA registry; it's the only way for them to know definitively what values will cause interoperability. Yet you say things like "a newcomer could be confused by a long list of all possible numbers". You can't have it both ways.

>No, you didn't get the point. I meant that Diffie-Hellman Group Transform IDs table
>So, in first case it just points back to RFC4306 Appendix B, where the actual

These are the full definition of the semantics of the groups. How would you change this?

>http://www.iana.org/assignments/eap-numbers, right?

Yes, but *only* if the names and numbers we use in this document match those exactly *and* the WG is willing to cede change control to the EAP methods we use to the IANA registry that we do not have input to. So far, the WG hasn't said they want to do that, so I don't presume to make that change.

>problems.

Correct.

>Now you suggest to make IKEv2 not self-contained again.

Correct, because we have already made many changes to the values that developers need to know.

>I still prefer single self-contained document for core protocol.

Of course, but your preference is at odds with the preference of someone reading the document needing to understand the context for the values.

>as possible, preferrably one.

Seriously: how hard is "two"? Any serious developer can go look at a second URL to get the values.

>logic. I can leave with it.

This seems inconsistent to me ("it's OK to need a second file for some things but not others").

>which will obsolete current one, won't it? If so, no contradiction.

That is not true. The new RFC can update just a portion of the old one. That is how this is normally handled in the IETF.

>completely) widely used in IETF?

I do not know if our situation has ever happened in the IETF for a major protocol. I will ask around and report back on that.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 30 Nov 2009 00:19:04 +0300

> This answer is inconsistent, and that's the crux of the issue I have with 
> your
> concern. We very much want developers to look at the IANA registry;
> it's the only way for them to know definitively what values will cause
> interoperability. Yet you say things like "a newcomer could be confused
> by a long list of all possible numbers". You can't have it both ways.

You probably speaks about "ideal" developers. I speak about real people.
I've seen a few cases when people implemented a bunch of really
unnecessary things just because "it was in standard".

> These are the full definition of the semantics of the groups. How would 

Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not 
defined in IANA.
For me this is inconsistent. Either change two abovementioned lines to:

1             768-Bit MODP Group                    [RFC4306]
2             1024-Bit MODP Group                  [RFC4306]

14           2048-Bit MODP Group                  [RFC3526]
15           3072-Bit MODP Group                  [RFC3526]
16           4096-Bit MODP Group                  [RFC3526]
17           6144-Bit MODP Group                  [RFC3526]
18           8192-Bit MODP Group                  [RFC3526]

or, if you think that current situation is OK, then why no to change other 
tables
in the same fashion and leave all numbers in the RFC. Just for example:

Value     Next Payload Type                Notation   Reference
--------  -------------------------------  ---------  ---------
0          No Next Payload                             [RFC4306]
1-32     Reserved                                       [RFC4306]
33-48     Defined in [RFC4306]                    [RFC4306]
49-127    Unassigned                                  [RFC4306]
128-255   Private use                                 [RFC4306]

At least this will made things consistent.

> Yes, but *only* if the names and numbers we use in this document match 
> those exactly
> *and* the WG is willing to cede change control to the EAP methods we use 
> to the IANA
> registry that we do not have input to. So far, the WG hasn't said they 
> want to do that,
> so I don't presume to make that change.

I fail to understand your logic here. You seem to want to have ability to 
change
already assigned numbers in IKEv2 in the future (and for this purpose remove
them from RFC), but at the same time you seem to presume  that other
groups will not ever change their numbers. By the way, at least one RFC 
outside
ipsecme WG (I mean RFC5106, EAP-IKEv2) has already listed some of IKEv2
magic numbers (payload types) and has already presumed that they won't 
change.

> Correct, because we have already made many changes to the values that 

Those new values could be listed in IKEv2bis RFC, which will update RFC4306.

> Of course, but your preference is at odds with the preference of someone
> reading the document needing to understand the context for the values.

I fail to understand how removing values from the RFC will help
understanding the context for them.

> a second URL to get the values.

It's not hard, but what for? I see some drawbacks and I don't see
how it will help interoperability.

> This seems inconsistent to me ("it's OK to need a second file for some 

I didn't say I like it. I said I can bear it. Tero has suggested removing
values for Transform IDs only. Those values mostly are "external" to
IKEv2 logic, it just "transfers" them between network, policy module,
ipsec module and crypto module. Theoretically they should not affect
IKEv2 itself (*). That's why I can bear removing them.

(*) Unfortunately, they do affect: AEAD algorithms require special
handling in construction proposals. But this is another story.
I've been thinking that introducing a new Transform type for
AEAD algorithms instead of reusing Encryption Algorithm Transform
would probably have made protocol simpler and cleaner, but that was that.

> That is not true. The new RFC can update just a portion of the old one.
> That is how this is normally handled in the IETF.

In any case base RFC will be updated. And the first thing one must do before
implementing any protocol is to find most recent RFC for it, including
all updates and erratas. This is natural way to go, and if one starts
implementing old RFC, then even if you manage to force him to go
to IANA for numbers, I doubt if he will get interoperable product.

> I do not know if our situation has ever happened in the IETF for a major 
> protocol.
> I will ask around and report back on that.

OK, thank you.

Regards,
Smyslov Valery.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Nov 2009 13:39:36 -0800

At 12:19 AM +0300 11/30/09, Valery Smyslov wrote:
>>This answer is inconsistent, and that's the crux of the issue I have with your

We still agree, and your answer is still inconsistent. If you worry about those type of developers, then you must want to get rid of the IANA registry, because that is what is giving them the silly ideas.

>Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not defined in IANA.

Sorry, I misunderstood what you were saying. Yes, that is a good suggestion; I'll make it happen.

>>Yes, but *only* if the names and numbers we use in this document match those exactly
>>*and* the WG is willing to cede change control to the EAP methods we use to the IANA
>>registry that we do not have input to. So far, the WG hasn't said they want to do that,
>I fail to understand your logic here. You seem to want to have ability to change
>groups will not ever change their numbers.

I do not presume that. I presume that this WG is not concerned about it; otherwise, we would have created our own IANA registry for the EAP values we use. We didn't.

>understanding the context for them.

The context for the values is "they are assigned and maintained by IANA". It is not "they came from this RFC". You may not like that, but that's how the IETF works.

>how it will help interoperability.

Again: it helps interoperability if developers look in the IANA registry at the time of coding and see changes have been made to what they thought was true based only on reading an RFC.

>would probably have made protocol simpler and cleaner, but that was that.

Your second paragraph is a shining example of why this should have been done in RFC 4306, and why we should not presume that what we do in IKEv2bis will be held constant.

>to IANA for numbers, I doubt if he will get interoperable product.

The IANA registry lists the current RFCs. Do you not think that is enough clue?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 30 Nov 2009 11:30:27 +0300

> We still agree, and your answer is still inconsistent. If you worry about
> those type of developers, then you must want to get rid of the IANA
registry,
> because that is what is giving them the silly ideas.

No, I didn't mean that. I meant that the simpler description of the protocol
is,
the better implementation is (usually) developed by an average person.
In this context adding one more step in the process of developing
may (and, I think, will) lead to increasing number of non-ineroperable
implementations. I suspect, you may get just the opposite results than
you expects.

> The context for the values is "they are assigned and maintained by IANA".
> It is not "they came from this RFC". You may not like that, but that's how
the IETF works.

IANA doesn't assign any number by its own will - there must
be request for that number and a corresponding RFC.
And if this is a change to existing number, then this new RFC must
either update base RFC or make it obsolete. Is it right?
And even laziest developer will start implementing from
finding the most recent RFC, updates and errata.

> Again: it helps interoperability if developers look in the IANA registry
at the time
> of coding and see changes have been made to what they thought was true
based
> only on reading an RFC.

Those changes don't come from IANA itself, they come from updating RFC.
And it is this RFC, which developer starts implementing from, not IANA.
And only after finding this RFC he/she will usually go to IANA.

And making changes to already assigned values must be as rare as possible,
because it automatically makes existing implementations non-compliant.
On the other hand, adding new values usually doen't affect base protocol.

> The IANA registry lists the current RFCs. Do you not think that is enough
clue?

No. RFC Editor Search Engine gives much more information regarding current
status of RFC, existence of updates and errata. IANA is best for looking for
protocol extensions, but it gives only current snapshot of the situation.
If some values were changed, IANA wouldn't keep old references, and
if you want to keep your product interoperable with previous versions,
IANA won't help you. And if you remove number values from RFC,
keepeng new products interoperable with previous in case of changing
some assigned values will become next to impossible - you just will
have no sources for old numbers.

Regards,
Smyslov Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 30 Nov 2009 14:00:33 +0200

Paul Hoffman writes:
> If a developer does not know how to read the IANA tables, we are all
> in trouble. Nothing in the tables says "you must implement every
> thing in these tables", of course.

Then we are already in trouble. There is lots of developers who do not
know about the IANA tables, they just grab the RFCs (without knowing
about the IETF) and start to implement them.

Not all developers follow IETF work, and quite a lot of developers do
not know how IETF work, and what is the relation between IETF and IANA
and so on.

Also I do not think developers NEED to know the this kind of things,
it should be enough for them to grab the documents and implement them.
I do not think it is mandatory for them to understand what different
IANA registration procedures mean. There is also lots of developers
who do not know the difference between Informational RFC and Standard
track RFC, and if they see numbers in the IANA registry they will
think they should implement all of them.

> I am now deeply concerned with this WG's relationship to the IANA

We are not talking about the developers who are working on this WG.
The whole world is not this WG, there is other people out there.

Also I myself do find extra unnecessary indirections very annoying,
and if possible, I try to avoid those.

> >3. Sometimes there might be difficulties in matching names from RFC
> >with IANA entries. For example, IANA registry has an entry named
> >ENCR_AES-CCM_8, but in RFC5282 this algorithm is called
> >AEAD_AES_128_CCM_SHORT_8. Are you sure these names reference the
> >same algorithm? I prefer to check their IDs in RFC and in IANA
> >registry.
> 
> This is a bug in the IANA registry that needs to be fixed.

It is not really a bug in IANA registry, as RFC4106 use those names,
and it did allocate them. It is bug in the RFC5282, which should have
used the same names for the same algorithms. On the other hand the
rfc5282 do have table mapping the names it uses to the ENCR identifier
numbers, and it DOES NOT have IANA actions for the Encryption
Transform identifiers table, as those numbers have already been
allocated before. 

> It is not related to the values being in the RFC. Tero has spent a
> lot of time trying to fix the registry, but clearly we need more
> effort here. I will certainly make sure that the names in the
> registry match those in RFC 4306, and that the exact names are used
> in IKEv2bis.

On of the problems is the RFC4106 which predates IKEv2, which means it
used completely different naming scheme than what was used in the rest
of the documents, i.e. their algorithms do not have ENCR_* format, but
is just text. I do not think we change that anymore.

> >4. Some entries in Diffie-Hellman Group Transform IDs table do not
> >really assign individual numbers, but instead point to other
> >documens, even to RFC4306 itself, where the numbers are assigned.
> 

I do not think anybody proposed to get rid of the IANA registry. I
think everybody agreed that yes, we should have pointer to the IANA
registry. But as those numbers are never going to change, they should
also be listed here.

> This is probably incorrect. In many WGs, when errors are found in
> old definitions, the error is corrected *and a new value is
> assigned*. That is the only way to assure interoperability.

Which means they existing numbers are not going to change. There may
be new numbers meaning almost same thing (but with fixed semantics),
but the old number can only mean exactly what was meant at the time
the RFC was written.

> The goal of our work is clarity and interoperability, not
> convenience, particularly when the inconvenience is remedied by one
> extra lookup. 

Extra lookup which WILL cause more bugs, which means implementations
are not interoperable. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 30 Nov 2009 14:20:48 +0200

> http://www.iana.org/assignments/eap-numbers, right?

This is good example of confision what happens when you point to
external iana registry.

In RFC4306 we have "Nak (Response only)". If you look to the iana
registry for eap, you cannot find that one. You do find "Legacy Nak".

Are those two same?

As both tables have also the number 2 associated to the code, you know
they are same. Reading RFC3748 you notice that it uses both "Nak" and
"Legacy Nak". 

> as possible, preferrably one.

I completely agree on that.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 30 Nov 2009 14:43:14 +0200

Now talking only about the Tranform Type 4 - Diffie-Hellman Group
Transform IDs IANA registry.

> 18           8192-Bit MODP Group                  [RFC3526]

Hmm... I think the IANA registry should really list these out, instead
of using range to reference to the RFCs.

I think we should fix the IANA registry so the group names will match
the section / appendix names in the appropriate RFCs and where there
would not be any range allocations. The resulting IANA registry would
be like this:
----------------------------------------------------------------------
Registry Name: Transform Type 4 - Diffie-Hellman Group Transform IDs
Reference: [RFC4306]
Registration Procedures: Expert Review

Registry:
Number        Name                                Reference
------------  ----------------------------------  ---------
0             NONE                                [RFC4306]
1             Group 1 - 768 Bit MODP Group        [RFC4306]
2             Group 2 - 1024 Bit MODP Group       [RFC4306]
3-4           Reserved                            [RFC4306]
5             1536-bit MODP Group                 [RFC3526]
6-13          Unassigned                          [RFC4306]
14            2048-bit MODP Group                 [RFC3526]
15            3072-bit MODP Group                 [RFC3526]
16            4096-bit MODP Group                 [RFC3526]
17            6144-bit MODP Group                 [RFC3526]
18            8192-bit MODP Group                 [RFC3526]
19            256-bit random ECP group            [RFC4753]
20            384-bit random ECP group            [RFC4753]
21            521-bit random ECP group            [RFC4753]
22            1024-bit MODP Group with 160-bit    [RFC5114]
              Prime Order Subgroup
23            2048-bit MODP Group with 224-bit    [RFC5114]
              Prime Order Subgroup
24            2048-bit MODP Group with 256-bit    [RFC5114]
              Prime Order Subgroup
25            192-bit Random ECP Group            [RFC5114]
26            224-bit Random ECP Group            [RFC5114]
27-1023       Unassigned                          [RFC4306] 
1024-65535    Private use                         [RFC4306]
----------------------------------------------------------------------

Unless anybody objects, I will be requesting IANA to make the change
next week. 

-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Mon, 30 Nov 2009 09:02:10 -0500

>I completely agree on that.

I also agree with Valery and Tero.

Dave Wierbowski

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Nov 2009 09:34:47 -0800

>Unless anybody objects, I will be requesting IANA to make the change

Not only do I not object, I thank you for doing something I volunteered to do.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 30 Nov 2009 15:16:08 -0800 (PST)

Hi Tero,

  Groups 1 and 2 were defined in RFC 2409 and repeating them in a
subsequent RFC does not change that. I suggest leaving the reference
to RFC 2409 for groups 1 and 2 (and 3 and 4 for that matter) that
currently exists today at http://www.iana.org/assignments/ipsec-registry,
as of 2315 GMT on 30 November 2009, aka "right now".

  regards,

  Dan.