Re: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-fast-mobility-03.txt
Jeff, Thanks for the feedback. After Passover, I will incorporate what I pull out of this. Bob On 4/6/20 1:51 PM, Jeff Ahrenholz wrote: Bob, Brief review below... I have updated the hip-fast-mobility draft. I welcome review. It will be used in an upcoming DRIP N-RID secure transport draft that will also include secure C2 transport. General comments: - Overall I think the draft looks good, it is a short read and quite straightforward. The TLDR: 1) include VIA_RVS more often (always in R1/I2), so peers always know how to reach you, 2) don't wait for complete address verification for using an address 3) piggyback upper layer data when possible - What about IPv4? There is no mention of it. And no extension header field like IPv6. - Did you consider the Credit-Based Authorization technique in section 3.3.2 of RFC 8046? You could maybe mention in this draft that it could optionally be used here? (Plays well / same concept as the send-before-verified.) Section 5.4.1 "the datagram is sent separately after receipt of the HIP UPDATE from Host B." This implies buffering packets after you've sent an UPDATE but waiting for UPDATE-ACK; we almost need a new association state "moving" because how long will you wait and buffer packets? What if the UPDATE-ACK is lost or not sent -- need to tear down? In practice, sometimes we're seeing dropped packets during mobility (depends on how quickly host can acquire a new address after losing the old address). Also we recently removed the initial-packet-embargo from our implementation (buffering packets while waiting for BEX to complete) as the complexity wasn't warranted (e.g. upper layers typically retransmit; packets likely to be stale.) Consider also switching interfaces, which may have differing MTUs (e.g. cellular/Ethernet failover.) Section 8 Security Considerations: Adding the VIA_RVS parameter to more packets -- any security considerations, since this is typically outside the signature? RFC 8004 indicates "The main goal of using the VIA_RVS parameter is to allow operators to diagnose possible issues" but here you're suggesting to use the address during shotgunning. Below are some editorial nits: Section 5.1 consider replacing: "An implementation may be able to adjust the transport window size downward so that the higher layer could still fill it and the whole piece then still fit within the MTU." with: "An implementation may be able to adjust the transport window size downward so that the higher layer could fit its data plus the UPDATE payload within the MTU." 5.2 s/others RVS/other's RVS/ 5.3 and 5.4 s/of new address/of a new address/ 5.5.1 and 5.5.2 s/wait from HIP UPDATE/wait for HIP UPDATE/ 7. IANA Considerations there is no PAYLOAD_MIC used here -Jeff ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-fast-mobility-03.txt
Bob, Brief review below... > I have updated the hip-fast-mobility draft. > > I welcome review. > > It will be used in an upcoming DRIP N-RID secure transport draft that will > also include secure C2 transport. General comments: - Overall I think the draft looks good, it is a short read and quite straightforward. The TLDR: 1) include VIA_RVS more often (always in R1/I2), so peers always know how to reach you, 2) don't wait for complete address verification for using an address 3) piggyback upper layer data when possible - What about IPv4? There is no mention of it. And no extension header field like IPv6. - Did you consider the Credit-Based Authorization technique in section 3.3.2 of RFC 8046? You could maybe mention in this draft that it could optionally be used here? (Plays well / same concept as the send-before-verified.) Section 5.4.1 "the datagram is sent separately after receipt of the HIP UPDATE from Host B." This implies buffering packets after you've sent an UPDATE but waiting for UPDATE-ACK; we almost need a new association state "moving" because how long will you wait and buffer packets? What if the UPDATE-ACK is lost or not sent -- need to tear down? In practice, sometimes we're seeing dropped packets during mobility (depends on how quickly host can acquire a new address after losing the old address). Also we recently removed the initial-packet-embargo from our implementation (buffering packets while waiting for BEX to complete) as the complexity wasn't warranted (e.g. upper layers typically retransmit; packets likely to be stale.) Consider also switching interfaces, which may have differing MTUs (e.g. cellular/Ethernet failover.) Section 8 Security Considerations: Adding the VIA_RVS parameter to more packets -- any security considerations, since this is typically outside the signature? RFC 8004 indicates "The main goal of using the VIA_RVS parameter is to allow operators to diagnose possible issues" but here you're suggesting to use the address during shotgunning. Below are some editorial nits: Section 5.1 consider replacing: "An implementation may be able to adjust the transport window size downward so that the higher layer could still fill it and the whole piece then still fit within the MTU." with: "An implementation may be able to adjust the transport window size downward so that the higher layer could fit its data plus the UPDATE payload within the MTU." 5.2 s/others RVS/other's RVS/ 5.3 and 5.4 s/of new address/of a new address/ 5.5.1 and 5.5.2 s/wait from HIP UPDATE/wait for HIP UPDATE/ 7. IANA Considerations there is no PAYLOAD_MIC used here -Jeff ___ 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
[Hipsec] HIP home stretch and new work for DRIP
HIPsters: Miika and I have been working away to get NAT-traversal and DEX through the IESG and on to last call. We are close That being said, hopefully you have noticed what is going on in the DRIP workgroup. In My Highly Biased Opinion (IMHBO), and what is an Opinion, but a bias... HITs are the only mechanism around that stand a chance to meet the constraints of Remote ID and provide trust. Others, with enough hand-waving and infrastructure, can work for some groups of UAS. None can work for all but the smallest UA that only support receive RF. That bias said, Stu, Adam, and I have been busy putting together a number of drafts over in DRIP and a number here which open the question of rechartering HIP to meet the needs of DRIP. Besides the HIP drafts, and the 'orphaned' ORCHID draft, there are also new ESP transforms to consider. Do we need to updated 7402 of RFC 8750? What about a new NIST lightweight cipher like Keyak (see new-crypto draft)? Or do Jeff and I, as the HIP IANA experts just update the HIP registry with these transforms for ESP? (well none assigned YET for Keyak, etc.) Please voice your positions on these points so we can get things moving going into April. Bob ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)
Hi, I think the below text looks good. If you are reasonably confident that HIP supports the capabilities required for implementing PLP MTUD requirements then I think that pargraph is good hint. So I believe I will have no issues with clearing when a document with the discussed updates are made available. Thanks Magnus On Sun, 2020-04-05 at 13:13 +, Miika Komu wrote: > Hi Magnus, > > > I tried to merge your feedback with text from Jeff and Robert, so now > it is as follows: > > UDP encapsulation of HIP packets reduces the Maximum Transfer Unit > (MTU) size of the control plane by 12 bytes (8-byte UDP header plus > 4-byte zero SPI marker), and the data plane by 8 bytes. Additional > HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, > RELAY_UDP_ESP, etc., further increase the size of certain HIP > packets. In regard to MTU, the following aspects need to be > considered in an implementation: > > o A HIP host SHOULD implement ICMP message handling to support path >MTU discovery (PMTUD) discovery as described in [RFC1063] >[RFC8201] > > o Reliance on IP fragmentation is unlikely to be a viable strategy >through NATs. If ICMP MTU discovery is not working, MTU related >path black holes may occur. > > o A mitigation strategy is to constrain the MTU, especially for >virtual interfaces, to expected safe MTU values, e.g., 1400 bytes >for the underlying interfaces that support 1500 bytes MTU. > > o Further extensions to this specification may define a HIP-based >mechanism to find a working path MTU without unnecessary >constraining that size using Packetization Layer Path MTU >Discovery for Datagram Transports >[I-D.ietf-tsvwg-datagram-plpmtud]. For instance, such mechanism >could be implemented between a HIP Relay Client and HIP Relay >Server. > > o It is worth noting that further HIP extensions can trim off 8 >bytes in the ESP header by negotiating implicit IV support in the >ESP_TRANSFORM parameter as described in [RFC8750]. -- Cheers Magnus Westerlund -- Networks, Ericsson Research -- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerl...@ericsson.com -- smime.p7s Description: S/MIME cryptographic signature ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Barry Leiba's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT)
Hi Barry, ke, 2020-03-04 kello 21:07 -0800, Barry Leiba via Datatracker kirjoitti: > Barry Leiba has entered the following ballot position for > draft-ietf-hip-native-nat-traversal-30: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ > > > > --- > --- > COMMENT: > --- > --- > > Given this document’s dependency on concepts and terminology from > 5770, I think > that document has to be a normative reference. Can someone really > understand > and implement this without any reference to 5770? I changed the refence to normative. > — Abstract — > >The main >difference from the previously specified modes is the use of HIP >messages instead of ICE for all NAT traversal procedures due to > its >kernel-space dependencies. > > The antecedent to “its” is unclear: it could be “use of HIP > messages”, or > “ICE”, or “NAT traversal”. Please rephrase to clarify. changed to "due to the kernel-space dependencies of HIP". > — Section 1 — > >Also, especially NATs usually require the >host behind a NAT to create a forwarding state in the NAT before >other hosts outside of the NAT can contact the > > What does “especially” mean in this sentence? It doesn’t make sense > to me. > Does it add anything? I removed it. >which will be referred as "Legacy ICE-HIP" in this document. > > Nit: “referred to” changed as suggested >HIP poses a unique challenge to using standard ICE, due not only > to >its kernel-space implementation, but also due to its close > > Same comment about “its” as in the abstract: please replace “its” > with what > you’re talking about, as it isn’t clear. changed to "kernel-space dependencies of HIP". Thanks for your comments! ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
