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

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 03 April 2020 09:49 UTC

Return-Path: <magnus.westerlund@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 785D83A15FA; Fri, 3 Apr 2020 02:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, 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 7zUM2NH3IvAx; Fri, 3 Apr 2020 02:49:05 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80075.outbound.protection.outlook.com [40.107.8.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 380ED3A15F9; Fri, 3 Apr 2020 02:49:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E+kBtYWgU64zFyFoNE30Le8irnBgWt3msQ43mLuYKd4QJg4HCTwOGjB/iIgaM70yf3OY7ehuYMz9dF59dJXgtQEcp8addIbnfKaE8EUGDuZ+56/fAu893axFs65XPrjOdEfGoz3QxijXczmInwiHqZUwdBqt8RfvUgkDsQikFoxIcySgHxjKkESdL0uW4hdk0cNWqyPNMoF1Wn8qGWW4oze8v5nyfZApGqM3byrkATwSDYiBqNUt8AVWEoM4wPJA6IE4KIY5EYXxYl7JFW+5K04Ar205wRzdOO/leTCu86BmRxRmy94l3bP4cNAAzpxocUfJAyh5LxaLP45MKJsI/w==
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=S1qLrgYagIRVvcG1GFBISVjfEcmBqsqxBi+77vhiqzI=; b=Mxt9jw8plgJZavyWz4i+5FB1QCYZoEeMNnA3vPyYsG0dOeBmqDsxQUOYctyKi6by1K1AZmlmMIw4KuHRFXdH9G/S0vccfR6TyYxsIYZMiTh6FkKKKF4ga6m45y3A5ZvO8X94Q/E7qNDSre5txwyzhV7o1l/tAuZ+JUiE6xlNGXRhtf4r3PdLuI4s5x77LVRc8BTcdd7QYFC7H9IXk5aX+Azn+UFL+zgywilJm/H/Ny0g2cXSqJl9NXIrHtzwyT/2sP9z9b3dLhKlO6P5XkswFljSn+umOUru+8Vx6n5lIisiWugrkj1OQzz2CNpVIFqbMYmQ7WEbFcU1RI+RL+dAKQ==
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=S1qLrgYagIRVvcG1GFBISVjfEcmBqsqxBi+77vhiqzI=; b=FFQxFHHpqPBAXPI09MTr9ZpOFdhQBeo25oHHFfbiNdfArJ4KQB/eDyft9BT3tutNDo4qDGCuK6tk7+rtd4Q8ImC8pO9MWXRXaj3Qi79HwtUef2sm42ieMGHIXMr0E4/eiATxGP2vYU6foaniLkZxexCAckXMViw142nNmn+P2gY=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (52.133.7.14) by HE1PR0702MB3786.eurprd07.prod.outlook.com (52.133.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.14; Fri, 3 Apr 2020 09:49:00 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2878.014; Fri, 3 Apr 2020 09:49:00 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "iesg@ietf.org" <iesg@ietf.org>, Miika Komu <miika.komu@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: AQHV8t5jpwo8AfrnzU6oGxAW8ZOYmqhma8gAgAC0MoCAADR7gA==
Date: Fri, 3 Apr 2020 09:49:00 +0000
Message-ID: <6d093953853f2062d0d31e23807f5116c4748ba3.camel@ericsson.com>
References: <158340648969.14566.11476213026719970345@ietfa.amsl.com> <ef83276e8b16e138f08b19747c54977989bcc1d8.camel@ericsson.com> <1ee7a7a90a590c89583c7ce3e6a61d07f63ad9b1.camel@ericsson.com>
In-Reply-To: <1ee7a7a90a590c89583c7ce3e6a61d07f63ad9b1.camel@ericsson.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [158.174.118.23]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7d21aa1c-1049-4041-0806-08d7d7b43c90
x-ms-traffictypediagnostic: HE1PR0702MB3786:|HE1PR0702MB3786:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0702MB37868B07E6B20E360F6C03C195C70@HE1PR0702MB3786.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0362BF9FDB
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(39860400002)(396003)(136003)(346002)(376002)(6486002)(66476007)(66446008)(2906002)(86362001)(5660300002)(6512007)(76116006)(81156014)(64756008)(36756003)(81166006)(66946007)(8936002)(66556008)(66616009)(110136005)(186003)(54906003)(44832011)(6506007)(8676002)(450100002)(966005)(478600001)(99936003)(4326008)(26005)(316002)(6636002)(71200400001)(2616005)(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: oRfeqlWEk1OrxH0SxaNIycDugy4PBx7IOM0nzduIaLLIpX+WLA9RK4661xMet60RIETd6kvLceaxn6v7C9UOoAWVdhkc1yKX4/7vH6EaoY23FMKLtYv79is0uZ1BeQqGBm4IWvK5574ZGWyodX+oHdQ86Fn58b8bTIm3rOnH5UkPO6elw5Injzcy/7JUbj0fvUaTiwZztT5iVFP+5dmf108fKGtVyYg0xPlrl3IBA+2OGTweb3K0nJ9vVDz4RCV1RFxHsfVWw39tD77h84JZKOTLmP/vaQqahOAjpgl5JwAXrm/ARRzGUzlzTUwJ8m54VmVv5hXfkYm4aJDlsON//D5lNLFt0FebBq3njSS32xs0pPfE0C8c5xrcE2ghtwltGOWwIcQzFPPKX+jANFLGg38l3RwxlyzkyhhvQKbIhL3eTFBE7qmglSQ6m9eG/ynFy4WEGLUsd3InEZ7ok092fhVzhq84iKg9SqjIxdHmulv09vrsod8fFl7XbiBFL+MPQw/agmMK6cKWE4J4HgQe3E0l0SFLxWtESVjdt/6xZQAL8OhTbtGncUirk3V0e+K2
x-ms-exchange-antispam-messagedata: Rfy6Jc+SzBU/Y0dKgKbJEfSAdnAlajq1eIIgn/yNA4hwtitFOrw/3BNHnOXGLJhR7Lohj9JBiFb/rw+t15JnvWHxBdLhLf8k/WOlBWW0PzmfRL0GaOcBbWV+iEPWSxXVGGS/yDzD8K2qeB9AzU2sxw==
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-TAgZMAwUvy0a08VISedQ"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d21aa1c-1049-4041-0806-08d7d7b43c90
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 09:49:00.5122 (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: L5zH3BezEvRwkENvc3YWm/zOoJuQgKf8JCM7AXxcFwb4zRSD1+yUgtpxx+twpIDsUV7YueDTh0IyJfcdZCaix0wOnlskO260MqldHNWm9A0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3786
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/ct7p_drrCXgZkR7ZENyKKR9zol4>
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: Fri, 03 Apr 2020 09:49:07 -0000

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. 

> 
> Btw, I would remove the following redundant statement in
> "RELAYED_ADDRESS and MAPPED_ADDRESS Parameters" section:
> 
> It is worth noting that UDP encapsulation of ESP reduces
> the MTU size of data plane by 8 bytes.

Ok.

Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------