Re: [Hipsec] DNS considerations in draft-ietf-hip-native-nat-traversal
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 +, 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 > 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 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 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 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/ 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/ 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/-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 > > >
Re: [Hipsec] DNS considerations in draft-ietf-hip-native-nat-traversal
Thanks Jeff, your nits will be included in the next version. ma, 2020-04-06 kello 13:44 +, 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 > 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 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 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 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/ 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/ 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/-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
Re: [Hipsec] DNS considerations in draft-ietf-hip-native-nat-traversal
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" 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 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 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 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 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/ 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/ 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/-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
