Subject: [rtcweb] Suresh Krishnan's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS)

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 02 Aug 2016 20:59:30 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-rtcweb-transports-14: 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-rtcweb-transports/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for writing this draft. It really helped clarify a lot of things
for me. I do have a concern though.

In Section 3.3.  Usage of temporary IPv6 addresses, the draft states

" The IPv6 default address selection specification [RFC6724] specifies
   that temporary addresses [RFC4941] are to be preferred over permanent
   addresses."

While this is technically true, this is only the seventh rule in an
ordered list of eight rules.
e.g. A valid permanent address would be preferred over a deprecated
temporary address based on Rule 3.

If a host had only a valid permanent address and a deprecated temporary
address, the mechanism specified in the draft would result in no
addresses being made available, whereas the permanent address would have
been an acceptable choice using RFC6724. 

So, it is not entirely clear to me what the draft is trying to
accomplish. It says 

"   However, this rule is not completely obvious in the ICE scope.  This
   is therefore clarified as follows:"
 
What rule is this talking about when it says "this rule"?

Similarly, it also says

"When a client gathers all IPv6 addresses on a host..."

but it is not clear what "client" the draft is referring to. 

I think if you can clarify what you want to achieve with the address
selection we can work together on some replacement text.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Aug 2016 11:58:04 +0200

Thanks for the comment!

I've attached this to
https://github.com/rtcweb-wg/rtcweb-transport/issues/22 because it deals
with the same block of text.

> been an acceptable choice using RFC6724. 

The previous fix added "non-deprecated" into the sentence. See
https://github.com/rtcweb-wg/rtcweb-transport/pull/32/files

> What rule is this talking about when it says "this rule"?

Rule seven.

The reason why it's not obvious is that ICE doesn't "prefer" addresses -
it gathers a bunch of them, and then sends the whole set to its partner,
where it will be tried in some order - which means that it's observable
by anyone who can see the signalling.

I believe rule seven was flipped in 6724 because of a concern with
privacy-enhanced addresses (which are temporary); if the permanent
address is tried before the temporary address, the permanent address
will be exposed when it doesn't have to.

In the ICE case, if it is gathered, it will be exposed; the only way to
preserve privacy of the permanent address is to discard it when
gathering ICE candidates.

No similar privacy concern was raised for the other steps of the algorithm.

> "When a client gathers all IPv6 addresses on a host..."

The intent is "WebRTC endpoint", as defined in -overview. I'll change
the terminology.

> selection we can work together on some replacement text.

Is it clear enough what we wanted to accomplish?

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 3 Aug 2016 21:37:46 +0000

Hi Harald,
   Thanks for clarifying your intent of culling the address set for ICE. 
Sounds reasonable. The text changes you have proposed for the next rev look 
good to me. I will clear as soon as the new rev is published.

Regards
Suresh