Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Bob Briscoe <in@bobbriscoe.net> Mon, 16 July 2018 23:12 UTC

Return-Path: <in@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F986130EDF; Mon, 16 Jul 2018 16:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 KU2pzzPlGGFi; Mon, 16 Jul 2018 16:12:54 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD8D126BED; Mon, 16 Jul 2018 16:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+3+uXbZefwxXBfOfsTokmzU410UGwWWczKYsUH3YuS4=; b=6Mly/cCrjTC5ioatNg+hraviY sh2e2KcjTVuuWh72TK4UTpcRr3/0a2X2fusVUA+3gID3z9DXijFTSHCGUDj8VGekTaGak+hmgXrXD VQMM3gTAQoow0f+e2ppJ7IYIxcJnMUzqSJbS3xoLvrORX4tI+W5OczGffXsdcK8uj7z0OsYcDUicf Xm8wR8OHKoXg4QVxfgxmYXF1JCHbryOc1qpa+sya7rDJQY2JqHkm4wHPSxIbbzI5Pj/FV18IYARXb KTMW1VBhZNkvHnIHohysFmc2D8I7kFqfUA2ekXrA7p8J+ZCyofM4bo/e6r9dT1VjuOpdZfrZ/7hbS QRRC733Ng==;
Received: from dhcp-80b8.meeting.ietf.org ([31.133.128.184]:50634) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <in@bobbriscoe.net>) id 1ffCfk-0001vd-Ab; Tue, 17 Jul 2018 00:12:52 +0100
To: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, "Scheffenegger, Richard" <rs.ietf@gmx.at>, "draft-ietf-tcpm-accurate-ecn@ietf.org" <draft-ietf-tcpm-accurate-ecn@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <AM2PR07MB086725AB3E0DFF2CFFAAE07A935E0@AM2PR07MB0867.eurprd07.prod.outlook.com> <25ea555d-8eea-57f1-8652-8dd234441010@gmx.at> <VI1PR07MB08800A9BA1D2195D62A1FE32935D0@VI1PR07MB0880.eurprd07.prod.outlook.com>
From: Bob Briscoe <in@bobbriscoe.net>
Message-ID: <6da3bc63-7720-2d5a-7cf4-dc79c791e9c7@bobbriscoe.net>
Date: Mon, 16 Jul 2018 19:12:50 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <VI1PR07MB08800A9BA1D2195D62A1FE32935D0@VI1PR07MB0880.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------E5B57CACC3C1581A934645A1"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/4qUeXRVuk-gVHqHVK0QfGib6b-E>
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2018 23:12:58 -0000

Michael,

> -----Original Message-----
> From: Scheffenegger, Richard [mailto:rs.ietf@gmx.at]
> Sent: Monday, July 16, 2018 11:16 AM
> To: Scharf, Michael (Nokia - DE/Stuttgart)<michael.scharf@nokia.com>om>;
> draft-ietf-tcpm-accurate-ecn@ietf.org;tcpm@ietf.org
> Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>
> Hi Michael,
On 16/07/18 13:48, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>> Section 7.  Security Considerations
>>>
>>> [ms] I wonder about the security implications of "confusing" classic ECN
>>> and AccECN feedback in (passive) network monitoring solutions,
>>>
[snip]
>> [RS] As to the passive monitoring - Mirja and Brian will certainly expand on this,
>> but sampling ever so often should expose ACE field codepoints with high
>> probability, which are unlikely or not possible with RFC3168 ECN (e.g. CWR +
>> ECE is very unlikely - pure ACKs are not ECT marked in RFC3168, and
>> bidirectional data exchange without stretches of pure acks is not common),
>> anything with the former "NS" bit set has never been observed on the public
>> internet to my knowledge. To summarize random sampling has at least a
>> 5/8th chance to detect AccECN. However, as r.cep (section 3.2) is initialized to
>> a value of 5 (101b), and many (short) flows probably rarely encounter a CE
>> mark, the chance to detect, by random sampling, the presence of AccECN
>> passively is even higher than this.  Short flow with up to 2 CE marks are
>> immediately detectable, as the former "NS" bit remains set.
> [ms] To me, this sort of discussion belongs into the document.
>
[BB] Although it's interesting to consider whether passive monitoring 
would be able to detect a difference between one version of a protocol 
and another, I think any discussion of that belongs in a draft about 
passive monitoring, or in mailing list discussion (as here). Not in a 
protocol spec.

We can't be expected to have to ensure that new protocols can be 
distinguished from old protocols by monitoring systems that haven't been 
properly programmed to look for the protocol negotiation during the 
handshake. If such a monitoring system is controlling something critical 
and it's not monitoring correctly, that is surely a safety issue with 
the monitoring system, not with the new protocol.

Having just been talking to a colleague who set up the monitoring 
systems for a mobile operator, the first and most obvious thing they do 
is look for the flow starts.




Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/