Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

"Black, David" <David.Black@dell.com> Fri, 03 April 2020 20:06 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4FB3A093D for <tsvwg@ietfa.amsl.com>; Fri, 3 Apr 2020 13:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=dell.com header.b=EOR7HP0x; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=qzSO/RbK
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 fGjaSiVK11qU for <tsvwg@ietfa.amsl.com>; Fri, 3 Apr 2020 13:06:10 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 9C0023A0947 for <tsvwg@ietf.org>; Fri, 3 Apr 2020 13:06:10 -0700 (PDT)
Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 033Jl78o031322; Fri, 3 Apr 2020 16:06:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=XWNiWtlt7ylWEAiygFg8Ag8z6TSgTwJIbsygoLn5C7s=; b=EOR7HP0xwd5FK7JHiWPDbv//n7KwAdT8zWexI5hh58ZSm2wzqZ0WIG5cEy6quW9Sdw9W CZxsfGZK4R2Kcffja3bTmasMf2viLvHG2QGxF+jk3euTYcC6c7uIapmpqzDRDa76dwTL IslaKwLqmrcoOpsKVbYFwPtxVwkLJ5c4KlQDhTYoQ1kSMhmQXDVLNsSBjNhri/FQkKho xAxIcDwz2rsb9M9IB4jVvlaMo0O+pnmQ/I4RazNEd1IgHCxP41jrbIMtT1sqzghiG5BL 9lricfF+rW9Ew1J/OfYIu+xJgiPVIS4Zd6TRVeHFDxOyXkD7QYMcHEVbeQiUVBoIgSlE gw==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 3021n5uufg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 Apr 2020 16:06:09 -0400
Received: from pps.filterd (m0133268.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 033Jq4wt056227; Fri, 3 Apr 2020 16:06:09 -0400
Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2177.outbound.protection.outlook.com [104.47.57.177]) by mx0a-00154901.pphosted.com with ESMTP id 3020tu7u73-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Apr 2020 16:06:09 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mREOWVN8U6y5IN7Cwb8ydp/lUaDjv1P8EHG4SughozrhM15gE28leXg0mY3H7hV1PXzeP+Qid9gw6S/wxCTrqyvcLk3SQq19WrBIXS5K8pMMx60kiBHGQKp2CC/+5T6WJyLMcqMv0Dh80p9b3WUnvZnjDDf+/UpB9G5XhfjfgtPrulo3dM/BkqGmF8nEYFvHN8LeMvwKoIdaH4ZTO0kFMWQRPR1jK9UtBB5IP0eI+/lOH0wPKAUnOcsYJ73n2YgN56ISAnFy/L8Z2V/7u8wgK0PDskdRuPta7ohH/lWNG879vzQJ3SDUIprdlaQmp+/YFnJMqA0tdBJBNZuT4wa/0Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XWNiWtlt7ylWEAiygFg8Ag8z6TSgTwJIbsygoLn5C7s=; b=CuXqx9y4YkhMj3UsJAM5FksuGunuCj0kmImYRI0fiu5ZFsWrNeJ34TQ0/qHh/PqZMXPpmpjVCqdiRjQ+olSxQKBG3/9XPLMFKsgcFCJvNZ0pbAQz8IexmwALnJ6scBQMAbVECqxKEoSSvim4C3FJs38g2jVIUObuxcpZ+3UB4Ze7tyCZAr5eh7xNzti7ccaLpQ7zh31BbBVg7plrNhkCXNmlvmtUVX5QFI3RWTW/HFxU38Q5AW33nZOD0R09UjBJfnPGTOfepIh/0lIA+ul5B+2cJAI7x3l4a29jxyMCDonUcjmAhRuxPTA7PlbggvxJcVc1uMrW3pVNmFq2OlbbkQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XWNiWtlt7ylWEAiygFg8Ag8z6TSgTwJIbsygoLn5C7s=; b=qzSO/RbKQ4oF5au/h5evuCGJErN5eJeMsAELtq1sfeUndThtjwXJeIq/Cv66SL4eeTToegAOypwGskYHXy76UknbDNYpf1+FvARNDKKMIs47YlwdaeGsBniT2Qf4BQfpxS25cZSlVC60ASMlazwZSAe+B/MdJvB5AqnfWrbEQ7M=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3470.namprd19.prod.outlook.com (2603:10b6:208:18c::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Fri, 3 Apr 2020 20:06:07 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd%3]) with mapi id 15.20.2878.018; Fri, 3 Apr 2020 20:06:07 +0000
From: "Black, David" <David.Black@dell.com>
To: Tom Herbert <tom@herbertland.com>, tsvwg <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
Thread-Index: AQHWCdfN95tAuqnQEUqYW+PFgtwk/qhnvS9Q
Date: Fri, 03 Apr 2020 20:06:07 +0000
Message-ID: <MN2PR19MB4045652C80DB5348A5A3505F83C70@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <CALx6S345Ta5LjSkZ+XmNmH8dxKnM++VRCej2iGxfdUqDc+M-Jw@mail.gmail.com>
In-Reply-To: <CALx6S345Ta5LjSkZ+XmNmH8dxKnM++VRCej2iGxfdUqDc+M-Jw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-04-03T19:14:46.1597465Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [168.159.213.214]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cd9ab57d-7746-4cf5-7f4b-08d7d80a723f
x-ms-traffictypediagnostic: MN2PR19MB3470:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB3470CA713DAE6605BC16FB8183C70@MN2PR19MB3470.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0362BF9FDB
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(346002)(376002)(136003)(366004)(396003)(186003)(316002)(9686003)(4326008)(71200400001)(33656002)(81156014)(478600001)(8676002)(81166006)(26005)(8936002)(107886003)(6506007)(7696005)(110136005)(55016002)(86362001)(53546011)(66446008)(786003)(2906002)(76116006)(52536014)(66476007)(64756008)(66946007)(66556008)(5660300002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: juPTuIOxtm6/Drnjc11IYHbSyqPKbJFuOGEOB8jcAFXDA9yzfYTvGocAZWDpmaNi2DqFyZRIYAl6p3WbifYcdUtenEHHicMLM8u0crShtrEXwOwpoJaj+WsMoV2w0e0T/q47gk1NGyLRxjCLPu9G4m2mB8oQqkwzaXM3IcWVZcYqV4IplTSAG2vD6SWhXhoY/d5gClsixYar6ovzj6qezj/xU2tbqc8Yszv2Le0SDhourlHIYDLSYJ/eYY8II0VqsuwS6k1Oc39VqSXLMav1LsgB8F4xfKQRL56RD275Jd1Xf8rci+4X5MgpNizlOx9n6GlBehHefFDiTgN+tpc+5fqfTZUCjxwONPh29Jc4IHYMrZioSpyyxJIY+M5hKw3hUmEe96yBZvMNLQgeTRxvzdNu7hk/E3MGxSSZKeCc6Hi5hYgC9+8Us+pt6UtTtIzv
x-ms-exchange-antispam-messagedata: OXin0PyLqX3ivotecPXWx8agEN3YvdfX/AnRdzZpWS6YFQ2O1RZ+jSWG98niccMuPuJ1IoThQUp9JHSaVZTEtbW809Tdf3ic1W4JHqwS8Dj9lwtB/5hTSwDlSY4umuDRyxKWBWtKHUa0lM3901+jRQ==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cd9ab57d-7746-4cf5-7f4b-08d7d80a723f
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 20:06:07.3235 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sI54cNA+Tm7yGYSAQgB7dO1k1VRx3GA/lTO1mefavU+MCCpaoVI6uRKYTNsOK9bBl53yOw1YYsi9TXJj371lqQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3470
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-03_16:2020-04-03, 2020-04-03 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 impostorscore=0 malwarescore=0 phishscore=0 clxscore=1015 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004030159
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 impostorscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1015 spamscore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004030159
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/snGBQe9LBL-lZxGZ27KoSKfI1zw>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2020 20:06:14 -0000

Hi Tom,
[writing as draft shepherd]

[1]
> I don't understand this statement from the draft:
> 
> "The value of this information would be enhanced if the exposed
> information could be verified to match the internal state of the
> transport by observing the transport behaviour."
> 
> I assume this means that the network nodes would need to understand
> the internal state of transport protocols. How would this work?

Oops, that's not a good assumption - in 20/20 hindsight, the quoted
text should focus on protocol behavior rather than internal state.

Suggested revised text:

   The usefulness of this information would be enhanced if the exposed
   information could be verified to match the protocol's actual behavior,
   e.g., by observing whether the network traffic sent by the protocol
   is consistent with the exposed information in that traffic.

Beyond that, one could (partially) infer protocol state from observed
traffic behavior, but I don't think it's important to say that.

[2]
> >From the draft:
> 
> "An endpoint/protocol could choose to expose transport header
> information to optimise the benefit it gets from the network
> [RFC8558]."
> 
> There is also the possibility that the endpoints didn't expose
> transport layer information, but the network incorrectly thinks it
> did.  The network may simply misinterpret bits in packets as being
> transport layer information when in fact the data can be something
> completely different and unrelated. The canonical example of this is
> QUIC or any transport encapsulated in UDP payload.

That's actually an observation about transport-layer vs. network-layer
information exposure that would be better addressed slightly earlier in
the draft where both of those layers are discussed.

After the first paragraph in Section 6.1 (Exposing Transport Information
in Extension Headers) looks like a good place to make that observation.

After this paragraph:

   At the network-layer, packets can carry optional headers (similar to
   Section 5) that may be used to explicitly expose transport header
   information to the on-path devices operating at the network layer
   (Section 3.1.3).  For example, an endpoint that sends an IPv6 Hop-by-
   Hop option [RFC8200] can provide explicit transport layer information
   that can be observed and used by network devices on the path.

Add this paragraph:

   Network-layer optional headers explicitly indicate the information
   that is exposed, whereas more effort may be required for a network
   device to determine whether a packet contains a partially encrypted
   transport header.  A particular concern is UDP-encapsulated protocols
   because the UDP ports do not definitively indicate which protocol has
   been encapsulated, even though some protocols are the predominant
   usage of specific UDP destination ports (e.g., a packet sent to UDP
   port 4500 is highly likely to contain UDP-encapsulated IKE [RFC3948]
   or IKEv2 [RFC7296]).
   
Would that work?

Thanks, --David

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Tom Herbert
> Sent: Friday, April 3, 2020 12:49 PM
> To: tsvwg
> Subject: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi, a few comments.
> 
> I don't understand this statement from the draft:
> 
> "The value of this information would be enhanced if the exposed
> information could be verified to match the internal state of the
> transport by observing the transport behaviour."
> 
> I assume this means that the network nodes would need to understand
> the internal state of transport protocols. How would this work?
> 
> If the idea is that the exposed information is somehow verified with
> the endpoints that securely provide the information then maybe I
> understand that. But, if the idea is that intermediate nodes need to
> autonomously deduce the internal state themselves, I think that is
> problematic. Aside from all the known problems that stateful network
> devices have caused, there seems to be a circular dependency here.
> AFAIK the only way to deduce the internal state of a transport
> connection in the network would be by inspecting the exposed transport
> information, but this statement seems to be saying the exposed
> information can't be trusted unless the internal state has been
> deduced. Am I missing something?
> 
> >From the draft:
> 
> "An endpoint/protocol could choose to expose transport header
> information to optimise the benefit it gets from the network
> [RFC8558]."
> 
> There is also the possibility that the endpoints didn't expose
> transport layer information, but the network incorrectly thinks it
> did. The network may simply misinterpret bits in packets as being
> transport layer information when in fact the data can be something
> completely different and unrelated. The canonical example of this is
> QUIC or any transport encapsulated in UDP payload. Per, RFC7605,
> transport port numbers only have meaning at end points. So for example
> a network device may think a packet with UDP destination port 80 is
> QUIC, when in fact it is something completely different, hence the
> network device may misinterpret the payload as being QUIC. I suspect
> it's unlikely that this situation will benefit the user, and more
> likely the network would not treat such packets well. There's been
> some work on this problem, like magic numbers in SPUD or analysis to
> mitigate the effects of misinterpretation like done for QUIC spin bit,
> but I don't believe anyone has proposed a general solution (other than
> moving the necessary information into the network layer and have
> intermediate nodes stop doing DPI).  I believe this problem should be
> mentioned in the draft with a reference to RFC7605 .
> 
> Tom