Re: [Hipsec] DNS considerations in draft-ietf-hip-native-nat-traversal

Miika Komu <miika.komu@ericsson.com> Thu, 09 April 2020 08:16 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 D1C713A0E72 for <hipsec@ietfa.amsl.com>; Thu, 9 Apr 2020 01:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.258
X-Spam-Level:
X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ZZY0t6Qj4wMG for <hipsec@ietfa.amsl.com>; Thu, 9 Apr 2020 01:16:01 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70041.outbound.protection.outlook.com [40.107.7.41]) (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 85E973A0E60 for <hipsec@ietf.org>; Thu, 9 Apr 2020 01:15:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZtpB3YqNz/n/Gf1GIN5fIggfuH9HXioPe0ISL+RO2uHX0B5z7VNZGP1XvWpZG/MqiJJ7IBsRQpnNoCJ09fGoxCErbjeGpicsTsrHbfY0q8zo6mHTP+3gHo5XyVSMJMrwBPW7Ntl4XvHJkzBdn650KfFLZ+SOUZAxhaMqxWZLALukP/ixvWlyg09npEGUG2RxRb6V439ozrS5v7zHXSf7KzqpXtXbGDZj0AfDS8ku1FpQIevQbc2BZXwI2bUcsU7dMmRT4U9Upy3B6NV9Nfdg+lHhZxY6snXA8ndtxsNdMDV8YrlAD3DECMFq4SFES0WaQvtYhuTIG9Ssy+N2uC5sRg==
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=GyOIeISuB/kVPI0aqR0XFyrpGVuIcdZBZdfj4FCllBo=; b=eh9NVHk2aUlb3q/Ya0GtL09LbWQFCOJhaENvgBbZm1Axvelnw+W378jYip9vkJX+5O0tKwarokNZm8fKRK705QRJtgktGCCgxuhOiASoixRh3TGWBPGEEq2iS1SLdt/BmOTYdpTm54dNu9FyE2Ofy5Y+MQ5fNC6txGh5IyEgUP0ww0KMv4wRHMpnW9fJPAfMjcDsh3HzzOyV6kaZQAsOKdLioL9BpnXwiUotkIDgDCduW79bVZ2k5gUfxzm4mJlwiuEFWSJr5ASYvtsYk5RDH8Hh1SFoCeAckonrKEk12XqcpJXq+uLq8DdUAC4u3ZuA2xtLg1ZNf95lS9xzXKo1Kw==
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=GyOIeISuB/kVPI0aqR0XFyrpGVuIcdZBZdfj4FCllBo=; b=tIwwzT2C5Q44gs60lkN+XDkCmF2sAaRUuHT374DtPSZAHzN4x7kvCqrRuRyixhAW9607eJStNpmOKlD3TubuvSzhgkTrj/A6AEKtC+ndAKjWcTnDRcksC6nHeYPKF7j09cgRqHUgdd1HpA+DDY8taB/sSbBUF7OFJTfCJ0A9HNY=
Received: from AM0PR07MB3876.eurprd07.prod.outlook.com (2603:10a6:208:44::16) by AM0PR07MB5602.eurprd07.prod.outlook.com (2603:10a6:208:ff::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.12; Thu, 9 Apr 2020 08:15:51 +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.015; Thu, 9 Apr 2020 08:15:51 +0000
From: Miika Komu <miika.komu@ericsson.com>
To: "miika.komu=40ericsson.com@dmarc.ietf.org" <miika.komu=40ericsson.com@dmarc.ietf.org>, "j.ahrenholz@Tempered.io" <j.ahrenholz@Tempered.io>, "hipsec@ietf.org" <hipsec@ietf.org>
Thread-Topic: [Hipsec] DNS considerations in draft-ietf-hip-native-nat-traversal
Thread-Index: AQHWDBl6+EF13lTjuk+JiMyOEPIlOqhwdfuA
Date: Thu, 9 Apr 2020 08:15:51 +0000
Message-ID: <80a8d1d013b215a66a04bc0a08ebe6c8d5f1d8f6.camel@ericsson.com>
References: <BE5944AA-CC27-4D07-99CD-5A5B16B19369@tempered.io>
In-Reply-To: <BE5944AA-CC27-4D07-99CD-5A5B16B19369@tempered.io>
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: b4c61cad-f6a5-4d4f-a853-08d7dc5e377e
x-ms-traffictypediagnostic: AM0PR07MB5602:
x-microsoft-antispam-prvs: <AM0PR07MB5602FF4EC8C4F674D0104315FCC10@AM0PR07MB5602.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4941;
x-forefront-prvs: 0368E78B5B
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)(136003)(366004)(376002)(396003)(346002)(39860400002)(316002)(81156014)(8936002)(8676002)(478600001)(71200400001)(86362001)(91956017)(76116006)(2616005)(6486002)(44832011)(5660300002)(966005)(81166007)(2906002)(36756003)(110136005)(64756008)(66946007)(26005)(186003)(66446008)(66556008)(66476007)(6506007)(6512007)(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: hp4Gje0jBqBRt8Trs39l4t611EoLPr5oOPVELkqIFBWxIb81kUmoEnf05BD04IdoXd2GavVSA3ctTWCYUe5GkTPGv3jtBj/4r3KWaQy44vSYEhEjL8Vwkcefi7CPDLkPJiVUPzblEV+/YgwjzFZPh42fUNOvLH/jQ2N7tGOP8PyqNPYiXkrArKrU5mwaZoABnMl6Tdkrin1vxu0hRrJdGNoJ3yJdCFJwpSHrWgIHsXBcr2aeIqG3WRII9AEZGHVXkg3VEWdmM7XXvTLsLjtAxxEFSHOIAmAUHeml5Ze/6/3exm0L67y3WpQFoy3TMfsKcYaQt5vn6ECkOA/U7a0OYoILIFtEH4w0mYNEUPRi52UTMwH9yJj53wwfykeQm4i/O5MbnlVANgXCDD8UP5hm4PyRo0Iglq7Wg1G8vcZc8SsRBMdgLUTLhBmB5QSP2ikgPVkYUmNLPe4UwN3DdwTqqAVYDzjolrpIpL4Exn/fXkWX/DzI5W9vAIV1WILuqu5rfH36N/nIrCrI2x0y8UBQUkje/17F10lNiDKiMjMrIPATBvJhYmPT9LgKcA5QxbHS
x-ms-exchange-antispam-messagedata: CMSfZRtONB0gdtpdpRKkeardMoG9yE9SEDPF+FtX/HhR/dYhiYAnF52DoyW4z4mpJsUcZYbpMXZIkzcY6D8N2A/TF/es21hjYVkOLbzv3E6a1ENzdNXtfetFjf3VH4blneOq91K2vhweQKwFQ2neRg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <694893C298011C42B779B603A77DD339@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b4c61cad-f6a5-4d4f-a853-08d7dc5e377e
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 08:15:51.1728 (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: GVbbPTFMbaqdyYqKHVsVkKY931sOCzQtD87JfWz/PPeLpnwJDgPvnDi2T+fOtYDL6wSu35d5zBWH41k62sUb9Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5602
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/4AhMBrFn555jYfJGSLM43r2nlsM>
Subject: Re: [Hipsec] DNS considerations in draft-ietf-hip-native-nat-traversal
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: Thu, 09 Apr 2020 08:16:08 -0000

Hi,

I noticed that the new proposed text on DNS is handling things
differently than this part in RFC5770:

https://tools.ietf.org/html/rfc5770#appendix-B

So I would suggest that we would update RFC5770 appendix B in the
native NAT traversal draft and replace it with the new DNS text. Would
you be ok with this?

ma, 2020-04-06 kello 13:44 +0000, Jeff Ahrenholz kirjoitti:
> Miika,
> Looks good to me. I like how the distinction between RVS and Control
> Relay Server  is spelled out.
> 
> Just a couple of nits:
> s/an HIP/ a HIP/
> s/the the A/the A/
> 
> -Jeff
> 
> On 4/5/20, 6:20 AM, "Hipsec on behalf of Miika Komu" <
> hipsec-bounces@ietf.org on behalf of 
> miika.komu=40ericsson.com@dmarc.ietf.org> wrote:
> 
>     Hi,
>     
>     during IESG review Magnus Westerlund asked about DNS support in
> draft-
>     ietf-hip-native-nat-traversal, so I added the the text below to
> draft-
>     ietf-hip-native-nat-traversal. Does it seem ok for the WG?
>     
>     Appendix E.  DNS Considerations
>     
>     [RFC5770] did not specify how an end-host can look up another
> end-
>     host via DNS and initiate an UDP-based HIP base exchange with it,
> so
>     this section makes an attempt to fill this gap.
>     
>     [RFC8005] specifies how an HIP end-host and its Rendezvous server
> is
>     registered to DNS.  Essentially, the public key of the end-host
> is
>     stored as HI record and its Rendezvous Server as A or AAAA
> record.
>     This way, the Rendezvous Server can act as an intermediary for
> the
>     end-host and forward packets to it based on the DNS
> configuration.
>     Control Relay Server offers similar functionality as Rendezvous
>     Server, with the difference that the Control Relay Server
> forwards
>     all control messages, not just the first I1 message.
>     
>     Prior to this document, the A and AAAA records in the DNS refer
>     either to the HIP end-host itself or a Rendezvous Server
> [RFC8005],
>     and control and data plane communication with the associated host
> has
>     been assumed to occur directly over IPv4 or IPv6.  However, this
>     specification extends the records to be used for UDP-based
>     communications.
>     
>     Let us consider the case of a HIP Initiator with the default
> policy
>     to employ UDP encapsulation and the extensions defined in this
>     document.  The Initiator looks up the FQDN of a Responder, and
>     retrieves its HI, A and AAAA records.  Since the default policy
> is to
>     use UDP encapsulation, the Initiator MUST send the I1 message
> over
>     UDP to destination port 10500 (either over IPv4 in the case of a
> A
>     record or over IPv6 in the case of a AAAA record).  It MAY send
> an I1
>     message both with and without UDP encapsulation in parallel.  In
> the
>     case the Initiator receives R1 messages both with and without UDP
>     encapsulation from the Responder, the Initiator SHOULD ignore the
> R1
>     messages without UDP encapsulation.
>     
>     The UDP encapsulated I1 packet could be received by three
> different
>     types of hosts:
>     
>     1.  HIP Control Relay Server: in this case the A/AAAA records
> refers
>         to a Control Relay Server, and it will forward the packet to
> the
>         corresponding Control Relay Client based on the destination
> HIT
>         in the I1 packet.
>     
>     2.  HIP Responder supporting UDP encapsulation: in this case, the
> the
>         A/AAAA records refers to the end-host.  Assuming the
> destination
>         HIT belongs to the Responder, it receives and processes it
>         according to the negotiated NAT traversal mechanism.  The
> support
>         for the protocol defined in this document vs [RFC5770] is
>         dynamically negotiated during the base exchange.  The details
> are
>         specified in Section 4.3.
>     
>     3.  HIP Rendezvous Server: this entity is not listening to UDP
> port
>         10500, so it will drop the I1 message.
>     
>     4.  HIP Responder not supporting UDP encapsulation: the targeted
> end-
>            host is not listening to UDP port 10500, so it will drop
> the I1
>            message.
>     
>     The A/AAAA-record MUST NOT be configured to refer to a Data Relay
>     Server unless the host in question supports also Control Relay
> Server
>     functionality.
>     
>     It also worth noting that SRV records are not employed in this
>     specification.  While they could be used for more flexible UDP
> port
>     selection, they are not suitable for end-host discovery but
> rather
>     would be more suitable for the discovery of HIP-specific
>     infrastructure.  Further extensions to this document may define
> SRV
>     records for Control and Data Relay Server discovery within a DNS
>     domain.
>     _______________________________________________
>     Hipsec mailing list
>     Hipsec@ietf.org
>     https://www.ietf.org/mailman/listinfo/hipsec
>     
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec