Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)

Miika Komu <miika.komu@ericsson.com> Sun, 05 April 2020 13:13 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8923A089B; Sun, 5 Apr 2020 06:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 4Cahc5E2Th2s; Sun, 5 Apr 2020 06:13:15 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130075.outbound.protection.outlook.com [40.107.13.75]) (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 AE5403A0896; Sun, 5 Apr 2020 06:13:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bb3Toy/tj8U82p9PI7ZOOeK9mUd3w1eVew8w9vXK33h3ZiH2OWV7bxEFPy0oZj0mframaoHDygr549D722VY2zZDvpPjC2OMABQX04M8xO/4yCH6j1u/qYYcoGzkn98I4G9StGxuVqCevF5MO6RRvJ3PrX04D/aEvv1rQGfiOWOR1S8UXJd0VbDk0Gs7FF0smNYI1rwGkvqkQj6FzcCiInCt2qepb84OD5n9IrDzipWAHDXQkpYa3YI5U+eQKohbRPQUM960nkgNRvO3g+o3PRAYXHC8qEFEIta4L4wcDTRkZlJdw6pGr4wcRauTNFucQ8EqDv6JfMnAnu4nKc/IvQ==
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=zMwOHswzHLUBiwmQhwzlstc3HsTPFJcp1PJmBNrviIw=; b=LvPGOVixMm09sP3eswQQr0Z84D+ZrfssWTd1hlHJMgyFJ+lFUMbOY9Z0G1UrTckjLy3znW5E+Gj9d3uuZ0XnzU6gxe2gq2lDGIuc3MgrgT0lkS0ybkXH3GhYf2yIF6E7OfTZqPT9nSmfbnbbvY+S4Hmru+YQkjpsDvpieX7vuwJ+tIeE8e0aNja4arfdwR2gTYzZT6fK1E7hjQhDlr/5jG9tStN9meCYGwpx3lZvYrOLfXuPQvSIG8XSP47+LKIKZ7ybZyit2OlSZGNvh8y28eSuxyIaDs+CXN3lSEoIAuDtU88DdpsRFH5BdGkNGoEEGImLKbLEgSY1pM4UH7qO1Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zMwOHswzHLUBiwmQhwzlstc3HsTPFJcp1PJmBNrviIw=; b=JXYDLshqHhyGZm/00GzdepKEHtdDsCbLvyuQRwcPQfdAh3fKXktUNItMPpuIQyFR5z9WrVdkm+u2ziacSd1rPNtMuKhOtWho3G86BC8rv6X3W1P9uTnKQvMIgDjdOTBsGQ3FG1gFdI0lzfjP1R9m91S1B1GqEExBxRBddUX30oM=
Received: from AM0PR07MB3876.eurprd07.prod.outlook.com (52.134.81.144) by AM0PR07MB4611.eurprd07.prod.outlook.com (52.135.151.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.13; Sun, 5 Apr 2020 13:13:07 +0000
Received: from AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::5c87:eedc:6e84:fd4]) by AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::5c87:eedc:6e84:fd4%7]) with mapi id 15.20.2900.012; Sun, 5 Apr 2020 13:13:07 +0000
From: Miika Komu <miika.komu@ericsson.com>
To: "iesg@ietf.org" <iesg@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "draft-ietf-hip-native-nat-traversal@ietf.org" <draft-ietf-hip-native-nat-traversal@ietf.org>, "hip-chairs@ietf.org" <hip-chairs@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "hipsec@ietf.org" <hipsec@ietf.org>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)
Thread-Index: AQHV8t5gg3Zvxq1PeEaWx2XZsfEZi6hma8SAgAC0NICAADR+AIADXbGA
Date: Sun, 5 Apr 2020 13:13:07 +0000
Message-ID: <408e58bf1969e7a538e0ee545dd69ff694d81bf0.camel@ericsson.com>
References: <158340648969.14566.11476213026719970345@ietfa.amsl.com> <ef83276e8b16e138f08b19747c54977989bcc1d8.camel@ericsson.com> <1ee7a7a90a590c89583c7ce3e6a61d07f63ad9b1.camel@ericsson.com> <6d093953853f2062d0d31e23807f5116c4748ba3.camel@ericsson.com>
In-Reply-To: <6d093953853f2062d0d31e23807f5116c4748ba3.camel@ericsson.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1
authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com;
x-originating-ip: [88.148.205.35]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cb9f6902-d9d8-4538-4b00-08d7d963154c
x-ms-traffictypediagnostic: AM0PR07MB4611:|AM0PR07MB4611:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM0PR07MB461113A71890B61F930584B2FCC50@AM0PR07MB4611.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03648EFF89
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3876.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(136003)(346002)(376002)(366004)(396003)(966005)(8676002)(36756003)(6506007)(6636002)(2906002)(81156014)(5660300002)(450100002)(478600001)(81166006)(71200400001)(316002)(186003)(8936002)(91956017)(66446008)(4326008)(66556008)(110136005)(26005)(86362001)(44832011)(6486002)(64756008)(66946007)(76116006)(2616005)(66476007)(6512007)(54906003)(99106002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Ir7Uu+MC5Q4wPdAh8gybzyTnTXLiCvul6urirHafOb3ujz6em87bl7QOx0dllmPFRhDLW5/08vCvffI4fYXdMHKCrwt/Q9sNIQh633Tdyg/c3wmSAqcpmyBkCnWyJWCIhBVAF9JapSiqJikXZL7yYlg02ORdMeinKhQ8k/0QJYCLvCAY41rgbHAobH4lTrwld4Ek1kDgbOVJe55WeDhCBtEgdavvku7zuBpmjZt5OQBNsrQrkDhoWoKlnvWINqbib9HCXVkEgUYoOSCFrHqwpusiIZCp3HYczKKrOngWuIEIhCnz5deRSMTIVr70tyU98+m8h8J7RlKNipcT9DXEP62pw84Wq/TnUy1OTSdyp7aOv7XNPiUGbDwXZL7lk1Uxw6bFKwBrLwNSJRzsxNlmRgLF/8DM0YlgyQ5NlRcD2QhLI1RO056jrE/OSDYa0173zdimfc3lq4Wdb952nKxhUWiYUre4zaF1NoRDzg4dt11JTfbktaXlLrUFjrWlfosCwHyJgpYiIM0DTwA16pu1zmHXnaYub50F2eByliXyHrbmvahVjXrfdpSvgDjGu9xY
x-ms-exchange-antispam-messagedata: 9m1aLMmg/3896tjeKLICi2yj3HysRqanipfBJfwVLXXGssS/stPD7TYPkHQL6qtgycZo2Ud2UM4cUv7L4r+in1mjIiwsD5lwCN3qcZ3qZeqZAuB6siWmg06qkgsrYKimpHPD5Y7UZFkuwIwtdsGLSg==
Content-Type: text/plain; charset="utf-8"
Content-ID: <700D1E76E3664648964F8782554DEC0B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cb9f6902-d9d8-4538-4b00-08d7d963154c
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2020 13:13:07.7696 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TZonAO8HX7gN4FHi0YQIduIqmOnUvj6bozCh0llLnQc/t74PwhY4HmhQIfjCGziljZ0hqigjY8Glzk/O+BOJFw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4611
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/7Gc8g-2derz8nTCwpXDce7z84VA>
Subject: Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Apr 2020 13:13:18 -0000

Hi Magnus,

pe, 2020-04-03 kello 09:49 +0000, Magnus Westerlund kirjoitti:
> Hi, 
> 
> See below.
> 
> On Fri, 2020-04-03 at 06:41 +0000, Miika Komu wrote:
> > Hi Magnus,
> > 
> > to, 2020-04-02 kello 22:56 +0300, Miika Komu kirjoitti:
> > > 
> > > > 4. MTU impact of NAT traversal.
> > > > 
> > > > Section 5.1 states
> > > > "It is worth noting that UDP encapsulation of HIP packets
> > > > reduces
> > > > the
> > > >    Maximum Transfer Unit (MTU) size of the control plane by 12
> > > > bytes."
> > > > 
> > > > There is also a similar text in Section 5.11:
> > > > 
> > > >    It is worth noting that UDP encapsulation of ESP reduces the
> > > > MTU
> > > > size
> > > >    of data plane by 8 bytes.
> > > > 
> > > > I think the document needs a discussion and impact on MTU which
> > > > this
> > > > NAT
> > > > traversal has on the HIP packets being sent. - First of all
> > > > there
> > > > appears to be
> > > > more packet expansions happening in some cases, for example the
> > > > RELAY_HMAC
> > > > option expands packets on one leg. - Secondly, HIP requires IP
> > > > fragementation
> > > > support, however IP fragmentation through NAT is commonly not
> > > > working. Thus an
> > > > HIP packet being UDP encapsulated that results in packet
> > > > exceeding
> > > > MTU will
> > > > likely end up in an MTU black hole on path.
> > > > 
> > > > The addition of the NAT traversal encapsulation actually
> > > > increases
> > > > the need for
> > > > MTU discovery or care in MTU handling by the HIP initiator. I
> > > > think
> > > > there need
> > > > to be discussion of that in the document.
> > > 
> > > I am stil iterating some text on this, I hope Jeff Ahrenholz can
> > > help
> > > with this.
> > 
> > I got text from Jeff Ahrenholz and Robert Moskowitz:
> > 
> > Section 5.2
> > 
> > replaced this:
> > 
> > It is worth noting that UDP encapsulation of HIP packets reduces
> > the
> > Maximum Transfer Unit (MTU) size of the control plane by 12 bytes.
> > 
> > with:
> > 
> > UDP encapsulation of HIP packets reduces the Maximum Transfer Unit
> > (MTU) size of the control plane by 12 bytes (8-byte UDP header plus
> > 4-byte zero SPI marker), and the data plane by 8 bytes.  This
> > encapsulation overhead increases the need for MTU discovery.  A HIP
> > host SHOULD have the option to enable ICMP path MTU discovery
> > (PMTUD)
> > [RFC1063] [RFC8201].  Otherwise, support for IP fragmentation is
> > required, which may not be commonly supported through NATs.  When
> > HIP
> > encapsulation is implemented using a virtual tunneling interface,
> > consider using a reduced MTU (e.g. 1400) by default.  Additional
> > HIP
> > relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP,
> > etc., further increase the size of certain HIP packets.  It is
> > worth
> > noting that further HIP extensions can trim off 8 bytes in the ESP
> > header by negotiating implicit IV support in the ESP_TRANSFORM
> > parameter as described in [RFC8750].
> > 
> > Does this address your concerns?
> 
> I think the recommendation for virtual interface is a reasonable one
> based on
> the constraints. However, I think: 
> 
> A HIP
> > host SHOULD have the option to enable ICMP path MTU discovery
> > (PMTUD)
> > [RFC1063] [RFC8201].  Otherwise, support for IP fragmentation is
> > required, which may not be commonly supported through NATs.
> 
> maybe should be reformulated. ICMP messages are sometimes dropped in
> NATs,
> despite recommendations to support at least the TOO BIG messages. And
> I think if
> ICMP either is not working or not enabled, indicating that IP
> fragmentation
> could be a possible way to get thingst to work, appears even less
> likely to work
> as IP fragmentation handling in NATs becomes resource demanding due
> to all per
> packet state needed to be maintained, as only the first fragement
> contains the
> UDP header allowing the lookup of the translation record. 
> 
> Maybe it can be made clearer by restructuring the text so that it
> says this: 
> 
> - A HIP host SHOULD implement ICMP message handling to support MTU
> discovery per
> [RFC1063] [RFC8201]. 
> - Reliance on IP fragmentation is unlikely to be a viable strategy
> through NATs
> so if ICMP MTU discovery is not working MTU realted path black holes
> may occur. 
> - A mitigation is to constrain the MTU, especially for virtual
> interfaces to
> expected to be safe MTU values, e.g. 1400 bytes for underlying
> interfaces that
> support 1500 bytes MTU.
> - (to include something realted to below discussion consider this
> bullet also,
> assumes that PLP MTUD actually can be implemented in HIP relay rather
> simply):
> Implement PLPMTUD [draft-ietf-tsvwg-datagram-plpmtud] in HIP to find
> a working
> path MTU without unnecessary constraining that size.  
> 
> Has anyone looked at implementing 
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/
> (document is
> in IESG evaluation) style path MTU discovery between the HIP client
> and the
> relay? Becasue I think that would be the best to actually run a HIP
> level path
> MTU discovery, so that the HIP client can set its MTU to path minus
> overhead and
> including any for occasional messages that are required to be
> included when
> carrying useful payload. If HIP has a padding option, then I would
> expect that
> HIP has everything necessary to implement working probe messages that
> can used
> by the above draft. 
> 
> To be clear, I don't expect that you write up and include such a one
> in this
> specification. At most you could consider an informative statement
> that an a
> client implementor could consider to implement such a mechanism. 
> 
> I would more hope that someone in the WG considers to actually write
> a draft for
> a specification for PLP MTU discovery for HIP, which hopefully are a
> rather
> short document, but can enable a HIP based virtual interface to set
> well working
> MTU without unnecessary constraining the MTU. 

I tried to merge your feedback with text from Jeff and Robert, so now
it is as follows:

UDP encapsulation of HIP packets reduces the Maximum Transfer Unit
(MTU) size of the control plane by 12 bytes (8-byte UDP header plus
4-byte zero SPI marker), and the data plane by 8 bytes.  Additional
HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP,
RELAY_UDP_ESP, etc., further increase the size of certain HIP
packets.  In regard to MTU, the following aspects need to be
considered in an implementation:

o  A HIP host SHOULD implement ICMP message handling to support path
   MTU discovery (PMTUD) discovery as described in [RFC1063]
   [RFC8201]

o  Reliance on IP fragmentation is unlikely to be a viable strategy
   through NATs.  If ICMP MTU discovery is not working, MTU related
   path black holes may occur.

o  A mitigation strategy is to constrain the MTU, especially for
   virtual interfaces, to expected safe MTU values, e.g., 1400 bytes
   for the underlying interfaces that support 1500 bytes MTU.

o  Further extensions to this specification may define a HIP-based
   mechanism to find a working path MTU without unnecessary
   constraining that size using Packetization Layer Path MTU
   Discovery for Datagram Transports
   [I-D.ietf-tsvwg-datagram-plpmtud].  For instance, such mechanism
   could be implemented between a HIP Relay Client and HIP Relay
   Server.

o  It is worth noting that further HIP extensions can trim off 8
   bytes in the ESP header by negotiating implicit IV support in the
   ESP_TRANSFORM parameter as described in [RFC8750].