Subject: [Hipsec] Re-doing the IESG ballot for draft-ietf-hip-native-nat-traversal

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 21 Feb 2020 12:35:04 +0000

Hi,

The first IESG ballot for the draft-ietf-hip-native-nat-traversal was done in May 2018 and was blocked by a couple of DISCUSS by the 2018 IESG. The main issue IMHO was around “why not reusing plain ICE?”; the authors in discussion with Adam Roach have provided an applicability statement and a justification on why “plain ICE” does not work efficiently when combined with HIP + additional text or replies for the remaining DISCUSS & COMMENT.

The diff are https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-30&url1=draft-ietf-hip-native-nat-traversal-28

I have reviewed all COMMENT and DISCUSS from 2 years ago and it appears to me that they are all addressed (including those from 2018 AD who are no more AD in 2020 – they are in cc). The changes in the document are minor and I am confident that neither a WG Last Call not an IETF Last Call is required. I am therefore placing the document in the next IESG telechat and opening a new IESG ballot.

Thank you for the authors on their energy to keep the document useful,

Regards,

-éric

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Feb 2020 05:38:47 -0800

I would like to note for the record that I do not find the arguments in the
applicability statement at all persuasive. They are principally about
performance but ICE occurs at setup time (so CPU performance is not much of
an issue) and is inherently so, with pacing and RTT the dominant factors
(and so the system architecture issues are unpersuasive). As I am no longer
an AD, this is just opinion, but were I the AD,  I would insist on a strong
rationale.

-Ekr

On Fri, Feb 21, 2020 at 4:35 AM Eric Vyncke (evyncke) <[email-masked]>
wrote:

> Hi,
>
>
>
> The first IESG ballot for the draft-ietf-hip-native-nat-traversal was done
> in May 2018 and was blocked by a couple of DISCUSS by the 2018 IESG. The
> main issue IMHO was around “why not reusing plain ICE?”; the authors in
> discussion with Adam Roach have provided an applicability statement and a
> justification on why “plain ICE” does not work efficiently when combined
> with HIP + additional text or replies for the remaining DISCUSS & COMMENT.
>
>
>
> The diff are
> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-30&url1=draft-ietf-hip-native-nat-traversal-28
>
>
>
> I have reviewed all COMMENT and DISCUSS from 2 years ago and it appears to
> me that they are all addressed (including those from 2018 AD who are no
> more AD in 2020 – they are in cc). The changes in the document are minor
> and I am confident that neither a WG Last Call not an IETF Last Call is
> required. I am therefore placing the document in the next IESG telechat and
> opening a new IESG ballot.
>
>
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 21 Feb 2020 13:56:31 +0000

Thank you, Eric, for the added information.

-éric (the other one)

From: Eric Rescorla <[email-masked]>
Date: Friday, 21 February 2020 at 14:39
To: Eric Vyncke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Ben Campbell <[email-masked]>, Spencer Dawkins at IETF <[email-masked]>, Terry Manderson <[email-masked]>
Subject: Re: Re-doing the IESG ballot for draft-ietf-hip-native-nat-traversal

I would like to note for the record that I do not find the arguments in the applicability statement at all persuasive. They are principally about performance but ICE occurs at setup time (so CPU performance is not much of an issue) and is inherently so, with pacing and RTT the dominant factors (and so the system architecture issues are unpersuasive). As I am no longer an AD, this is just opinion, but were I the AD,  I would insist on a strong rationale.

-Ekr

On Fri, Feb 21, 2020 at 4:35 AM Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

-éric

---

From: Miika Komu <[email-masked]>
Date: Fri, 21 Feb 2020 14:21:10 +0000

Hi Eric,

I disagree about the overhead occuring only during set up time because
STUN message format is incompatible with ESP formatting, so an
implementation needs to constantly monitor and intercept STUN packets
from the data-plane traffic. This causes a continuous overhead to the
data plane, so it is not only about set up time. Please check the draft
or hipsec mailing for more detailed discussion on this.

pe, 2020-02-21 kello 05:38 -0800, Eric Rescorla kirjoitti:
> I would like to note for the record that I do not find the arguments
> in the applicability statement at all persuasive. They are
> principally about performance but ICE occurs at setup time (so CPU
> performance is not much of an issue) and is inherently so, with
> pacing and RTT the dominant factors (and so the system architecture
> issues are unpersuasive). As I am no longer an AD, this is just
> opinion, but were I the AD,  I would insist on a strong rationale.
> 
> -Ekr
> 
> 
> On Fri, Feb 21, 2020 at 4:35 AM Eric Vyncke (evyncke) <
> [email-masked]> wrote:
> > Hi,
> >  
> > The first IESG ballot for the draft-ietf-hip-native-nat-traversal
> > was done in May 2018 and was blocked by a couple of DISCUSS by the
> > 2018 IESG. The main issue IMHO was around “why not reusing plain
> > ICE?”; the authors in discussion with Adam Roach have provided an
> > applicability statement and a justification on why “plain ICE” does
> > not work efficiently when combined with HIP + additional text or
> > replies for the remaining DISCUSS & COMMENT.
> >  
> > The diff are 
> > I have reviewed all COMMENT and DISCUSS from 2 years ago and it
> > appears to me that they are all addressed (including those from
> > 2018 AD who are no more AD in 2020 – they are in cc). The changes
> > in the document are minor and I am confident that neither a WG Last
> > Call not an IETF Last Call is required. I am therefore placing the
> > document in the next IESG telechat and opening a new IESG ballot.
> >  
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Feb 2020 06:52:29 -0800

> or hipsec mailing for more detailed discussion on this.

Assuming you're talking about Appendix B, this is just a bare assertion
that is no more convincing than the one you make here.

I would make several points here:

1. STUN packets are trivial to detect and that detection is *far* cheaper
than doing any kind of cryptographic processing. Moreover, you only need to
invoke it once you have determined that you don't have an ESP packet on
your hands, which you have to do *anyway*, because you need to demux ESP
packets from HIP setup packets.
Failing that, you could just do STUN demuxing for packets which are
unprocessable as ESP (which you would need to have some code for anyway).
2. Once the ICE handshake has completed, the only reason to send STUN
packets is for keepalives, which ICE explicitly permits to be able to sent
by non-STUN mechanisms, so you could simply profile ICE to use a non-STUN
keepalive. Beyond that, you can simply ignore STUN as long as there aren't
any connections being set up.

To the extent to which your argument relies one endpoint performance, I
really think that some measurements and a demonstration that you attempted
to optimize the code in the obvious ways are in order. More generally, this
sort of non-specific performance argument is often adduced in favor of
designing something new, but ICE is a very complicated piece of machinery
that has taken the IETF quite a lot of time to build and refine. This
protocol is subtly different in ways that don't seem entirely obvious and
so I think we should be quite cautious about issuing it as a Proposed
Standard when we have a pre-existing protocol at hand, given that the
arguments for doing so seem to rest on a rather thin set of arguments about
performance.

-Ekr