Re: [conex] Kathleen Moriarty's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT)

Suresh Krishnan <suresh.krishnan@ericsson.com> Thu, 01 October 2015 01:41 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9406B1ACE2D; Wed, 30 Sep 2015 18:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AkM5T8EOuUA; Wed, 30 Sep 2015 18:41:55 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CECD1ACE2C; Wed, 30 Sep 2015 18:41:55 -0700 (PDT)
X-AuditID: c6180641-f792c6d00000686a-98-560c23b782e6
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.D8.26730.7B32C065; Wed, 30 Sep 2015 20:02:31 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 21:41:53 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, The IESG <iesg@ietf.org>
Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT)
Thread-Index: AQHQ+7Vq9thQLxuvy0KgOa4wEJ46Lg==
Date: Thu, 1 Oct 2015 01:41:53 +0000
Message-ID: <E87B771635882B4BA20096B589152EF63A976DE1@eusaamb107.ericsson.se>
References: <20150930192253.28856.7833.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXSPt+52ZZ4wg0l3zCzOPbzMZHHo2k9G i4eP0i3en/rCbtG9+he7xYw/E5ktGnbmO7B77Jx1l91jyZKfTB4zjr1kD2CO4rJJSc3JLEst 0rdL4Mo4NOE0Y8ESjYrt59QbGDcqdjFycEgImEisX6bcxcgJZIpJXLi3nq2LkYtDSOAoo8SL G6/YQBJCAssZJSbPlAKx2YDqN+z8zARiiwiESDz8PIUFpIFZYD6TxNF/l5lBEsICqRIH7p5m hChKk5h0/iRUg57E8s5jYENZBFQkPu/tBrN5BXwlDn+cwQixzEHi8OmLLCA2I9BF30+tAetl FhCXuPVkPhPEpQISS/acZ4awRSVePv7HCmErSXz8PZ8dol5HYsHuT2wQtrbEsoWvmSF2CUqc nPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAmPomASb4w7GBZ8sDzEKcDAq 8fAqAGNLiDWxrLgy9xCjNAeLkjjvvBn3Q4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwavsW zPmUOe1KxqFFjJz9vW9ZrziVntvP0fL0sfH8SQGzJlb2/AgQ5dJieqX/foHa+v53F1gdou5p 5D21++l5zSnjivTFqPJLa3/pfHUwZkv+NUGm8eMtLSElf6ddIU76YR+7Zi73fqPFN9XvsSL7 SaGbX983zTGYILtgy8GCHR33tz7f636bUYmlOCPRUIu5qDgRALVjuO+CAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/AxeOFMhnRyz0mN9KAN8lyI_iBjs>
Cc: "draft-ietf-conex-destopt.ad@ietf.org" <draft-ietf-conex-destopt.ad@ietf.org>, "conex-chairs@ietf.org" <conex-chairs@ietf.org>, "conex@ietf.org" <conex@ietf.org>, "draft-ietf-conex-destopt@ietf.org" <draft-ietf-conex-destopt@ietf.org>
Subject: Re: [conex] Kathleen Moriarty's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT)
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 01:41:57 -0000

Hi Kathleen,
   Thanks a lot for your comments. Please find responses inline.


On 09/30/2015 03:22 PM, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-conex-destopt-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I think this should be easy to address, but wanted to discuss options for
> the text in section 7.  Since there is text that says IPsec
> Authentication should be used when integrity protection and the section
> goes on to also discuss encryption, shouldn't there be a similar
> statement that says IPsec encryption should be used when there is a need
> to protect confidentiality?

Yes. We were worried more about the authentication because tampering of 
the packet to scrub the markings would cause audit devices to penalize 
the connection. Encryption on the other hand would be counterproductive 
as the intermediate nodes would be unable to observe the markings.

>
> Also, in reading this, I think because of the selected wording, I was
> thinking that it wasn't clear enough on the need/recommendation for
> authentication or encryption with IPsec since there are options for both
> to be set to NULL/none.  You can have a NULL cipher-suite and you can
> also have authentication set to none to allow for opportunistic security
> negotiations (fairly new RFC for the latter).  There's no need to mention
> these options explicitly, but rather to make it clear that IPsec can be
> used to provide authentication and encryption.  So I think one additional
> sentence and some possible rewording in this section would be helpful.

I have added a new sentence about encryption and reworded some of the 
text to clarify. Does this text change work for you?

OLD:

If the transport network cannot be trusted, IPsec Authentication
should be used to ensure integrity of the ConEx information.  If an
attacker would be able to remove the ConEx marks, this could cause an
audit device to penalize the respective connection, while the sender
cannot easily detect that ConEx information is missing.

In IPv6 a Destination Option header can be placed in two possible
position in the order of possible headers, either before the Routing
header or after the Encapsulating Security Payload (ESP) header
[RFC2460].  As the CDO is placed in the destination option header
before the AH and/or ESP, it is not encrypted in transport mode
[RFC4301].  Otherwise, if the CDO were placed in the latter position
and an ESP header were used, the CDO would also be encrypted and
could not be interpreted by ConEx-aware devices.

NEW:

If the transport network cannot be trusted, the IPsec Authentication 
Header (AH) [RFC4302] should be used to ensure integrity of the ConEx 
information. If an attacker would be able to remove the ConEx marks, 
this could cause an audit device to penalize the respective connection, 
while the sender cannot easily detect that ConEx information is missing. 
Similarly, if confidentiality of the transmitted information is desired, 
the IPsec Encapsulating Security Payload (ESP) [RFC4303] should be used.

Inside an IPv6 packet, a Destination Option header can be placed in two 
possible positions, either before the Routing header or after the ESP/AH 
headers as described in Section 4.1 of [RFC2460].  When the CDO is 
placed in the destination option header before the AH and/or ESP, it is 
not encrypted in transport mode [RFC4301].  Otherwise, if the CDO were 
placed in the latter position and an ESP header was used with 
encryption, the CDO cannot be viewed and interpreted by ConEx-aware 
intermediate nodes effectively rendering it useless.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> For the Security Considerations section, I'd just ask that you add in
> "IPsec" when AH and ESP are first mentioned so this is clear.

Does the above wording change work to resolve this as well?

Cheers
Suresh