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

From: "Charlie Kaufman" <[email-masked]>
Date: Sun, 18 Jul 2004 16:13:33 -0700

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.

>The IANA considerations seem sparse, and I hope the wg is prepared
>to work with IANA and the designated expert on this, especially in
>setting up the process for creating a new registry when a new transform
>type is registered.

There is a separate IANA considerations document with the initial registry,
but I'm not sure what more can or should be said about the modification
process. In practice, I do not expect that new transform types will be
created.

>In reading this draft, I am concerned about whether the IPv6
>addressing model that is described in Section 2.19 and 3.15 has been fully
>thought through.
>
>The CFG_REQUEST functionality that is described is somewhat in
>the style of PPP's IPCPv4, in that a particular address can be assigned,
>along with IP-layer parameters such as the DNS and WINS server addresses.
>
>However, for PPP IPCPv6, a different route was taken; only the
>Interface-Id is negotiated with mechanisms such as RS/RA used to obtain
>the prefix and upper-layer configuration handled by
>existing mechanisms such as DHCPv6.  This allows configuration mechanisms
>to be leveraged across interface types.
>
>I'm concerned that the implications of the IPv6 configuration mechanisms
>defined in IKEv2 haven't been well thought through; the examples seem
>mostly focussed on IPv4.
>
>For example, the document contains a  number of oddities -- it defines how
>to configure an IPv6 NetBios Name Server, even though NetBIOS is not
>supported for IPv6;  yet another mechanism is defined for configuring an
>IPv6 DNS server;  the draft allows a host to obtain *both* an address and
>a prefix, as well as to obtain the address of a DHCP server, etc.
>
>Note that a number of comments were posted to the IPSEC list about these
>issues, but they seem to have been ignored.

It seems quite likely that the design of IPv6 configuration mechanisms
in the IRAC/IRAS case was an afterthought based on modifying IPv4. I could
not find the comments on the IPSEC list. I tried reading the IPv6 DHCP
spec for guidance, but it wasn't obvious how to resolve this. Is there
someone out there with IPv6 expertise who can help?

**********ALL CHANGES**********

IETF I-D Tracker v1.0 --To: Internet Engineering Steering Group <[email-masked]>
From: IESG Secretary <[email-masked]>
Reply-To: IESG Secretary <[email-masked]>
Subject: Evaluation: draft-ietf-ipsec-ikev2-14.txt to Proposed Standard 
--------

Evaluation for draft-ietf-ipsec-ikev2-14.txt can be found at 
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=7977&rfc_flag=0 

Last Call to expire on: 2004-04-12

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Harald Alvestrand    [   ]     [ X ]     [   ]     [   ]
Steve Bellovin       [   ]     [   ]     [ X ]     [   ]
Bill Fenner          [   ]     [ X ]     [   ]     [   ]
Ted Hardie           [   ]     [ X ]     [   ]     [   ]
Scott Hollenbeck     [   ]     [ X ]     [   ]     [   ]
Russ Housley         [   ]     [   ]     [ X ]     [   ]
David Kessens        [   ]     [   ]     [ X ]     [   ]
Allison Mankin       [   ]     [ X ]     [   ]     [   ]
Thomas Narten        [   ]     [ X ]     [   ]     [   ]
Jon Peterson         [   ]     [ X ]     [   ]     [   ]
Margaret Wasserman   [   ]     [   ]     [ X ]     [   ]
Bert Wijnen          [   ]     [ X ]     [   ]     [   ]
Alex Zinin           [   ]     [ X ]     [   ]     [   ]

2/3 (9) Yes or No-Objection opinions needed to pass.

DISCUSSES AND COMMENTS:
======================
Harald Alvestrand:

Comment:
Reviewed by Scott Brim, Gen-ART.

Only minor issues found, these have been forwarded to the AD.

>Steve Bellovin:
>
>Discuss:
>Define SA.  Define -- not just expand -- "IKE SA".  What is one?

At first mention of SA (in introduction), added reference to RFC2401bis
for definitions.
 
>2.7: The acronym SA is overloaded -- it's being used to refer to a concept
>as well as to a payload containing proposals for the concept.

