Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]]

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 24 Dec 2004 05:29:12 -0800

Hi Steve,

> This requirements applies to both transport and tunnel mode 
> SAs. In the case of tunnel mode SAs, the DSCP values in question 
> appear in the inner IP header. In transport mode, the DSCP value 
> might change en route, but this should not case problems with 
> respect to IPsec processing since the value is not employed for 
> SA selection and MUST NOT be checked as part of SA/packet 
> validation. When the DSCP value changes en-route can it defeat 
> the reason of having DSCP as a classifier.

"  If different classes of traffic (distinguished by Differentiated
   Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the
   same SA, and if the receiver is employing the optional anti-replay
   feature available in both AH and ESP, this could result in
   inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature. Therefore a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support QoS appropriately."

Do you think some clarification is required for this? Besides I do not see a 
reason we cannot support flowId as a classifier(it's a local matter at the 
tunnel head-end) as long as we allow multiple SA's between a sender receiver
pair.

Thanks,
Vishwas

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Friday, December 24, 2004 12:56 AM
To: Brian E Carpenter
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]]

Brian,

Thanks for the review comments.  Our responses are inline below.

I think this is basically ready to go, but I have a few minor comments
and there are some nits.

(I will flag this review to the authors etc once Avri has posted it.)

Slightly substantive:
=====================

4.1 Definition and Scope
... 
   If different classes of traffic (distinguished by Differentiated
   Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the
   same SA, and if the receiver is employing the optional anti-replay
   feature available in both AH and ESP, this could result in
   inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature.  Therefore a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support QoS appropriately.  To permit this, the
   IPsec implementation MUST permit establishment and maintenance of
   multiple SAs between a given sender and receiver, with the same
   selectors.  Distribution of traffic among these parallel SAs to
   support QoS is locally determined by the sender and is not negotiated
   by IKE. The receiver MUST process the packets from the different SAs
   without prejudice.

I think it would be helpful to remind readers that (as indicated
in RFC 2983) we are talking here about the "inner" DSCP in a tunnel,
which will not be changed en route (since in general, the DSCP
value may be changed en route and that destroys the model described,
since there would be no fixed relationship between DSCP value and SA).

The text above applies to both tunnel and transport mode, but yes, in tunnel mode, we are talking about a DSCP value that appears in the inner header.  also note that in transport mode a change to the DSCP value en route has no effect at the receiver in terms of IPsec processing, because the receiver is not paying attention to the DSCP value in demuxing the traffic (assigning it to an SA). I suggest we add the following text at the end of the paragraph cited above:

This requirements applies to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not case problems with respect to IPse processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation.

I also note that there is no reference to the IPv6 Flow Label. Since this
is an e2e field (RFC 3697) it would actually be easier to handle than the
DSCP, if there was any need to do so.

We do talk about processing flow labels in 5.1.2.2, but we do not require that an implementation offer different SAs based on flow labels. The WG did not express an opinion that we needed to offer support for QoS based on this  parameter, but did for DSCP, and that's what motivated the text in 4.1.

4.4.2.1 Data Items in the SAD
... 
    o Bypass DF bit (T/F) - applicable to tunnel mode SAs

Note that this only applies to IPv4 (ditto section 8.1).

OK, we will change the text to be:

        Bypass DF bit (T/F) - applicable to tunnel mode SAs where both inner and outer headers are IPv4

8.1 DF Bit

   All IPsec implementations MUST support the option of copying the DF
   bit from an outbound packet to the tunnel mode header that it emits,
   when traffic is carried via a tunnel mode SA. This means that it MUST
   be possible to configure the implementation's treatment of the DF bit
   (set, clear, copy from inner header) for each SA. This applies to SAs where both inner and outer headers are IPv4.

    o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
      needed to restrict bypass of DSCP values - applicable to tunnel
      mode SAs

This is unclear to me and needs some explanation. Actually, it's
unclear how the earlier suggested treatment of DSCPs works,
since the DSCP value(s) corresponding to an SA aren't stored anywhere
that I noticed, so the model does not allow for demultiplexing on
DSCP values in any case.

The text immediately above says that either you can bypass a DSCP value from an inner IP header to the outer header in tunnel mode, OR you can map the inner value to an entry in an array of DSCP values that are used to populate outer IP headers in tunnel mode. The latter mechanism would be used if one wanted to try to limit the covert channel bandwidth associated with bypassing these values, or if the inner header values were meaningful only in the protected nets behind security gateways and had different, corresponding values in the nets on the other (unprotected) side of the gateways. here is some additional text:

        Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
      needed to restrict bypass of DSCP values - applicable to tunnel
      mode SAs. This feature maps DSCP values from an inner header to
     values in an outer header, e.g., to address covert channel
     signalling concerns.

Your second point is that we said that a sender had to be able to allow use of different SAs for different traffic classes, e.g., based on DSCP values, but here we didn't mandate support for storing the different values in the SAD, to aid the sender in selecting the right SA to use for different DSCPs. Good point! We will add the following text to the SAD description to fix this oversight

    o DSCP values: the set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA. 

Steve 

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 27 Dec 2004 11:09:00 -0500

>tunnel head-end) as long as we allow multiple SA's between a sender receiver

Since the text above mandates support for multiple SAs with the same 
traffic selectors between a pair of IPsec implementations, then yes, 
one could make a local decision to use the flowId as a classified. 
But, since 2401bis is silent on this detail, there is no guarantee 
that this capability will be available in any implementation.

I agree with Brian that if we have experience suggesting that this is 
an important feature, we can make exlicit comments about it in a 
later revision.

Steve