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

Robert Moskowitz <rgm@htt-consult.com> Sun, 05 April 2020 17:44 UTC

Return-Path: <rgm@htt-consult.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 B38A83A105A for <hipsec@ietfa.amsl.com>; Sun, 5 Apr 2020 10:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 5VAjmwQ07dbS for <hipsec@ietfa.amsl.com>; Sun, 5 Apr 2020 10:44:29 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 D056F3A1058 for <hipsec@ietf.org>; Sun, 5 Apr 2020 10:44:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id B1E0C62136; Sun, 5 Apr 2020 13:44:26 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lkc3FVuXE7uq; Sun, 5 Apr 2020 13:44:17 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 5426762123; Sun, 5 Apr 2020 13:44:15 -0400 (EDT)
To: Miika Komu <miika.komu=40ericsson.com@dmarc.ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>
References: <ca8f592b3aa5ab33221ce2ef31bf5d8970335052.camel@ericsson.com>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <3d656083-dbd1-30d0-2476-e34e2230b7ee@htt-consult.com>
Date: Sun, 5 Apr 2020 13:44:06 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <ca8f592b3aa5ab33221ce2ef31bf5d8970335052.camel@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/BktJKq0HGHAls55o6Hlkoy4CkDI>
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: Sun, 05 Apr 2020 17:44:33 -0000

I am in agreement with this approach.

It is consistent with everything we have done (and planning, see my HHIT 
draft) in HIP with DNS.

Robert Moskowitz

On 4/5/20 9:20 AM, Miika Komu 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