SA refers to Security Association except as part of the phrase "SA payload".
Found and fixed 3 places where that rule wasn't followed.
 
>2.15: This section denounces passwords, but the only mandatory input
>mechanism for shared secrets is an ASCII string.  It MUST support hex input

Changed hex input to be a MUST.

>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.

>3.1: The text about ignoring things from the UDP header beyond the ports
>and addresses is a bit odd, since that's about all there is in it....

Changed text to "Information from the beginning of the packet through the
UDP header is largely ignored except...". (Meaning that this information is
not cryptographically protected and hop counts, IP options, etc. are ignored)

>3.3.3: What are ESN and INTEG?

Added the abbreviations ENCR, PRF, INTEG, D-H, and ESN to the transform
type value table in section 3.3.2.

>3.3.5: RC4 also requires a key length

Removed reference to RC4, which is not profiled for use with IPsec and
probably never will be.

>3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems.  Support for
>ID_IPV4_ADDR is only required for IPv4-capable systems

ok.

>3.6: What URL types must be supported?  HTTP?  HTTPS?  FTP?  MAILTO?

None are MUST. Clarified that URL w/HTTP is SHOULD.

>5: A discussion of fragmentation attacks needs to be here.  The bare mention
>of [KPS03] earlier is insufficient.

Added a paragraph to section 5 stating the problem, recommending use of
"Hash and URL" encoding, and referring again to [KPS03].

>Appendix B doesn't list DH Group 5, but it's mentioned in Section 5.

Group 5 is defined in [ADDGROUP] and was removed from Appendix B for
that reason.

>Comment:
>Should there be discussion of requirements for maximum UDP packet size (after 
>fragment reassembly)?

See comments below under Margaret Wasserman.

>On the number of very closely-spaced packets that the 
>system must be capable of receiving?  (There have been reports of 
>interoperability problems in the past because of this issue.)

IKEv2 is a request/response protocol, so with the exception of fragmented
packets there should be no congestion issues.

>Ted Hardie:
>
>Comment:
>In Section 2.23:
>  
>      If the NAT_DETECTION_DESTINATION_IP payload received does not
>      match the hash of the destination IP and port found from the IP
>      header of the packet containing the payload, it means that this
>      end is behind NAT (i.e., the original sender sent the packet to
>      address of the NAT box, which then changed the destination address
>      to this host). In this case the this end should start sending
>      keepalive packets as explained in [Hutt04].
>
>Two nits:  "the this end should" should probably be "this end";

Changed to "this end SHOULD"

>the parenthetical
>section seems confusing and should probably be re-worded or perhaps
>dropped (as what to do is clear without it).

Dropped.

>Just below, NAT-T is used without explanation in the text; expansion may be 
>useful.

Changed to NAT traversal.

>In 3.3.4 (Mandatory transform IDs), the draft says:
>
>   
>   It is likely that IANA will add additional transforms in the future,
>   and some users may want to use private suites, especially for IKE
>   where implementations should be capable of supporting different
>   parameters, up to certain size limits. In support of this goal, all
>   implementations of IKEv2 SHOULD include a management facility that
>   allows specification (by a user or system administrator) of Diffie-
>   Hellman parameters (the generator, modulus, and exponent lengths and
>   values) for new DH groups. Implementations SHOULD provide a
>   management interface via which these parameters and the associated
>   transform IDs may be entered (by a user or system administrator), to
>   enable negotiating such groups.
>
>   All implementations of IKEv2 MUST include a management facility that
>   enables a user or system administrator to specify the suites that are
>   acceptable for use with IKE. Upon receipt of a payload with a set of
>   transform IDs, the implementation MUST compare the transmitted
>   transform IDs against those locally configured via the management
>   controls, to verify that the proposed suite is acceptable based on
>   local policy.  The implementation MUST reject SA proposals that are
>   not authorized by these IKE suite controls.
>
>reading these together, it was not clear to me whether it was considered
>acceptable for an implementation to be configured such that there
>were none of the mandatory transforms in its permitted set.  I eventually
>came to the conclusion that this was permitted (i.e., only private suites
>in use), but I feel the document might benefit from making the point explcit
>here, one way or the other.

