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

From: Stephen Kent <[email-masked]>
Date: Thu, 23 Dec 2004 14:26:15 -0500

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: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Dec 2004 09:15:45 +0100

I was asked to make this review for Harald's General Area review team.

    Brian

-------- Original Message --------
Subject: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]
Date: Mon, 20 Dec 2004 11:58:03 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
CC: [email-masked]
References: <[email-masked]>

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

...

...

Nits:
=====

> 4.4.1 The Security Policy Database (SPD)
...
> Decorrelation
...
> (unordered) state.  ppendix B provides an algorithm that can be

s/Appendix/ppendix/

Then idnits has complaints:

idnits 1.58

tmp/draft-ietf-ipsec-rfc2401bis-05.txt:

   Checking nits according to http://www.ietf.org/ID-Checklist.html :

     Checking conformance with RFC 3667/3668 boilerplate...
   * The document seems to lack an RFC 3667 Section 5.4 Copyright Notice --
     however, there's a paragraph with a matching beginning. Boilerplate error?
     ( - It does however have an RFC 2026 Section 10.4(C) Copyright Notice.)
   * The document seems to lack an RFC 3667 Section 5.5 Disclaimer --
     however, there's a paragraph with a matching beginning. Boilerplate error?
   * The document seems to lack an RFC 3668 Section 5, para 3 IPR Disclosure
     Invitation -- however, there's a paragraph with a matching beginning.
     Boilerplate error?
   * There are 105 instances of too long lines in the document, the longest
     one being 7 characters in excess of 72.

   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

   * The document seems to lack a 1id_guidelines paragraph about
     Internet-Drafts being working documents.
   * The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity.
   * The document seems to lack a 1id_guidelines paragraph about the list of
     current Internet-Drafts.
   * The document seems to lack a 1id_guidelines paragraph about the list of
     Shadow Directories.

   Miscellaneous warnings:

   - There are 28 instances of lines with hyphenated line breaks in the
     document.
   - Line 512 has weird spacing: '...support  multi...'
   - Line 1029 has weird spacing: '...g value  examp...'
   - Line 1031 has weird spacing: '...elector  selec...'
   - Line 1610 has weird spacing: '...oc addr  list ...'
   - Line 1615 has weird spacing: '...em addr  list ...'
   - (18 more instances...)

     Run idnits with the --verbose option for more detailed information.

      Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Dec 2004 16:52:10 +0100

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:
> 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.
> 
> 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.
> 
>>
>     Bypass DF bit (T/F) - applicable to tunnel mode SAs where both inner 
> and outer headers are IPv4
> 
> 
> 8.1 DF Bit
> 
>    (set, clear, copy from inner header) for each SA. This applies to SAs 
> where both inner and outer headers are IPv4.
> 
>>
>>>
> 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:
> 
> 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
> 
> 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
>