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: Sun, 26 Dec 2004 21:26:57 -0800

Hi,

I agree with what Brian said. I just noticed some formatting issues 
with my previous mail because of which one of the points I stated got
missed. 

When the DSCP value changes en-route can it defeat the reason for 
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?

Thanks,
Vishwas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian E Carpenter
Sent: Friday, December 24, 2004 9:22 PM
To: Stephen Kent
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]]

Steve,

Thanks, that all looks good to me.

wrt to the Flow Label, I'm not surprised it didn't come up, because
it is an unused field today and RFC 3697 is quite recent. With respect
to Vishwas' comment on this, as long as the draft doesn't *forbid*
it being used in an SA, I think it's probably better to wait for
some experience with flow label usage before trying to craft language.

    Brian

Stephen Kent wrote:
> 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:12:09 -0500

>having DSCP as a classifier?

If an external DCSP value changes en route, it will not defeat the 
effect of using separate SAs for different traffic priorities, since 
the DSCP value is NOT used by a receiver to demux the trafic to 
different SAs.

>Do you think some clarification is required for this?

Brian said that I think the text I proposed addressed his concerns re 
clarifications, so I think I will stop with that text.

Steve