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

[Miika Komu <[e-mail]>]

Thanks Jeff,

your nits will be included in the next version.

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" <
> [e-mail] on behalf of 
> miika.komu=[e-mail]> 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
>     
> 
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec