Re: LAST CALL: IKE

[Stephen Kent <kent@bbn.com>]

>In anticipation of several proposed changes to RFC 2401, I would like to suggest a few additional payloads to be added to IKE v2.

Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested.  He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions.  So, let me try again.

>Several folks have asked for the ability to place traffic with different TOS values on different SAs, which requires that the TOS field (IPv4) and the flow spec field (IPv6) be useable as selectors. If we agree to add this feature, we need the ability to negootiate this in IKE.

What I meant to say is what David said in his message, i.e.:
That would be the 6 bit DS Field, as defined in RFC 2780.  The other

two bits in the same header octets are used for ECN and should not be

used as selectors.  There are some subtle issues in QoS specification

across administrative domain boundaries - in full generality, the

DiffServ Code Point (DSCP) values used in the DS Field do not have

global validity or meaning.



It's ok to use DSCPs when the values are only expected to be

meaningful to one end of the connection (e.g., receiver tells

sender to set DSCP to

in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. At least this covers the IPv4 case. I'm open to suggestions from IPv6 experts about what to do there, for flows. Radia also comment on this issue, but I have to disagree with her a bit; I think it is important to allow the initiator to specify the intent to segregate traffic by the DS field, e.g., to try to get the responder to treat return traffic accordingly. Thinking ahead, we ought to decide if there are other fields we want to specify as selectors, now. For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. >A few folks have observed that the current mandate for black side fragmentation poses DoS vulnerabilities for receivers. Thus we may choose to allow (or recommend) red side fragmentation. If so, we need to be able to negotiate use of this capability on a per-SA basis, and to notify the receiver that NO black fragments should be accepted, because none will be sent on this SA. My terminology here was sloppy, relative to what we usually use in IPsec. Today, we require an IPsec implementation to fragment a packet after processing, if we increase its size beyond the MTU for the link via which the packet is being transmitted from the IPsec implementation. This creates a problem for a receiver, because an attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems. If we allowed a sender to fragment a packet prior to IPsec encapsulation, then we could avoid this problem. So, I was suggesting that we add a paylod to IKE to allow an initiator to indicate the intent to perform such fragmentation on an SA, with the ability of the responder to indicate whether this is OK (i.e., it knows how to manage the reassembly after IPsec decapsulation), or not (the status quo). An acceptance by the responder would imply that it could choose to do the same for the companion SA. A logical, but separable, companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable., minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). >As a separate matter, I had requested a few months ago that we allow IKE peers to negotiate use of groups other than the set defined in Oakley. I see that there is a provision to negotiate other choices for P, but not for G. I apologize for not noticing this sooner. I would like to see the negotiation made more general, so that both the generator as well as the exponent are values that peers can negotiate. This is a request to make the IKE parameter space negotiation more flexible. there would be no requirement that a conforming implementation support other groups than the ones defined in the separate IKE algorithms spec. But it would allow user communities to specify other groups for their own use. I thought we agreed on this a while ago, but I didn't check closely enough to realize that the current IKE version allows only the exponent, not the generator, to be specified. My intent had been to allow both to be specified. Steve