Subject: Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)

From: Miika Komu <[email-masked]>
Date: Wed, 19 Feb 2020 20:52:00 +0000

Hi Spencer,

thanks for your comments, please see my response below.

ke, 2018-05-09 kello 18:18 -0700, Spencer Dawkins kirjoitti:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-28: 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:
> -------------------------------------------------------------------
> ---
> 
> I'm balloting No Objection, but I'm watching the discussion in Eric's
> ballot
> thread about reusing pieces of ICE, and I look forward to some
> discussion about
> the provisions being made for middleboxes in this draft - I'm not
> denying that
> such things exist, only that it would be best if we understood why
> middleboxes
> are needed for this usage.

I am not sure exactly what you mean by middlebox provisioning, but at
least a couple of things have been clarified in the draft related to
middleboxes:

* STUN may be used for discovering address candidates; HIP Control
Servers are recommended 
* The address candidates are encrypted to protect against middlebox
tampering

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 26 Feb 2020 18:23:31 +0100

Hi Miika,

Maybe you already go a reply from Spencer anyway, however, he is not serving in the AD position anymore, so he might not reply.

Thanks for replying to his comments anyway. I think a way to encrypt candidate address was what Spencer was looking for. So I think his comment is addressed as well.

I also just enter my ballot with “No objection” and I think Magnus Westerlund, Spencer’s successor, will also enter a ballot position in the next week.

Mirja

> On 19. Feb 2020, at 21:52, Miika Komu <miika.komu=[email-masked]> wrote:
> 
> Hi Spencer,
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 26 Feb 2020 12:20:16 -0600

Hi, Mirja, and Magnus,

On Wed, Feb 26, 2020 at 11:23 AM Mirja Kuehlewind <[email-masked]>
wrote:

> Hi Miika,
>
> Maybe you already go a reply from Spencer anyway, however, he is not
> serving in the AD position anymore, so he might not reply.
>

Right, and for extra credit, now that a new ballot has been issued, I'm not
seeing the ballot threads from any of the ADs, so didn't want to cause
confusion and further delay this document.

> Thanks for replying to his comments anyway. I think a way to encrypt
> candidate address was what Spencer was looking for. So I think his comment
> is addressed as well.
>

I now apologize for using the word "provision" in my ballot - I wasn't
talking about "provisioning" in the configuration sense, but about "making
accommodations because middleboxes exist".

> I also just enter my ballot with “No objection” and I think Magnus
> Westerlund, Spencer’s successor, will also enter a ballot position in the
> next week.
>

I see that Adam has asked the question about why XOR is not required, which
is close enough to my question that I should DEFINITELY continue to defer
to the current ADs!

Make good choices.

Best to you all, and thanks for finishing this up.

Spencer

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 27 Feb 2020 11:48:21 +0000

> is close enough to my question that I should DEFINITELY continue to defer

I believe that was already answered somewhere in the thread of messages.

XOR is not used as it is superfluous, since the messages in question are
encrypted.  Hence middleboxes still can't see the addresses.

DF