[Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-fast-mobility-03.txt
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. Stay tuned... Forwarded Message Subject: New Version Notification for draft-moskowitz-hip-fast-mobility-03.txt Date: Fri, 03 Apr 2020 06:24:02 -0700 From: internet-dra...@ietf.org To: Stuart W. Card , Adam Wiethuechter , Robert Moskowitz , Stuart Card A new version of I-D, draft-moskowitz-hip-fast-mobility-03.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-fast-mobility Revision: 03 Title: Fast HIP Host Mobility Document date: 2020-04-03 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-fast-mobility-03.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-fast-mobility/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-fast-mobility-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-fast-mobility Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-fast-mobility-03 Abstract: This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ 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, See below. On Fri, 2020-04-03 at 06:41 +, Miika Komu wrote: > Hi Magnus, > > to, 2020-04-02 kello 22:56 +0300, Miika Komu kirjoitti: > > > > > 4. MTU impact of NAT traversal. > > > > > > Section 5.1 states > > > "It is worth noting that UDP encapsulation of HIP packets reduces > > > the > > >Maximum Transfer Unit (MTU) size of the control plane by 12 > > > bytes." > > > > > > There is also a similar text in Section 5.11: > > > > > >It is worth noting that UDP encapsulation of ESP reduces the MTU > > > size > > >of data plane by 8 bytes. > > > > > > I think the document needs a discussion and impact on MTU which > > > this > > > NAT > > > traversal has on the HIP packets being sent. - First of all there > > > appears to be > > > more packet expansions happening in some cases, for example the > > > RELAY_HMAC > > > option expands packets on one leg. - Secondly, HIP requires IP > > > fragementation > > > support, however IP fragmentation through NAT is commonly not > > > working. Thus an > > > HIP packet being UDP encapsulated that results in packet exceeding > > > MTU will > > > likely end up in an MTU black hole on path. > > > > > > The addition of the NAT traversal encapsulation actually increases > > > the need for > > > MTU discovery or care in MTU handling by the HIP initiator. I think > > > there need > > > to be discussion of that in the document. > > > > I am stil iterating some text on this, I hope Jeff Ahrenholz can help > > with this. > > I got text from Jeff Ahrenholz and Robert Moskowitz: > > Section 5.2 > > replaced this: > > It is worth noting that UDP encapsulation of HIP packets reduces the > Maximum Transfer Unit (MTU) size of the control plane by 12 bytes. > > with: > > 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. This > encapsulation overhead increases the need for MTU discovery. A HIP > host SHOULD have the option to enable ICMP path MTU discovery (PMTUD) > [RFC1063] [RFC8201]. Otherwise, support for IP fragmentation is > required, which may not be commonly supported through NATs. When HIP > encapsulation is implemented using a virtual tunneling interface, > consider using a reduced MTU (e.g. 1400) by default. Additional HIP > relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, > etc., further increase the size of certain HIP packets. 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]. > > Does this address your concerns? I think the recommendation for virtual interface is a reasonable one based on the constraints. However, I think: A HIP > host SHOULD have the option to enable ICMP path MTU discovery (PMTUD) > [RFC1063] [RFC8201]. Otherwise, support for IP fragmentation is > required, which may not be commonly supported through NATs. maybe should be reformulated. ICMP messages are sometimes dropped in NATs, despite recommendations to support at least the TOO BIG messages. And I think if ICMP either is not working or not enabled, indicating that IP fragmentation could be a possible way to get thingst to work, appears even less likely to work as IP fragmentation handling in NATs becomes resource demanding due to all per packet state needed to be maintained, as only the first fragement contains the UDP header allowing the lookup of the translation record. Maybe it can be made clearer by restructuring the text so that it says this: - A HIP host SHOULD implement ICMP message handling to support MTU discovery per [RFC1063] [RFC8201]. - Reliance on IP fragmentation is unlikely to be a viable strategy through NATs so if ICMP MTU discovery is not working MTU realted path black holes may occur. - A mitigation is to constrain the MTU, especially for virtual interfaces to expected to be safe MTU values, e.g. 1400 bytes for underlying interfaces that support 1500 bytes MTU. - (to include something realted to below discussion consider this bullet also, assumes that PLP MTUD actually can be implemented in HIP relay rather simply): Implement PLPMTUD [draft-ietf-tsvwg-datagram-plpmtud] in HIP to find a working path MTU without unnecessary constraining that size. Has anyone looked at implementing https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ (document is in IESG evaluation) style path MTU discovery between the HIP client and the relay? Becasue I think that would be the best to actually run a HIP level path MTU discovery, so that the HIP client can set its MTU to path minus overhead and including any for occasional messages that are required to be included when carrying useful payload. If HIP has a padding option, then I would expect that HIP has everything necessary to implement working probe messages that can used by the above
Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)
Hi Miika, Please see inline. On Thu, 2020-04-02 at 19:56 +, Miika Komu wrote: > Hi Magnus, > > to, 2020-03-05 kello 03:08 -0800, Magnus Westerlund via Datatracker > kirjoitti: > > Magnus Westerlund has entered the following ballot position for > > draft-ietf-hip-native-nat-traversal-30: Discuss > > > > 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/ > > > > > > > > --- > > --- > > DISCUSS: > > --- > > --- > > > > So I think the below are important things that needs to be discussed > > before > > proceeding. However, I might have missed things as I didn't have time > > to read > > the whole document in detail. Several of the issues are pieces for > > discussion > > to ensure that the right thing really is done. > > > > 1. So this document recommends the usage of port 10500 as default > > listening > > port. A port registered by Ari and also used for RFC 5770. I get the > > impression > > that the port was registered separately from RFC 5770. So the port is > > assigned > > to Ari. Would Ari be willing to release the port for re-assignment to > > IESG > > control. RFC 6335 has the recommendation for ports for IETF protocols > > that the > > assignee is IESG and the contact ch...@ietf.org. This to have the > > change > > control with IETF as body rather than with individuals. > > > > If Ari agrees to this, I think it would be good to have the IANA > > section be > > updated to note the re-assignment and provide the necessary > > information. > > This document reuses the same default UDP port number 10500 as > specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control > plane and data plane traffic. The port was was registered > separately for RFC5770 to co-author Ari Keranen but should now be re- > assigned for IESG control. With the permission of Ari Keranen, the new > assignee is IESG and contact "ch...@ietf.org". In addition, IANA is > requested to add a reference to this document in the entry for UDP port > 10500 in the Transport Protocol Port Number Registry. The selection > between Legacy ICE-HIP and Native ICE-HIP mode is negotiated using > NAT_TRAVERSAL_MODE parameter during the base exchange. By default, > hosts listen this port for incoming UDP datagrams and can use it also > for sending UDP datagrams. Other emphemeral port numbers are > negotiated and utilized dynamically. Thanks, this is exactly what I wanted to here. > > > 2. Secondly, as this solution is different from the RFC 5770 should > > this > > solution have a different service name? The reason I am asking is > > that it > > depends on how for example how an initiator determine which of the > > NAT > > traversal solution. If there is any intention to use DNS SRV for > > example > > different service name would make sense. This is primarily to verify > > that this > > has been considered. > > I am not an expert on the topic but based on some discussions with some > colleagues, the SRV records seem to more suitable for infrastructure > discovery, not really for end-host discovery. Since you asked for this, > I wrote a new section in the appendix: So the main reason for my question was to ensure that you have not forgoetten that you actually have some dependnecy on the service name that would in fact be incompatible. That could include some supporting document, for example usage of SRV records. However, with the below text written, I do find it informative.. And the statement at the end that you don't use SRV records currently is also good and part to answer one aspect of my question. To conclude, it appears to be no issues with having the two mechanisms share service name and port. From my perspective it appears to be some benefit in including the below appendix in the specificaiton, but you should seek consensus on it in the WG before the document is approved in my opinion. > > 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
Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)
Hi Magnus, to, 2020-04-02 kello 22:56 +0300, Miika Komu kirjoitti: > > > 4. MTU impact of NAT traversal. > > > > Section 5.1 states > > "It is worth noting that UDP encapsulation of HIP packets reduces > > the > >Maximum Transfer Unit (MTU) size of the control plane by 12 > > bytes." > > > > There is also a similar text in Section 5.11: > > > >It is worth noting that UDP encapsulation of ESP reduces the MTU > > size > >of data plane by 8 bytes. > > > > I think the document needs a discussion and impact on MTU which > > this > > NAT > > traversal has on the HIP packets being sent. - First of all there > > appears to be > > more packet expansions happening in some cases, for example the > > RELAY_HMAC > > option expands packets on one leg. - Secondly, HIP requires IP > > fragementation > > support, however IP fragmentation through NAT is commonly not > > working. Thus an > > HIP packet being UDP encapsulated that results in packet exceeding > > MTU will > > likely end up in an MTU black hole on path. > > > > The addition of the NAT traversal encapsulation actually increases > > the need for > > MTU discovery or care in MTU handling by the HIP initiator. I think > > there need > > to be discussion of that in the document. > > I am stil iterating some text on this, I hope Jeff Ahrenholz can help > with this. I got text from Jeff Ahrenholz and Robert Moskowitz: Section 5.2 replaced this: It is worth noting that UDP encapsulation of HIP packets reduces the Maximum Transfer Unit (MTU) size of the control plane by 12 bytes. with: 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. This encapsulation overhead increases the need for MTU discovery. A HIP host SHOULD have the option to enable ICMP path MTU discovery (PMTUD) [RFC1063] [RFC8201]. Otherwise, support for IP fragmentation is required, which may not be commonly supported through NATs. When HIP encapsulation is implemented using a virtual tunneling interface, consider using a reduced MTU (e.g. 1400) by default. Additional HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, etc., further increase the size of certain HIP packets. 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]. Does this address your concerns? Btw, I would remove the following redundant statement in "RELAYED_ADDRESS and MAPPED_ADDRESS Parameters" section: It is worth noting that UDP encapsulation of ESP reduces the MTU size of data plane by 8 bytes. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
