Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments

From: "Charlie Kaufman" <[email-masked]>
Date: Sun, 18 Jul 2004 23:35:21 -0700

Ah, yes. Actually, it could be fixed as you describe in 2.19. I searched
the document for all references to subnet 10, and in section 2.9 there
is a use that is harder to fix.

The address recommended from RFC 3330 is an example IP address, for example
as the address of example.com. In the context of using IPsec to tunnel
between two parts of an internal network, use of 10.* addresses seems
more appropriate.

	--Charlie

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Sunday, July 18, 2004 11:32 PM
To: Charlie Kaufman; [email-masked]
Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments

Hi Charlie.

Re: 2.19.  I don't understand your objection.  In the example you only use
one address (10.168.219.202) and one subnet (10.168.219.0/24).  Why not
replace it with 192.0.2.202 and 192.0.2.0/24 ?  You could also change the
responder TSr to be identical to the initiator TSr, because I think this is
the way most remote-access works - the client can send whatever traffic to
the gateway, not just to the remote-client subnet.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charlie Kaufman
Sent: Monday, July 19, 2004 2:14 AM
To: [email-masked]
Subject: [Ipsec] Proposed changes to IKEv2 based on IESG comments

The following are the IESG comments on IKEv2 annotated with what I did
to address them in the IKEv2 spec. In most cases, the needed correction
or clarification was obvious. But in some cases, I had to guess what to
do (or explain why I believed no action was necessary). In one case (3rd
item
under controversial - IRAC/IRAS with IPv6 - I don't know what to do and
need guidance). I'm posting this to solicit objections, feedback, and
ideas.

            --Charlie

********MOST LIKELY TO BE CONTROVERSIAL********
>2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918
>addresses.

RFC3330 reserves addresses of the form 192.0.2.0/24 for examples in
documentation. Unfortunately, negotiation of traffic selectors requires
specification of two subnets. They are currently taken from 10.*, which is
reserved for local use. While in theory, on might divide 192.0.2.0 into
multiple subnets, this is likely in practice to be confusing.

<snip>

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

---

From: "Charlie Kaufman" <[email-masked]>
Date: Mon, 19 Jul 2004 22:11:21 -0700

I believe issues 94, 96, 97, 98, 100, and 103 were fixed and closed with
draft-14. I (shame on me) forgot my password and was unable to close
them.

I believe issue 95 was rejected in the draft-14 timeframe.

I believe issues 101, 102, 104, 105, 106, and 107 are awaiting updates
to the IKEv2 IANA document.

I believe issues 108, 109, 110, 111, 112, 113, & 114 are the subject of
the discussion in this string (IESG comments). Issue 114 (Dynamic
address assignment with IPv6) is the most serious, in that it may
require a technical change and there is no proposal on the table for
what that change would be.

I believe these are the only issues remaining for IKEv2.

	--Charlie

-----Original Message-----
From: William Dixon [mailto:[email-masked]] 
Sent: Monday, July 19, 2004 6:40 PM
To: Charlie Kaufman; [email-masked]
Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments

Charlie, Angelos, are you still using the Issues Tracker ?

>From my quick review,
Issues 100, 103 and 108 are already fixed and closed with IKEv14
Issues 101, 102, 106, 107 are still outstanding because they require the
Jan
04 IKEv2 IANA document to be updated.
Issues 112-114 are still open for IKEv14 tracking IESG comments.

Here are the sorted & grouped list of issues not yet closed:

99 Editorial Must Fix Clarification on end-to-end tunnel mode  Text
Proposed
angelos 2004-04-14.02:24:04 Kaufman 
Accepted 
94 Editorial Must Fix Fix cert bundle numbering  Accepted angelos
2004-03-25.00:41:09 Kaufman 
95 Editorial Must Fix Responder SHOULD send AUTH/SAr2/TSi/TSr  Accepted
angelos 2004-03-25.00:42:11 Kaufman 
96 Editorial Must Fix Clarification on OPAQUE port numbers  Accepted
angelos
2004-03-25.00:43:10 Kaufman 
Pending 
101 Editorial Must Fix Inconsistencies between IKEv2 and IANA registry
drafts  Pending angelos 2004-04-14.02:26:25 Kaufman 
102 Editorial Must Fix How are registries updated ?  Pending angelos
2004-04-14.02:26:59 Kaufman 
103 Editorial Must Fix XCBC_96 PRF definition  Pending angelos
2004-04-14.02:27:37 Kaufman 
104 Editorial Must Fix ESN values  Pending angelos 2004-04-14.02:28:13
Kaufman 
105 Editorial Must Fix ID Payload types  Pending angelos
2004-04-14.02:28:48
Kaufman 
106 Editorial Must Fix Notification types missing from IANA document
Pending angelos 2004-04-14.02:29:19 Kaufman 
107 Editorial Must Fix Traffic selector types reserved space  Pending
angelos 2004-04-14.02:29:59 Kaufman 
108 Editorial Must Fix Clarification on behavior/detection of responder
being behind NAT (Section 2.23)  Pending angelos 2004-06-24.07:04:11
Kaufman

109 Editorial Must Fix Clarification on supporting mandatory algorithms
Pending angelos 2004-06-24.07:07:34 Kaufman 
110 Editorial Must Fix Fix/expand/define acronyms and terms  Pending
angelos
2004-06-24.07:09:59 Kaufman 
111 Editorial Must Fix Maximum UDP packet size issues  Pending angelos
2004-06-24.07:11:34 Kaufman 
112 Editorial Must Fix Editorial nits in version -14 of the draft
Pending
angelos 2004-06-24.07:16:14 Kaufman 
113 Editorial Must Fix Clarifications on the use of UDP / minimum
requirements  Pending angelos 2004-06-24.07:20:24 Kaufman 
114 Editorial Must Fix IPv6 addressing model  Pending angelos
2004-06-25.06:15:42 Kaufman 
91 Technical Must Fix Handling ICMP error messages  Pending kseo
2003-10-27.01:43:27 kseo 
92 Technical Must Fix Fragmentation handling in tunnel mode  Pending
angelos
2004-02-24.17:41:26 kseo 
97 Editorial Must Fix Security considerations: key length from group 1
Pending angelos 2004-04-14.02:22:13 Kaufman 
98 Editorial Must Fix OPAQUE and ANY do not have the same meaning
Pending
angelos 2004-04-14.02:22:56 Kaufman 
100 Editorial Should Fix CERTREQ processing  Pending angelos
2004-04-14.02:25:04 Kaufman

---

From: "Charlie Kaufman" <[email-masked]>
Date: Tue, 20 Jul 2004 10:53:04 -0700

Great. That sounds like it will make everyone happy. I'll make
that change.

	--Charlie

-----Original Message-----
From: Paul Hoffman / VPNC [mailto:[email-masked]] 
Sent: Tuesday, July 20, 2004 8:20 AM
To: Michael Richardson; Charlie Kaufman
Cc: [email-masked]
Subject: Re: [Ipsec] Proposed changes to IKEv2 based on IESG comments

At 10:21 AM -0400 7/20/04, Michael Richardson wrote:
>  >>>>> "Charlie" == Charlie Kaufman <[email-masked]> writes:
>     Charlie> ********MOST LIKELY TO BE CONTROVERSIAL********
>     >> 2.19: Use IP addresses from the sample range (RFC 3330) instead
>     >> of RFC 1918 addresses.
>
>     Charlie> RFC3330 reserves addresses of the form 192.0.2.0/24 for
>     Charlie> examples in documentation. Unfortunately, negotiation of
>     Charlie> traffic selectors requires specification of two
>     Charlie> subnets. They are currently taken from 10.*, which is
>     Charlie> reserved for local use. While in theory, on might divide
>     Charlie> 192.0.2.0 into multiple subnets, this is likely in
practice
>     Charlie> to be confusing.
>
>   I suggest that you use 192.0.2.0 and 192.0.3.0.
>
>Internet Assigned Numbers Authority RESERVED-192 (NET-192-0-0-0-1)
>                                   192.0.0.0 - 192.0.127.255
>
>   I'm told that new numbers will be assigned for examples.
>   I would stay away from 10.* because in my experience, people think
>that it has something to with NAT, and get confused.

I fully agree with Michael here. In our interop testing, I have 
talked to more than one IPsec engineer who has thought that private 
addresses (such as 10. addresses) *have* to be behind a NAT box. 
Using the new, not-private-looking addresses would be less confusing.

--Paul Hoffman, Director
--VPN Consortium