Subject: [IPsec] IKEv2-bis comments: 2.17 and onwards

From: Yaron Sheffer <[email-masked]>
Date: Sun, 24 Jan 2010 23:06:05 +0200

1.7: This also lead to -> This also led to

2.21.: EAP Failure cases are missing altogether. Also, the first paragraph says that if an auth failure occurs at the responder, AUTHENTICATION_FAILED is included in the protected response (to IKE_AUTH), while the last paragraph says it's a separate Informational exchange.

1.3.2 and 2.18 (IKE SA rekey) have lots of overlap. If we don't consolidate them, we should at least have them reference one another.

2.19: grammar: "it simply causes the Child SA creation *to* fail".

2.21.2: grammar: "in case an error happened *in* when processing"

2.23: what do we mean by this - "In addition, firewalls may be configured to pass IPsec traffic over UDP but not ESP/AH or vice versa"? This would be less confusing: "In addition, firewalls may be configured to pass UDP-encapsulated IPsec traffic but not plain, unencapsulated ESP/AH or vice versa".

2.23: "The recipient of either the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied value to a SHA-1 hash of the SPIs, source IP address, and port, and if they don't match it SHOULD enable NAT traversal. In the case there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject the connection attempt if NAT traversal is not supported." In the first sentence, the comparison is not just with the source address/port. Also, while NAT-T is a MAY, once you decide that you implement NAT-T, this comparison becomes at least a SHOULD. "If they don't match it SHOULD enable NAT-T" contradicts an earlier MUST: "if a NAT is detected, both devices MUST send UDP encapsulated packets". And the second sentence doesn't make sense as pointed out before - if you recognize these payloads, then obviously you support NAT-T. Overall, the normative part of this section needs to be reworked.

2.23: replace the second-last bullet with a pointer to the subsequent subsection, on Transport Mode and NAT.

