Subject: Re: [Tsv-art] TSV-ART Review of draft-ietf-hip-native-nat-traversal

From: Miika Komu <[email-masked]>
Date: Fri, 2 Mar 2018 20:37:42 +0200

Hi Colin,

thanks for your comments! My suggestions for fixes are below.

On 02/27/2018 01:13 AM, Colin Perkins wrote:
> Hi,
> 
> I've reviewed this document as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments
> were written primarily for the transport area directors, but are
> copied to the document's authors for their information and to allow
> them to address any issues raised. When done at the time of IETF Last
> Call, the authors should consider this review together with any other
> last-call comments they receive. Please always CC tsv-art@… if you
> reply to or forward this review.
> 
> Summary: This draft is basically ready for publication, but has nits
> that should be fixed before publication.
> 
> Comments: This draft describes how the ICE algorithm can be applied
> for NAT traversal with the Host Identity Protocol (HIP). The
> classical ICE algorithm is tied to STUN and TURN for connectivity
> checks, encapsulation, and tunnelling. This draft recasts ICE to work
> with HiP-specific mechanisms. The proposed mechanism looks to be a
> straight-forward reworking of ICE into this new context, and there do
> not look to be any significant new transport issues raised compared
> to classic ICE.
> 
> The draft could perhaps better explain the rationale for recasting
> the ICE protocol to use HIP specific mechanisms rather than reusing
> STUN and TURN. In addition, the reference to Appendix B (which
> explains the differences from classical ICE) at the end of the
> Introduction could perhaps be highlighted. Both would be useful to
> show why this mechanism is needed, and to clearly document the
> differences to classical ICE.

I suggest to modify the sentence in the intro to highlight the importance:

    Appendix B explains the differences to ICE,
    and it is recommended that the reader would read also this section in
    addition to the ICE specification.

And I would add to appendix B (Differences to ICE) a small intro:

    Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it is.  The
    benefits of such as an approach include the reuse of STUN/TURN
    infrastructure and possibly the reuse of existing software libraries,
    but there are also drawbacks with the approach.  For example, ICE is
    meant for application-layer protocols, whereas HIP operates at layer
    3.5 between transport and network layers.  This is particularly
    problematic because the implementations employ IPsec ESP as their
    data plane: demultiplexing of incoming ESP, HIP and TURN messages
    required capturing of all UDP packets destined to port 10500 to the
    userspace, thus causing additional software complexity and an
    unnecessary latency/throughput bottleneck for the dataplane
    performance.  Also, relaying of ESP packets via TURN relays was not
    considered that simple because TURN relays require adding and
    removing extra TURN framing for the relayed packets.  Finally, the
    developers of the two Legacy ICE-HIP implementations concluded that
    "effort needed for integrating an ICE library into a HIP
    implementation turned out to be quite a bit higher that initially
    estimated.  Also, the amount of extra code (some 10 kLoC) needed for
    all the new parsers, state machines, etc., is quite high and by re-
    using the HIP code one should be able to do with much less.  This
    should result in smaller binary size, less bugs, and easier
    debugging.".  Consequently, the HIP working group decided to follow
    ICE methodology but reuse HIP messaging format to achieve the same
    functionality as ICE, and consequently the result is this document
    that specifies the Native ICE-HIP protocol.

Would this address your concerns?

> The draft doesn’t mention the impact on the MTU of encapsulating HIP
> messages for NAT traversal. It probably should discuss the
> implications of this MTU reduction.

Would it address your concerns if I added the following paragraphs to 
the end of the related sections?

    5.1.  HIP Control Packets

    It is worth noting that UDP encapsulation of HIP packets reduces the
    Maximum Transfer Unit (MTU) size of the control plane by 12 bytes.

    5.11.  ESP Data Packets

    It is worth noting that UDP encapsulation of ESP reduces the MTU size
    of data plane by 8 bytes.

> Section 4.1, page 11, suggests the use of UDP port 10500. The IANA
> considerations do not register this port. The draft should either
> register this port, or clearly cite the draft/RFC that does register
> it.

Good catch! I will reference RFC5770.

Is it ok if I post a new version? Also IANA requested also some minor 
nits and it would be nice to have them available.

---

From: Colin Perkins <[email-masked]>
Date: Sun, 4 Mar 2018 22:57:23 +0000

Hi Miika,

These changes all look good to me – thanks! 
Colin

> On 2 Mar 2018, at 18:37, Miika Komu <[email-masked]> wrote:
> 
> Hi Colin,
> 
> Would it address your concerns if I added the following paragraphs to the end of the related sections?
> 
>   5.1.  HIP Control Packets
> 
> Is it ok if I post a new version? Also IANA requested also some minor nits and it would be nice to have them available.

-- 
Colin Perkins
https://csperkins.org/

---

From: Miika Komu <[email-masked]>
Date: Mon, 5 Mar 2018 10:51:21 +0200

Hi Colin,

thanks! I posted a new version.

On 03/05/2018 12:57 AM, Colin Perkins wrote:
>> On 2 Mar 2018, at 18:37, Miika Komu <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Colin,
>>