On Fri, Feb 21, 2020 at 6:21 AM Miika Komu wrote:
> 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.
>
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
> 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) <
> > evyn...@cisco.com> 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=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
> > >
> >
> > ___
> > 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