Added clarifying sentence to end of 3.3.4 that mandatory transforms are
mandatory to implement but need not be configured as acceptable to
local policy.

>The IANA considerations seem sparse, and I hope the wg is prepared
>to work with IANA and the designated expert on this, especially in
>setting up the process for creating a new registry when a new transform
>type is registered.

There is a separate IANA considerations document with the initial registry,
but I'm not sure what more can or should be said about the modification
process. In practice, I do not expect that new transform types will be
created.

>Russ Housley:
>
>Discuss:
>
>  In section 1.5, the last sentence says: "... it MAY send an Informational
>  message without cryptographic protection to the source IP address and port
>  to alert it to a possible problem."  However, section 1.4 says that
>  informational messages "MAY ONLY occur after the initial exchanges and are
>  cryptographically protected with the negotiated keys."  These are in
>  conflict, and one of them needs to be changed to resolve the conflict.
>  Also, "MAY ONLY" ought to be changed to "MUST ONLY."

Changed the MAY ONLY to MUST ONLY. Clarified that an informational message
can occur outside of an informational exchange; section 1.5 talks about 
such messages. Informational exchanges (section 1.4) MUST ONLY occur within
an IKE_SA.

>  In section 2.23, the text says: "IKEv2 can negotiate UDP encapsulation of
>  IKE, ESP, and AH packets."  Then, in the middle of page 38, the conventions
>  for tunneling IKE and ESP over UDP are described.  The conventions for AH
>  ought to be described too.  Further, the IANA registry for port 4500 ought
>  to be updated to point to this document.  It currently says:
>  
>    ipsec-msft      4500/tcp   Microsoft IPsec NAT-T
>    ipsec-msft      4500/udp   Microsoft IPsec NAT-T
>    #               Christian Huitema <[email-masked]> March 2002

Section 2.23 was incorrect and reflected some wishful thinking on my
part. Port 4500 was reserved for UDP encapsulation of IKE and ESP
packets. No similar encapsulation for AH has been defined. I corrected
section 2.23 to remove any mention of AH.

>  In the 3rd paragraph of section 2.21, the document says: "If the message is
>  marked as a response, the node MAY audit the suspicious event but MUST NOT
>  respond."  How would an implementation respond to a response message?

There is no defined way to respond to a response. That's why responses are
forbidden. Perhaps this statement is unnecessary.

>  In section 3.3.2, the table for transform type values needs an entry for
>  zero, making it RESERVED.

Done.

>  Also in Section 3.3.2, the table for encryption algorithms has some missing
>  references.  ENCR_AES_CBC ought to refer to RFC 3602, and ENCR_AES_CTR ought
>  to refer to RFC 3686.

Done.

>  Also in Section 3.3.2, the table of PRFs should replace "PRF_AES_CBC" with
>  "PRF_AES128_CBC" in order to match the companion algorithms document.
>  Further, it ought to refer to RFC 3664.

Done.

>  Also in Section 3.3.2, the last entry in the integrity algorithms table is
>  ought to be AUTH_AES_XCBC_96, and it ought to refer to RFC 3566.

Done.

>  Also in Section 3.3.2, the Diffie-Hellman groups table should not constrain
>  the kinds of groups that might be registered in the future.  It ought to
>  say: "values 6-13 and 19-1023 are reserved to IANA."

Done.

>  In section 3.3, I do not understand the context where ESP or AH would make
>  use of D-H.  Why is D-H an optional type for ESP or AH?

D-H is an optional type in an SA payload negotiating ESP or AH. If present,
the messages must also contain KE payloads and use the keying material
from this fresh D-H exchange in keying the ESP or AH SAs as specified
in section 2.17.

>  In section 3.5, the table needs to say something about values 4, 6, 7,
>  and 8.  I assume that they are also reserved to IANA.

Done.

>  In section 3.10.1, the first table needs an entry for zero, making it
>  RESERVED.  Further, at the end of the first table, the document ought to
>  reserve values 40-1891 (not 39-8191).

Done.

>  In section 6, please change the title of the Diffie-Hellman registry
>  to "IKEv2 Diffie-Hellman Transform IDs."  Again, the point is to avoid
>  unduly constraining the kinds of groups that might be registered in
>  the future.

