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

[Robert Moskowitz <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec