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-boun...@ietf.org on behalf of > miika.komu=40ericsson....@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 _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