Done.

>  Also in section 6, the last paragraph would be more clear if is said:
>  "Changes and additions to any of these registries are by expert review."

Done.

>  Appendix A refers to two Internet Drafts that will never be published.
>  These references need to be replaced with a brief summary of the issue.

Replaced the reference to draft-ietf-ipsec-hash-revised-02.txt with
a five word summary.
The reference to the other document on NAT traversal requirements was redundant
with the statement that NAT traversal was folded into IKEv2, so the
reference was removed.

>Comment:
>
>  Please spell out the acronym "PFS" the first time it is used.

It was only used twice. In both cases, I changed it to refer to the
optional Diffie-Hellman exchange instead of using the acronym.

>  In the 2nd paragraph of section 3.12, the document says: "... i.e., it MUST
>  be non-critical."  It would be more clear, I think, to say: "the critical
>  bit MUST be set to 0."  This is discussed elsewhere in the document, but
>  stating the value of the bit will make it clearer.

Done.

>  In section 3.1, the second-to-last entry in the main table should read
>  "RESERVED TO IANA" to match the wording in the rest of the tables.

Done.

>  [IKEv2IANA] and [Ker01] are not referenced in the document.  Please
>  delete these references.

Done.

>David Kessens:
>
>Discuss:
>Comments from the ops directorate:
>
>In reading this draft, I am concerned about whether the IPv6
>addressing model that is described in Section 2.19 and 3.15 has been fully
>thought through.
>
>The CFG_REQUEST functionality that is described is somewhat in
>the style of PPP's IPCPv4, in that a particular address can be assigned,
>along with IP-layer parameters such as the DNS and WINS server addresses.
>
>However, for PPP IPCPv6, a different route was taken; only the
>Interface-Id is negotiated with mechanisms such as RS/RA used to obtain
>the prefix and upper-layer configuration handled by
>existing mechanisms such as DHCPv6.  This allows configuration mechanisms
>to be leveraged across interface types.
>
>I'm concerned that the implications of the IPv6 configuration mechanisms
>defined in IKEv2 haven't been well thought through; the examples seem
>mostly focussed on IPv4.
>
>For example, the document contains a  number of oddities -- it defines how
>to configure an IPv6 NetBios Name Server, even though NetBIOS is not
>supported for IPv6;  yet another mechanism is defined for configuring an
>IPv6 DNS server;  the draft allows a host to obtain *both* an address and
>a prefix, as well as to obtain the address of a DHCP server, etc.
>
>Note that a number of comments were posted to the IPSEC list about these
>issues, but they seem to have been ignored.

It seems quite likely that the design of IPv6 configuration mechanisms
in the IRAC/IRAS case was an afterthought based on modifying IPv4. I could
not find the comments on the IPSEC list. I tried reading the IPv6 DHCP
spec for guidance, but it wasn't obvious how to resolve this. Is there
someone out there with IPv6 expertise who can help?

>Margaret Wasserman:
>
>Discuss:
>In general, I think that this is a good piece of work.  However,
>there are two issues with this document that should be addressed:
>
>(1) This document uses UDP and includes a retransmission mechanism for
>requests, but it does not indicated that the retransmission timer must
>back off exponentially.

Added to section 2.4:

To be a good network citizen, retransmission times MUST increase exponentially
to avoid flooding the network and making an existing congestion situation
worse.

>(3) This specification does not mandate a minimum supported UDP packet
>size for hosts that 
>implement IKEv2.  Would the default minimum (556 bytes of UDP payload
>in IPv4) be sufficient?  Or should this specification mandate that
>implementations of IKEv2 must support larger UDP packets?

In the simplest use of IKEv2, UDP payload sizes never exceed 340 bytes.
(So an implementation that did not support 340 byte payloads could not
possibly work). There is no theoretical upper bound on the size of a
valid IKEv2 message (except for a 32 bit field for message length).
There will be cases where IKEv2 messages in practice will exceed 556 bytes
(they can contain X.509 certificates, which are commonly bigger than
1024 bytes), but there is no natural number to require of the underlying
UDP implementation.

Added the following to section 2:

While IKEv2 messages are intended to be short, they contain structures with
no hard upper bound on size (in particular, X.509 certificates), and IKEv2
itself does not have a mechanism for fragmenting large messages. IP defines
a mechanism for fragmentation of oversize UDP messages, but implementations
vary in the maximum
message size supported. Further, use of IP fragmentation opens an
implementation to denial of service attacks [KPS03].

IKEv2 implementations SHOULD be aware of the maximum UDP message size
supported and MAY shorten messages by leaving out some certificates or
cryptographic suite proposals if that will keep messages below the maximum.

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

---

From: "Yoav Nir" <[email-masked]>
Date: Mon, 19 Jul 2004 09:32:07 +0300

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

do (or explain why I believed no action was necessary). In one case (3rd
item

            --Charlie

<snip>

---

From: "William Dixon" <[email-masked]>
Date: Mon, 19 Jul 2004 21:40:12 -0400

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Charlie Kaufman
> Sent: Sunday, July 18, 2004 7:14 PM
> To: [email-masked]
> 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
> 
> 
> 
> >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.
> 
> >The IANA considerations seem sparse, and I hope the wg is 
> prepared to 
> >work with IANA and the designated expert on this, especially 
> in setting 
> >up the process for creating a new registry when a new 
> transform type is 
> >registered.
> 
> There is a separate IANA considerations document with the 
> initial registry, but I'm not sure what more can or should be 
> said about the modification process. In practice, I do not 
> expect that new transform types will be created.
> 
> addressing 
> >model that is described in Section 2.19 and 3.15 has been 
> fully thought 
> >through.
> >
> >The CFG_REQUEST functionality that is described is somewhat in the 
> >style of PPP's IPCPv4, in that a particular address can be assigned, 
> >the prefix and upper-layer configuration handled by existing 
> mechanisms 
> >such as DHCPv6.  This allows configuration mechanisms to be 
> leveraged 
> >across interface types.
> >
> >I'm concerned that the implications of the IPv6 configuration 
> >mechanisms defined in IKEv2 haven't been well thought through; the 
> >examples seem mostly focussed on IPv4.
> >
> >For example, the document contains a  number of oddities -- 
> it defines 
> >how to configure an IPv6 NetBios Name Server, even though NetBIOS is 
> >not supported for IPv6;  yet another mechanism is defined for 
> >configuring an
> >IPv6 DNS server;  the draft allows a host to obtain *both* 
> an address 
> >and a prefix, as well as to obtain the address of a DHCP server, etc.
> >
> >Note that a number of comments were posted to the IPSEC list about 
> >these issues, but they seem to have been ignored.
> 
> It seems quite likely that the design of IPv6 configuration 
> mechanisms in the IRAC/IRAS case was an afterthought based on 
> modifying IPv4. I could not find the comments on the IPSEC 
> list. I tried reading the IPv6 DHCP spec for guidance, but it 
> wasn't obvious how to resolve this. Is there someone out 
> there with IPv6 expertise who can help?
> 
> Steve Bellovin       [   ]     [   ]     [ X ]     [   ] Bill 
> Fenner          [   ]     [ X ]     [   ]     [   ] Ted 
> Hardie           [   ]     [ X ]     [   ]     [   ] Scott 
> Hollenbeck     [   ]     [ X ]     [   ]     [   ] Russ 
> Housley         [   ]     [   ]     [ X ]     [   ] David 
> Kessens        [   ]     [   ]     [ X ]     [   ] Allison 
> Mankin       [   ]     [ X ]     [   ]     [   ] Thomas 
> Narten        [   ]     [ X ]     [   ]     [   ] Jon 
> Peterson         [   ]     [ X ]     [   ]     [   ] Margaret 
> Wasserman   [   ]     [   ]     [ X ]     [   ] Bert Wijnen   
       [   ]     [ X ]     [   ]     [   ] Alex Zinin           > [   ]    
[ X ]     [   ]     [   ]
> At first mention of SA (in introduction), added reference to 
> RFC2401bis for definitions.
>  
> >2.7: The acronym SA is overloaded -- it's being used to refer to a 
> >concept as well as to a payload containing proposals for the concept.
> 
> >mechanism for shared secrets is an ASCII string.  It MUST 
> support hex 
> >input
> 
> >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.
> 
> >3.1: The text about ignoring things from the UDP header beyond the 
> >ports and addresses is a bit odd, since that's about all 
> there is in it....
> 
> Changed text to "Information from the beginning of the packet 
> through the UDP header is largely ignored except...". 
> (Meaning that this information is not cryptographically 
> protected and hop counts, IP options, etc. are ignored)
> 
> Added the abbreviations ENCR, PRF, INTEG, D-H, and ESN to the 
> transform type value table in section 3.3.2.
> 
> Removed reference to RC4, which is not profiled for use with 
> IPsec and probably never will be.
> 
> >5: A discussion of fragmentation attacks needs to be here.  The bare 
> >mention of [KPS03] earlier is insufficient.
> 
> Added a paragraph to section 5 stating the problem, 
> recommending use of "Hash and URL" encoding, and referring 
> again to [KPS03].
> 
> Group 5 is defined in [ADDGROUP] and was removed from 
> Appendix B for that reason.
> 
> >Comment:
> >Should there be discussion of requirements for maximum UDP 
> packet size 
> >(after fragment reassembly)?
> 
> >On the number of very closely-spaced packets that the system must be 
> >capable of receiving?  (There have been reports of interoperability 
> >problems in the past because of this issue.)
> 
> IKEv2 is a request/response protocol, so with the exception 
> of fragmented packets there should be no congestion issues.
> 
> >Ted Hardie:
> >
> >Comment:
> >In Section 2.23:
> >  
> >Just below, NAT-T is used without explanation in the text; expansion 
> >may be useful.
> 
> >reading these together, it was not clear to me whether it was 
> >considered acceptable for an implementation to be configured 
> such that 
> >there were none of the mandatory transforms in its permitted set.  I 
> >eventually came to the conclusion that this was permitted 
> (i.e., only 
> >private suites in use), but I feel the document might benefit from 
> >making the point explcit here, one way or the other.
> 
> Added clarifying sentence to end of 3.3.4 that mandatory 
> transforms are mandatory to implement but need not be 
> configured as acceptable to local policy.
> 
> >The IANA considerations seem sparse, and I hope the wg is 
> prepared to 
> >work with IANA and the designated expert on this, especially 
> in setting 
> >up the process for creating a new registry when a new 
> transform type is 
> >registered.
> 
> There is a separate IANA considerations document with the 
> initial registry, but I'm not sure what more can or should be 
> said about the modification process. In practice, I do not 
> expect that new transform types will be created.
> 
> >Russ Housley:
> >
> >Discuss:
> >
> >  message without cryptographic protection to the source IP 
> address and 
> >port
> Changed the MAY ONLY to MUST ONLY. Clarified that an 
> informational message can occur outside of an informational 
> exchange; section 1.5 talks about such messages. 
> Informational exchanges (section 1.4) MUST ONLY occur within 
> an IKE_SA.
> 
> >  ought to be described too.  Further, the IANA registry for 
> port 4500 
> >ought
> Section 2.23 was incorrect and reflected some wishful 
> thinking on my part. Port 4500 was reserved for UDP 
> encapsulation of IKE and ESP packets. No similar 
> encapsulation for AH has been defined. I corrected section 
> 2.23 to remove any mention of AH.
> 
> There is no defined way to respond to a response. That's why 
> responses are forbidden. Perhaps this statement is unnecessary.
> 
> >  In section 3.3.2, the table for transform type values 
> needs an entry 
> >for
> >  Also in Section 3.3.2, the table for encryption algorithms 
> has some 
> >missing
> >  Also in Section 3.3.2, the table of PRFs should replace 
> "PRF_AES_CBC" 
> >with
> >  the kinds of groups that might be registered in the 
> future.  It ought 
> >to
> >  In section 3.3, I do not understand the context where ESP 
> or AH would 
> >make
> D-H is an optional type in an SA payload negotiating ESP or 
> AH. If present, the messages must also contain KE payloads 
> and use the keying material from this fresh D-H exchange in 
> keying the ESP or AH SAs as specified in section 2.17.
> 
> >  In section 3.5, the table needs to say something about 
> values 4, 6, 
> >7,
> >  RESERVED.  Further, at the end of the first table, the 
> document ought 
> >to
> Replaced the reference to 
> draft-ietf-ipsec-hash-revised-02.txt with a five word summary.
> The reference to the other document on NAT traversal 
> requirements was redundant with the statement that NAT 
> traversal was folded into IKEv2, so the reference was removed.
> 
> 
> >Comment:
> >
> It was only used twice. In both cases, I changed it to refer 
> to the optional Diffie-Hellman exchange instead of using the acronym.
> 
> >  In the 2nd paragraph of section 3.12, the document says: 
> "... i.e., 
> >it MUST
> >  bit MUST be set to 0."  This is discussed elsewhere in the 
> document, 
> >but
> addressing 
> >model that is described in Section 2.19 and 3.15 has been 
> fully thought 
> >through.
> >
> >The CFG_REQUEST functionality that is described is somewhat in the 
> >style of PPP's IPCPv4, in that a particular address can be assigned, 
> >the prefix and upper-layer configuration handled by existing 
> mechanisms 
> >such as DHCPv6.  This allows configuration mechanisms to be 
> leveraged 
> >across interface types.
> >
> >I'm concerned that the implications of the IPv6 configuration 
> >mechanisms defined in IKEv2 haven't been well thought through; the 
> >examples seem mostly focussed on IPv4.
> >
> >For example, the document contains a  number of oddities -- 
> it defines 
> >how to configure an IPv6 NetBios Name Server, even though NetBIOS is 
> >not supported for IPv6;  yet another mechanism is defined for 
> >configuring an
> >IPv6 DNS server;  the draft allows a host to obtain *both* 
> an address 
> >and a prefix, as well as to obtain the address of a DHCP server, etc.
> >
> >Note that a number of comments were posted to the IPSEC list about 
> >these issues, but they seem to have been ignored.
> 
> It seems quite likely that the design of IPv6 configuration 
> mechanisms in the IRAC/IRAS case was an afterthought based on 
> modifying IPv4. I could not find the comments on the IPSEC 
> list. I tried reading the IPv6 DHCP spec for guidance, but it 
> wasn't obvious how to resolve this. Is there someone out 
> there with IPv6 expertise who can help?
> 
> >Margaret Wasserman:
> >
> >Discuss:
> >In general, I think that this is a good piece of work.  
> However, there 
> >are two issues with this document that should be addressed:
> >
> To be a good network citizen, retransmission times MUST 
> increase exponentially to avoid flooding the network and 
> making an existing congestion situation worse.
> 
> >size for hosts that implement IKEv2.  Would the default minimum (556 
> >bytes of UDP payload in IPv4) be sufficient?  Or should this 
> >specification mandate that implementations of IKEv2 must 
> support larger 
> >UDP packets?
> 
> (So an implementation that did not support 340 byte payloads 
> could not possibly work). There is no theoretical upper bound 
> on the size of a valid IKEv2 message (except for a 32 bit 
> field for message length).
> There will be cases where IKEv2 messages in practice will 
> exceed 556 bytes (they can contain X.509 certificates, which 
> are commonly bigger than
> 1024 bytes), but there is no natural number to require of the 
> underlying UDP implementation.
> 
> While IKEv2 messages are intended to be short, they contain 
> structures with no hard upper bound on size (in particular, 
> X.509 certificates), and IKEv2 itself does not have a 
> mechanism for fragmenting large messages. IP defines a 
> mechanism for fragmentation of oversize UDP messages, but 
> implementations vary in the maximum message size supported. 
> Further, use of IP fragmentation opens an implementation to 
> denial of service attacks [KPS03].
> 
> IKEv2 implementations SHOULD be aware of the maximum UDP 
> message size supported and MAY shorten messages by leaving 
> out some certificates or cryptographic suite proposals if 
> that will keep messages below the maximum.
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Jul 2004 10:21:49 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "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.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 20 Jul 2004 08:19:56 -0700

>Internet Assigned Numbers Authority RESERVED-192 (NET-192-0-0-0-1)

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