Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: ESP Processing

<nalini.elkins@insidethestack.com> Wed, 04 January 2017 14:56 UTC

Return-Path: <nalini.elkins@insidethestack.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249D91293D9 for <secdir@ietfa.amsl.com>; Wed, 4 Jan 2017 06:56:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 6KHHxdXS0ERY for <secdir@ietfa.amsl.com>; Wed, 4 Jan 2017 06:56:44 -0800 (PST)
Received: from nm30-vm8.bullet.mail.gq1.yahoo.com (nm30-vm8.bullet.mail.gq1.yahoo.com [98.136.216.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982F712958A for <secdir@ietf.org>; Wed, 4 Jan 2017 06:56:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1483541803; bh=q3kkoO3oFHfcAexFMtuK7TYSf6/ocrfNkX0lyT4pQxQ=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=E/Ek5+6kiaVJvbFUovG28++4MH2rnSNeMuEaBW5wieqd0SMpbJUxkNwder3iu83pSAIun8YVqS0GaPfxFwrmylhcct8D7uW0H4lo3u6GSkZbgZHFJXOL6YTiBddkOnn557d8EuaAZKb+Dzp4KMXLHkGPVCgI7bxScmwsD6KapNuntWwhdIPbjn2jbJlp9kQ2dyTcF2u12pZDKS5hZIO68Z6l4exHGxC+e5w6+YRrzm9F1asI0n9ldzf5TwZEWbMi5Uihi/SoZqZBa83TydAtnHlRGex7R2/ET4NPfPUfk6k1vDjt8cV//WCCdVq6BuGxKC8KBte2vZRpgAt2xbJabg==
Received: from [98.137.12.174] by nm30.bullet.mail.gq1.yahoo.com with NNFMP; 04 Jan 2017 14:56:43 -0000
Received: from [98.137.12.192] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 04 Jan 2017 14:56:43 -0000
Received: from [127.0.0.1] by omp1000.mail.gq1.yahoo.com with NNFMP; 04 Jan 2017 14:56:43 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 846030.74235.bm@omp1000.mail.gq1.yahoo.com
X-YMail-OSG: PbdznzIVM1kokTF0MqLo2b_iVEhHdFBaa2LF4tPUewCaMQGLW6CovwozAYOeiIn 4XrPVcdX819A6jMnnmsvjbKOSKJFA1sj4NqdyzSzIqbm1v7dLcEMm400Shrq3b8UzRMGVC_qVGTP yDBOJw1aktifSqSERiiiZ6f1SCkXRXb0Bp9vpCgEMPOiOREWdP8kbH10vsv5vF9leM.voQ_CqMFL wfA7LqRhXSCYl.K9.Q6Nu5IotTonPQVo6wfOk7GFsGtCd9a9J0mO8uP82lfxY0XbJvPBi9FcEOJ6 KpYGXZGscxve3WXocAZBDwb5_apGKzxMwEZ8N.Nsbc5WFw5gR72zS9HsBd9cXwf8OQAyePYd8aMf C3KK7sNdSTE7gtXR2B8FkdmTGO2sgT5WNrlrQ5rK4KsYCGugMrAX9yClYkurSrW4lboEbQU5BJUw WagHwHjNNhmQkz0Hl6pUyfX4TG7Vy_ZP9Gx891_00JRUrGBh8spDElD3MmGXt09T04rYlqnnPHIP hteuZ.W_3L0oVPTptqwh7B20dMIb_Tm4d4oiyxzXThBo7G4yRuYqEGC.l5.YkZohz
Received: from jws300046.mail.gq1.yahoo.com by sendmailws133.mail.gq1.yahoo.com; Wed, 04 Jan 2017 14:56:43 +0000; 1483541803.468
Date: Wed, 4 Jan 2017 14:56:43 +0000 (UTC)
From: <nalini.elkins@insidethestack.com>
To: Tero Kivinen <kivinen@iki.fi>
Message-ID: <884033410.7600072.1483541803113@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
References: <884033410.7600072.1483541803113.ref@mail.yahoo.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Nt4ydmd-Zncxnfic_rNl27XfoZA>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" <draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: ESP Processing
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: nalini.elkins@insidethestack.com
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2017 14:56:46 -0000





nalini.elkins@insidethestack.com writes: 
>> New Section 3.4 
>> 
>> 3.4 Header Placement Using IPSec ESP Mode 
>> 
>>    IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] and 
>>    is widely used.  Section 3.1.1 of [RFC4303] discusses placement of 
>>    Destination Options Headers. 
>> 
>>    The placement of PDM is different depending on if ESP is used in 
>>    tunnel or transport mode. 
>> 
>>    3.4.1 Using Transport Mode 
>> 
>>    Below is the diagram from [RFC4303] discussing placement of headers. 
>> 
>>    Note that Destination Options MAY be placed before or after ESP or 
>>    both.  In transport mode, PDM MUST be placed after the ESP header so 
>>    as not to leak information. 
>> 
>>                            BEFORE APPLYING ESP 
>> 
>>              --------------------------------------- 
>>        IPv6  |            | ext hdrs |    |      | 
>>              | orig IP hdr |if present| TCP | Data | 
>>              --------------------------------------- 
>> 
>>                            AFTER APPLYING ESP 
>>              --------------------------------------------------------- 
>>        IPv6  | orig |hop-by-hop,dest*,|  |dest|  |    | ESP  | ESP| 
>>              |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| 
>>              --------------------------------------------------------- 
>>                                          |<--- encryption ---->| 
>>                                          |<------ integrity ------>| 
>> 
>>              * = if present, could be before ESP, after ESP, or both 
>> 
>> 3.4.2 Using Tunnel Mode 
>> 
>>    Below is the diagram from [RFC4303] discussing placement of headers. 
>> 
>>    Note that Destination Options MAY be placed before or after ESP or 
>>    both in both the outer set of IP headers and the inner set of IP 
>>    headers. 
>> 
>>    In tunnel mode, PDM MAY be placed before or after the ESP header 
>>    or both. 
>> 
>>                              BEFORE APPLYING ESP 
>> 
>>            --------------------------------------- 
>>      IPv6  |            | ext hdrs |    |      | 
>>            | orig IP hdr |if present| TCP | Data | 
>>            --------------------------------------- 
>> 
>>                      AFTER APPLYING ESP 
>> 
>>            ------------------------------------------------------------ 
>>      IPv6  | new* |new ext |  | orig*|orig ext |  |    | ESP  | ESP| 
>>            |IP hdr| hdrs*  |ESP|IP hdr| hdrs *  |TCP|Data|Trailer| ICV| 
>>            ------------------------------------------------------------ 
>>                                |<--------- encryption ---------->| 
>>                            |<------------ integrity ------------>| 
>> 
>>            * = if present, construction of outer IP hdr/extensions and 
>>                modification of inner IP hdr/extensions is discussed in 
>>                the Security Architecture document. 

>For tunnel mode you could add text noting, that as the sgw will make 
>completely new IP packet, it means that PDM information for that 
>packet does not contain any information from the inner packet, i.e. 
>the PDM information will NOT be based on the TCP ports etc in the 
>inner header, but will be specific to the ESP flow. 

>If you want to see PDM information for the inner packet, the original 
>host sending the inner packet needs to put PDM header in the tunneled 
>packet, and then the PDM information will be specific for that TCP 
>stream. 

OK.

>So if the PDM header is part of "new ext hdrs*" then it specifies the 
>ESP flow, and it will not be end to end, it will only between SGSs. If 
>the PDM is part of the "orig ext hdrs*", then it will be end to end 
>PDM header, and ESP processing does not modify it at all. This 
>location is only place, where you can get end to end information about 
>the flow. 

>The first PDM header which is part of the ESP, will not separate TCP 
>flows at all, as it is for the ESP packets, thus it might not be that 
>useful, especially as there is no relation between the inbound ESP 
>packet and outbound ESP packet. The inbound ESP packet might be TCP 
>packet, and the tunneled packet is sent forward to the inner network, 
>and then the next outbound ESP packet might be from some completely 
>different host in different stream, and might be for example UDP DNS 
>packet. Having PDM information between those packets does not really 
>help debuggin at all.

I think the first PDM header is, of course, not as helpful as the first.
I suppose what one has is a sense of how that stack (server / client) is
responding to various requests.

I think that might be useful.  If one sees very good service at one time
and not so good service for others, then one knows that it is not the server
or client itself that is "hung".  If that makes sense.  

Or if there is a network issue to that device.  That is the kind of thing that
I get involved in often.

Nalini