2.23: the last bullet (automatically updating the peer's IP address) is too important to be only mentioned as a side note. We should at least mention it in Sec. 2.6, following the sentence: "Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet."

2.24: what's this section (ECN) doing here? It is 100% IPsec, nothing to do with IKE. If there's a reason, let's explain it in the text.

3.1: "The Recipient SPI in the header identifies an instance of an IKE security association. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers." In fact it's more than that, you can have multiple sessions with one peer! So I would rephrase: "The Recipient SPI in the header identifies an instance of an IKE security association. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers, including multiple sessions per peer."

3.2: grammar: "by appending it" -> "by appending them" (or "each one").

3.2, "Next Payload": we say that the Encrypted payload gets a different Next Payload value. But then, we should also say (here or where describing the Encrypted payload) that the last *contained* payload gets a zero Next Payload value.

3.3.2: Tiger - we closed issue #33, but according to the text of the issue, should have left the algorithm "unspecified". Which I think would be much more accurate.

3.3.5: "Attributes described as fixed length MUST NOT be encoded using the variable-length encoding." This cannot be correct, a new 4-octet attribute will have to be encoded as variable-length. It won't fit into the other format.

3.3.6: "The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not that response MUST be rejected." We are not specifying how to reject such erroneous responses, so why not say: "The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not MUST terminate the exchange".

3.3.6: we somehow never say what you do when you receive a Transform ID (i.e. protocol) that you don't understand. This can be added to 3.3.6. E.g., change "Similarly, if the responder receives a transform that contains a Transform Attribute it does not understand..." to "Similarly, if the responder receives a transform that it does not understand, or one that contains a Transform Attribute it does not understand...".

3.5: "IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR." We probably don't mean it, but rather: "IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR, rather than ID_IPV4_ADDR, in addition to the other three types."

3.6: "DNS Signed Key" is marked Unspecified. Is it not RFC 4025? It's not used anywhere, but still...

3.6: [Hash and URL] "makes IKE less subject to denial of service attacks that become easier to mount when IKE messages are large enough to require IP fragmentation." This statement is hard to take seriously. When the certificate is NOT cached, this encoding eliminates a difficult-to-perform DOS attack, replacing it with a much easier one: stop the endpoint from obtaining the cert.

3.6: clarification, replace "Use the following ASN.1 definition for an X.509 bundle" by "The "Hash and URL of a bundle" type uses the following ASN.1 definition of an X.509 bundle:"

3.7: "If multiple CAs are trusted and the certificate encoding does not allow a list, then multiple Certificate Request payloads would need to be transmitted." This doesn't make sense: we are not sending the cert itself here. we're just sending an encoding on a CA. Moreover, the text further down indicates that the CA field is *always* a list - at least for the defined cert types (4, 12, 13). Overall, this looks like a placeholder, and I suggest to delete the sentence.

3.9: "The size of a Nonce" -> "The size of the Nonce Data".

3.10.1: "in any case where the offered proposal" -> "... proposals".

3.10.1: INVALID_SELECTORS is underspecified. It should be rate limited (I suppose), also, how long is the packet fragment included in the notification? In addition, Sec. 2.21.2 implies that it is sent during Child SA negotiation, which is not what 3.10.1 is saying.

3.14: "denoted SK{...} or E in this document" -> "denoted SK{...} in this document."

3.15: "type length values" -> "Type Length Value (TLV) structures".

3.15.1: "With IPv6, a requestor MAY supply the low-order address octets it wants to use." This means to me that you *don't* provide all 16 octets. But according to the table, the field is a fixed-length 16 octets!

3.15.2: "is in CFG_REQUESTs is unclear" - delete the first "is".

3.16: the text here, "...this field MAY be set to any value" implies that the Identifier field can be constant, e.g. always zero. But this would contradict RFC 3748, that says:

In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within the conversation.  One way to achieve this is to start the Identifier at an initial value and increment it for each new Request.  Initializing the first Identifier with a random number rather than starting from zero is recommended, since it makes sequence attacks somewhat more difficult.

4: what do we mean by "Ability to support various types of legacy authentication"? If we mean, "Ability to support EAP-based authentication", let's say so.

5: what do we mean by "leaves all SAs vulnerable to ... overrun of either endpoint"?

5: unfortunately we have to revise the text about group strengths - or remove it altogether. It is non-normative, so it's probably best to eliminate it.

6: the are not -> they are not.

B.1 (Group 1): We may want to add: "Use of this group is NOT RECOMMENDED."

C: I suggest to repeat at the top of this appendix this text from 2.5: "Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations SHOULD send the payloads defined in this specification in the order shown in the figures in Sections 1 and 2; implementations MUST NOT reject as invalid a message with those payloads in any other order."

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Jan 2010 16:45:43 -0800

Thanks again for the careful review. All changes made other than those listed below.

--Paul HOffman

>2.21.: EAP Failure cases are missing altogether. Also, the first paragraph says that if an auth failure occurs at the responder, AUTHENTICATION_FAILED is included in the protected response (to IKE_A…

Please open a tracker issue for this.

>2.23: "The recipient of either the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied value to a SHA-1 hash of the SPIs, source IP address, and port, and if they don't match it SHOULD enable NAT traversal. In the case there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject the connection attempt if NAT traversal is not supported." In the first sentence, the comparison is not just with the source address/port. Also, while NAT-T is a MAY, once you decide that you implement NAT-T, this comparison becomes at least a SHOULD. "If they don't match it SHOULD enable NAT-T" contradicts an earlier MUST: "if a NAT is detected, both devices MUST send UDP encapsulated packets". And the second sentence doesn't make sense as pointed out before - if you recognize these payloads, then obviously you support NAT-T. Overall, the normative part of this section needs to b!
 e reworked.

Please open a tracker issue for this.

>2.23: replace the second-last bullet with a pointer to the subsequent subsection, on Transport Mode and NAT.

Added a forward reference instead.

>2.23: the last bullet (automatically updating the peer's IP address) is too important to be only mentioned as a side note. We should at least mention it in Sec. 2.6, following the sentence: "Incomin…

Please propose specific wording for that insertion to 2.6.

>2.24: what's this section (ECN) doing here? It is 100% IPsec, nothing to do with IKE. If there's a reason, let's explain it in the text.

Disagree. This section lists new mandatory actions that were not in IKEv1.

>3.2, "Next Payload": we say that the Encrypted payload gets a different Next Payload value. But then, we should also say (here or where describing the Encrypted payload) that the last *contained* pa…

This is significant. Please propose changes in a new tracker issue.

>3.3.5: "Attributes described as fixed length MUST NOT be encoded using the variable-length encoding." This cannot be correct, a new 4-octet attribute will have to be encoded as variable-length. It w…

Please open a tracker issue for this.

>3.6: "DNS Signed Key" is marked Unspecified. Is it not RFC 4025? It's not used anywhere, but still...

RFC 4025 only specifies how to format those keys in the DNS and in display, not in IKE. You can guess that you should use the RDATA format, but that's only a guess.

>3.6: [Hash and URL] "makes IKE less subject to denial of service attacks that become easier to mount when IKE messages are large enough to require IP fragmentation." This statement is hard to take s…

See the IPsec WG archives. If you really think this subjective rathole is worth opening again, open a tracker issue.

>3.10.1: INVALID_SELECTORS is underspecified. It should be rate limited (I suppose), also, how long is the packet fragment included in the notification? In addition, Sec. 2.21.2 implies that it is se…

Please open a tracker issue for this.

>3.15.1: "With IPv6, a requestor MAY supply the low-order address octets it wants to use." This means to me that you *don't* provide all 16 octets. But according to the table, the field is a fixed-le…

Please open a tracker issue for this.

>In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within…

Please open a tracker issue for this.

>5: what do we mean by "leaves all SAs vulnerable to ... overrun of either endpoint"?

Please open a tracker issue for this.

>5: unfortunately we have to revise the text about group strengths - or remove it altogether. It is non-normative, so it's probably best to eliminate it.

Why?

>B.1 (Group 1): We may want to add: "Use of this group is NOT RECOMMENDED."

Please open a tracker issue for this. Even though this is obvious, it is a tad late to be suggesting new normative language.

>C: I suggest to repeat at the top of this appendix this text from 2.5: "Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification…

If the appendix is as "purely informative" as it says, then putting normative language in it (even as duplication) is inappropriate.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Jan 2010 13:30:52 +0200

Yaron Sheffer writes:
> 2.21.: EAP Failure cases are missing altogether. Also, the first
> paragraph says that if an auth failure occurs at the responder,
> AUTHENTICATION_FAILED is included in the protected response (to
> IKE_AUTH),

Yes.

> while the last paragraph says it's a separate
> Informational exchange.

Where does it say that if failure occurs at the responder you are
allowed to use separate INFORMATIONAL exchange? It was supposed to say
that in case the failure occurs at the INITIATOR (i.e. parsing the
response packet) then it MAY use INFORMATIONAL exchange.

> 2.24: what's this section (ECN) doing here? It is 100% IPsec,
> nothing to do with IKE. If there's a reason, let's explain it in
> the text.

It is here because if IKEv2 is used then ECN behavior is implictly
mandated by just using IKEv2. In IKEv1 we had negotiation ability for
it, but not in IKEv2. I think the current text already explains this:

            ECN support for IPsec tunnels for IKEv1-
   based IPsec requires multiple operating modes and negotiation (see
   [ECN]).  IKEv2 simplifies this situation by requiring that ECN be
   usable in the outer IP headers of all tunnel-mode Child SAs created
   by IKEv2.  Specifically, tunnel encapsulators and decapsulators for
   all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
   functionality option for tunnels specified in [ECN] and MUST
   implement the tunnel encapsulation and decapsulation processing
   specified in [IPSECARCH] to prevent discarding of ECN congestion
   indications.

> 3.3.2: Tiger - we closed issue #33, but according to the text of the
> issue, should have left the algorithm "unspecified". Which I think
> would be much more accurate.

The "Not done" part is from the time Paul opened the issue, not the
final outcome from the issue.

Final outcome can be found from here:

http://www.ietf.org/mail-archive/web/ipsec/current/msg03187.html

> 3.3.5: "Attributes described as fixed length MUST NOT be encoded
> using the variable-length encoding." This cannot be correct, a new
> 4-octet attribute will have to be encoded as variable-length. It
> won't fit into the other format.

This should use "TV" and "TLV" format text instead:

   The only currently defined attribute type (Key Length) is using TV
   encoding; the TLV encoding specification is included only for
   future extensions. Attributes described as using TV encoding MUST
   NOT be encoded using the TLV encoding. Attributes described as
   using TLV encoding MUST NOT be encoded as using TV encoding even if
   their value can fit into two octets. NOTE: This is a change from
   IKEv1, where increased flexibility may have simplified the composer
   of messages but certainly complicated the parser.

> It's not used anywhere, but still...

I do not think the DNS Signed Key mans the same as IPSECKEY RR
specified in the RFC4025. Or it could be it means, but nobody knows,
thus I think it is correct to keep it UNSPECIFIED, especially as this
value dates back to the RFC2408 which predates RFC4025 and RFC4025
does not mention that it actually specifies what this format in IKE
should mean.

> 3.7: "If multiple CAs are trusted and the certificate encoding does
> not allow a list, then multiple Certificate Request payloads would
> need to be transmitted." This doesn't make sense: we are not sending
> the cert itself here. we're just sending an encoding on a CA.
> Moreover, the text further down indicates that the CA field is
> *always* a list - at least for the defined cert types (4, 12, 13).
> Overall, this looks like a placeholder, and I suggest to delete the
> sentence.

It is placeholder for other formats not defined in this document, i.e.
it explictly says that if some future certificate encoding type
defines format how certificate authorities are sent inside the CERTREQ
payload and that newly defined format does not allow list then
multiple CERTREQ payloads are sent.

As all currently defined certificate encodings do allow list, this
does not affect them.

I suggest keeping that text.

> 3.10.1: INVALID_SELECTORS is underspecified. It should be rate
> limited (I suppose), also, how long is the packet fragment included
> in the notification?

Yes, most likely it should be rate limited, but that is not hard
requirement, as this is caused when authenticated entity does
something incorrect (i.e includes traffic that is not allowed in this
SA).

Also RFC4301 already mentions rate limitation etc:
----------------------------------------------------------------------
   5.  If an IPsec system receives an inbound packet on an SA and the
       packet's header fields are not consistent with the selectors for
       the SA, it MUST discard the packet.  This is an auditable event.
       The audit log entry for this event SHOULD include the current
       date/time, SPI, IPsec protocol(s), source and destination of the
       packet, any other selector values of the packet that are
       available, and the selector values from the relevant SAD entry.
       The system SHOULD also be capable of generating and sending an
       IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
       indicating that the received packet was discarded because of
       failure to pass selector checks.

   To minimize the impact of a DoS attack, or a mis-configured peer, the
   IPsec system SHOULD include a management control to allow an
   administrator to configure the IPsec implementation to send or not
   send this IKE notification, and if this facility is selected, to rate
   limit the transmission of such notifications.
----------------------------------------------------------------------

I think the as in ICMP message provides good enough hint how the
packet fragment should be included (i.e. not too long as it would
waste bandwidth, but long enough to allow other end to see all
selectors). 

> In addition, Sec. 2.21.2 implies that it is sent during Child SA
> negotiation, which is not what 3.10.1 is saying.

Yes, the 2.21.2 should not include INVALID_SELECTORS in its list of
notify paylaods there, so changing

				Specifically, a
   responder may include all the payloads associated with authentication
   (IDr, Cert and AUTH) while sending error notifications for the
   piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
   NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
   authentication because of this.  

to

				Specifically, a
   responder may include all the payloads associated with
   authentication (IDr, Cert and AUTH) while sending error
   notifications for the piggybacked exchanges (FAILED_CP_REQUIRED
   NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
   authentication because of this.

is required.

> 3.15.1: "With IPv6, a requestor MAY supply the low-order address
> octets it wants to use." This means to me that you *don't* provide
> all 16 octets. But according to the table, the field is a
> fixed-length 16 octets!

No, you always include full 16 octets, but you might only fill in the
lower 8 octets. You can also fill in the full 16 octets, if you have
address from previous runs.

I.e. you can send following INTERNAL_IP6_ADDRESS payloads in the
CFG_REQUEST:

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64) = 17 bytes
INTERNAL_IP6_ADDRESS(::21d:9ff:fea5:c19a/64) = 17 bytes
INTERNAL_IP6_ADDRESS() = 0 bytes.

> 5: unfortunately we have to revise the text about group strengths -
> or remove it altogether. It is non-normative, so it's probably best
> to eliminate it.

Why is that, and what text you mean?

I still think group 2 (1024-bit group) is common for use with 3DES.
Also group 5 (1536-bit group) does provide more security than group 2
(1024-bit group).

Also group 1 (768-bit group) is for historic purposes only and does
not provide sufficient strength except for use with DES, which is also
for historic use only.

So which of those statement requires revising? 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 12:09:46 +0100

Paul Hoffman wrote:

> Please open a tracker issue for this. Even though this is obvious, it
> is a tad late to be suggesting new normative language.

This "NOT RECOMMENDED" would belong in an update to RFC 4307,
not this document.

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 Jan 2010 13:51:07 +0200

> This "NOT RECOMMENDED" would belong in an update to RFC 4307,

The current RFC4306 Security Considerations section already says:

            Group one is for historic purposes only and does not
   provide sufficient strength except for use with DES, which is also
   for historic use only.  

and I would think that group and algorithms which are historic use
only, are also NOT RECOMMENDED...

And yes, I agree it should really be in RFC4307, but the group is
defined here, so word of it not being recommended, might be good idea
in this document too.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 26 Jan 2010 15:38:06 +0200

Hi Tero, please see below.

Thanks,
	Yaron

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Monday, January 25, 2010 13:31
> To: Yaron Sheffer
> Cc: IPsecme WG
> Subject: [IPsec] IKEv2-bis comments: 2.17 and onwards
> 
> Yaron Sheffer writes:
Yes, I misunderstood the parentheses in that last paragraph of 2.21.2. It would have been clearer if we said "in case an error happened when the initiator processes a response to IKE_AUTH).

> http://www.ietf.org/mail-archive/web/ipsec/current/msg03187.html

No, there were follow-ups to that message, including one that gave the reference that we should include in bis:

Ross Anderson, Eli Biham, Tiger: A Fast New Hash Function, Fast Software Encryption 3, 1996, LNCS 1039.

> Also RFC4301 already mentions rate limitation etc:

I think we should give better guidance than a hint.

> authentication

So you are saying the responder (the IRAS) should interpret the prefix-length field as "the last X octets are the ones that I want retained in the new address, if that is possible"? This is not clear from the existing text.

> So which of those statement requires revising?

The one about Group 2. But I accept Pasi's judgment that this would be a rewrite of RFC 4307, i.e. let's forget it for now.

> --
> [email-masked]
> 
> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 27 Jan 2010 11:16:11 +0200

Yaron Sheffer writes:
> Yes, I misunderstood the parentheses in that last paragraph of
> 2.21.2. It would have been clearer if we said "in case an error
> happened when the initiator processes a response to IKE_AUTH).

Yes, that clarification might be better, i.e. the whole pararaph would
be then this:

   In an IKE_AUTH exchange, or in the INFORMATIONAL exchange
   immediately following it (in case an error happened when the
   initiator processes a response response to IKE_AUTH), the
   UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
   AUTHENTICATION_FAILED notifications are the only ones to cause the
   IKE SA to be deleted or not created, without a DELETE payload.
   Extension documents may define new error notifications with these
   semantics, but MUST NOT use them unless the peer has been shown to
   understand them.

> No, there were follow-ups to that message, including one that gave
> the reference that we should include in bis: 
> 

Yes there is responses and reference to Tiger hash function, but as
the RFC2104 works for any generic hash it works also with Tiger, and I
understood from Paul's message that he was ok with the RFC2104
reference and I do not think we need separate reference for each
algorithm. We have some of those references, and in some case we refer
to RFC which has references to the algorithm and in some cases (IDEA)
we have both, i.e. both reference to the RFC having reference to the
algorithm description and the direct reference to the algorithm
reference.

I think TIGER is the only algorithm where we do not have such
reference (either direct or inderect), so it might be good to add
reference for it.

> I think we should give better guidance than a hint.

Perhaps, but in the general I do not expect any kind of automatic
parsing of those INVALID_SELECTORS messages, so this is not so
important. In most cases I think the implementations will most likely
just audit and log the INVALID_SELECTORS notification and put the
notify data in the log file too, so adminstrator can check that later.

INVALID_SELECTORS message usually means that one end is not following
specification. If you want to provide some kind of guidance, I think
that is ok, but I do not think we should waste too much time working
on it. 

> So you are saying the responder (the IRAS) should interpret the
> prefix-length field as "the last X octets are the ones that I want
> retained in the new address, if that is possible"?

No. The prefix len is not really meaningful in the
INTERNALIP6_ADDRESS, in the same way as INTERNAL_IP4_NETMASK is not
really meaningful.

The gateway knows the real prefix len it has, and will replace the
prefix with the one it has regardless what prefixlen was requested by
the client.

I.e. if client had the 2001:1bc8:100d:2:21d:9ff:fea5:c19a/64 before
(i.e. the server gave that address last time etc), then it sends
request saying:

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64)

Server might respond with any of the following:

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64)

	Keep the same address, if it s free.

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:ff00:21d:9ff:fea5:c19a/64)

	Keep the same /48 prefix (2001:1bc8:100d::/48), but change the
	subnet inside it from 0002 to for example ff00, but keep the
	lower 64 bits.

