Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 4 Feb 2005 09:45:55 -0800

Hi Tero,
 
This is the last mail on the subject from me. I am sorry about going on and on, as they seem like obvious.
 
I am sorry, as we have been having a private discussion(maybe that is the reason for the misunderstanding) and after some thought this is what we have come to some point with the DSCP and ECN, you may want to take a look at it. I am just sending you abstracts from the last mail sent in the discussion and most of the text is by David Black. 
 
I am sorry about the (K, S) part too. I guess I was not clear here. If K and S mean something they should be explained. can we instead use x(Y, Z),  x is the function and Y and Z the inputs as very obvious. I think we need to specify it.
 
I am not sure how saying "An IKE endpoint MUST NOT exceed the peer's stated window size for
transmitted IKE requests. " is not obvious(and hence the long explanation) and why stating something else is.
 
As I said RFC3948, specifies the sending as well as the receiving, I am not sure why something about sending is respecified in the IKE draft, but not receiving.
 
Thanks,
Vishwas
==============================================
The informational reference to 2983 is important.  I think this may be
better handled by paralleling the text in 5.1.2 about the DS field and
covert channels:

    o IPsec offers certain controls to a security administrator to
      manage covert channels (which would not normally be a concern for
      tunneling) and to ensure that the receiver examines the right
      portions of the received packet re: application of access
      controls. An IPsec implementation MAY be configurable with regard
      to how it processes the outer DS field for tunnel mode for
      transmitted packets. For outbound traffic, one configuration
      setting for the outer DS field will operate as described in the
      following sections on IPv4 and IPv6 header processing for IPsec
      tunnels. Another will allow the outer DS field to be mapped to a
      fixed value, which MAY be configured on a per SA basis. (The value
      might really be fixed for all traffic outbound from a device, but
      per SA granularity allows that as well.) This configuration option
      allows a local administrator to decide whether the covert channel
      provided by copying these bits outweighs the benefits of copying.

I would also expect Steve to object to Vishwas's proposed SHOULD.  Here's
an attempt on my part - take the current bullet:

    o IPsec describes how to handle ECN or DS.

and replace it with:

    o IPsec describes how to handle ECN or DS and provides the ability
        to control propagation of changes in these fields from unprotected
        to protected domains.  ECN is controlled so that only legitimate
        ECN changes (indicating occurrence of congestion between the tunnel
        endpoints) are propagated.  By default, DS propagation is not
        permitted.  When the traffic management benefits of DS propagation
        outweigh the security concerns, an IPsec implementation MAY be
        configurable with regard to how it processes the outer DS field
        for tunnel mode for received packets.  For inbound traffic, one
        configuration setting for the outer DS field will discard it and
        use the inner DS field as described in the following sections on
        IPv4 and IPv6 header processing for IPsec tunnels. Another will
        copy the outer DS field to overwrite the inner DS field; this
      discard vs. overwrite behavior MAY be configured on a per SA basis.
      (The behavior might really be fixed for all traffic inbound to a
        device, but per SA granularity allows that as well.) This
configuration
        option allows a local administrator to decide whether the
information
        propagation concerns raised by copying these bits outweigh the
        benefits of copying.  See [RFC 2983] for further information on when
        each of these behaviors may be useful, and also for the possible
        need for diffserv traffic conditioning prior or subsequent to IPsec
        processing (including tunnel decapsulation). 

While this is more text than adding a (9) note, I think the longer
explanation is better, as it explains the security issues rather than
hoping that the reader will correctly infer them.   Leaving the
tables as they are avoids security surprises when someone skims
the RFC and just implements the tables.  Since my proposed "implementation
MAY be configurable" text above is qualified by "When the traffic
management benefits of DS propagation outweigh the security
concerns" I think that "MAY" could be a "SHOULD" but I'm not going
to insist on this change.

________________________________

From: Tero Kivinen [mailto:[email-masked]]
Sent: Fri 2/4/2005 7:28 AM
To: Vishwas Manral
Cc: [email-masked]
Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt

Vishwas Manral writes:
> However I am still confused about why we talk about ECN and not DSCP.

DSCP values are copied during the encapsulation, and they are not
changed during the decapsulation, thus there is no need to do anything
special there.

The ECN values are similarly copied during the encapsulation, but in
the decapsulation they are reconstructed based on the both inner and
outer ECN values.

The processing of the ECN has changed from the rfc2401 to RFC2401bis,
and the RFC3168 describing ECN had a negotiation method how to
negotiate that the ECN bits are processed like in rfc2401bis. The text
we have about ECN in the IKEv2 draft simply says, that all SAs
negotiated using IKEv2 must construct the ECN bits, i.e the
negotiation of that feature is no longer needed.

> Also I still believe we should specify behavior more clearly about
> receiving messages on 4500(if it is specified in another RFC, do we need
> to write anything about the send itself, isn't sending specified in the
> UDP encapsulation?).

UDP encapsulation is described in the RFC 3948, and we already have
reference to that in few places. I do not think we need to say
anything more about the issue, than simply say that IKE packets are
prepended with 4 bytes of zero.

> On why K, S are used yet nowhere specified what they mean (while
> everything else is explained).

As I said they are inputs to the function of prf+. I do not think they
need to be explicitly specified as such, as it is obvious from the
context.

> On why we give " In
> other words, if the responder stated its window size is N, then when the
> initiator needs to make a request X, it MUST wait until it has received
> responses to all requests up through request X-N.", when it is self
> explanatory anyway, and if we give it why we do not define the ranges of
> things we talk about.

That text explains how the windows work in general. If we remove it
then the text will be hard to understand.
--
[email-masked]

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