INTERNAL_IP6_ADDRESS(2001:1234:5678:0:21d:9ff:fea5:c19a/64)

	If server has multiple /48 prefixes (for example
	2001:1234:5678::/48 in addition the 2001:1bc8:100d::/48 listed
	before), it can change the prefix and also subnet inside it or
	keep the same subnet.

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:3333:4444:5555:6666:/64)

	Server might want to change the lower 64-bits for any reason,
	for example if the address requested is still in use (for
	example the same machine has requested it before reboot, and
	the old IKE SA was not yet deleted, thus the address is still
	in use for that IKE SA), or for example to randomize the lower
	64-bits to hide the fact that this is same machine than before
	etc.

or the server can also do something else... :-)

Anyways the prefix length request and reply is not really meaningful.
In reply it has same meaning as INTERNAL_IP4_NETMASK has. In request
it is just whatever the server returned last time. I would except it
to be /64 always...

>From draft-ietf-ipsecme-ikev2bis-07:
----------------------------------------------------------------------
   o  INTERNAL_IP4_NETMASK - The internal network's netmask.  Only one
      netmask is allowed in the request and response messages (e.g.,
      255.255.255.0), and it MUST be used only with an
      INTERNAL_IP4_ADDRESS attribute.  INTERNAL_IP4_NETMASK in a
      CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET
      containing the same information ("send traffic to these addresses
      through me"), but also implies a link boundary.  For instance, the
      client could use its own address and the netmask to calculate the
      broadcast address of the link.  An empty INTERNAL_IP4_NETMASK
      attribute can be included in a CFG_REQUEST to request this
      information (although the gateway can send the information even
      when not requested).  Non-empty values for this attribute in a
      CFG_REQUEST do not make sense and thus MUST NOT be included.
...
   The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
   field.  When used in a CFG_REPLY, this corresponds to the
   INTERNAL_IP4_NETMASK attribute in the IPv4 case.
----------------------------------------------------------------------

> This is not clear from the existing text.

True, but as we have already work in progress to change the whole IPv6
address allocation situation, I do not think we should change this
text in IKEv2bis.

> The one about Group 2. But I accept Pasi's judgment that this would
> be a rewrite of RFC 4307, i.e. let's forget it for now. 

So you think group 2 is not common use with 3DES? The text is very
careful about not saying anything about the actual strength of either
algorithm (group 2 or 3DES), just comments that it is common use with
3DES (not that its strength match with it), and that it needs to be
used with random exponent longer than 200 bits for that use.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 28 Jan 2010 12:17:58 +0100

Tero Kivinen wrote:
> > > Please open a tracker issue for this. Even though this is obvious,
> > > it is a tad late to be suggesting new normative language.
> >

Hmm... I think the current security considerations text is quite 
sufficient to discourage people from using this, and repeating the same 
thing with upper-case RFC 2119 keywords doesn't seem to add anything
(and we have earlier agreed those keywords belong in a separate 
document anyway).

Best regards,
Pasi