Subject: [rtcweb] Call for review

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Mar 2019 12:22:11 -0800

Howdy,

draft-uberti-ip-handling-ex-
<https://datatracker.ietf.org/doc/draft-uberti-ip-handling-ex-mdns/>mdns
<https://datatracker.ietf.org/doc/draft-uberti-ip-handling-ex-mdns/> is a
very short draft describing two new modes  related to
draft-ietf-rtcweb-ip-handling
<https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling> using bits of
draft-ietf-rtcweb-mdns-ice-candidates
<https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/>.

The chairs would like to ask for a couple of reviews; given that it is four
pages long, we are hopeful that it will not take much time.

Please send your review to the list,

thanks,

Ted

---

From: Roman Shpount <[email-masked]>
Date: Tue, 5 Mar 2019 15:57:44 -0500

I have reviewed  draft-uberti-ip-handling-ex-mdns and as far as I can see
it looks good.

One comment that I have is that handling of RFC4941 IPv6 addresses in mode
2.1 is different from what is described in
draft-ietf-rtcweb-mdns-ice-candidates
<https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates>. This
ideally should be updated in draft-ietf-rtcweb-mdns-ice-candidates
<https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates> to
allow skipping generation of mDNS names for RFC4941 IPv6 addresses.

On the related note, draft-ietf-rtcweb-mdns-ice-candidates probably should
go into ICE working group or at least be reviewed there. This draft is not
RTCWeb specific and is closely related to ICE.

Regards,
_____________
Roman Shpount

On Tue, Mar 5, 2019 at 3:22 PM Ted Hardie <[email-masked]> wrote:

> The chairs would like to ask for a couple of reviews; given that it is
> four pages long, we are hopeful that it will not take much time.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Mar 2019 16:10:38 -0500

How is it that the two drafts this rules on are only informative references? It probably needs to update IP handling.

The modes this adds are good, but it specifically states that the implications aren't known. It even promises to update the draft when that information is gained.  That suggests that this doc might have an uncertain future. What is the chairs' thinking about the draft?

On Wed, Mar 6, 2019, at 07:22, Ted Hardie wrote:
> <https://datatracker.ietf.org/doc/draft-uberti-ip-handling-ex-mdns/>mdns <https://datatracker.ietf.org/doc/draft-uberti-ip-handling-ex-mdns/> is a very short draft describing two new modes related to draft-ietf-rtcweb-ip-handling <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling> using bits of draft-ietf-rtcweb-mdns-ice-candidates <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/>.
>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Mar 2019 13:12:21 -0800

Roman, was there specific text in mdns-ice-candidates that you think is
contradicted by ip-handling-ex-mdns? The goal was for the former document
to describe the technique and the latter to describe when it should be
applied.

On Tue, Mar 5, 2019 at 12:58 PM Roman Shpount <[email-masked]> wrote:

> allow skipping generation of mDNS names for RFC4941 IPv6 addresses..
>
>> <https://datatracker.ietf.org/doc/draft-uberti-ip-handling-ex-mdns/> is
>> a very short draft describing two new modes  related to
>> <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling> using bits
>> of draft-ietf-rtcweb-mdns-ice-candidates

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Mar 2019 13:13:29 -0800

Regarding information about implications, we expect to be able to share
initial data within the next several weeks.

On Tue, Mar 5, 2019 at 1:10 PM Martin Thomson <[email-masked]> wrote:

> How is it that the two drafts this rules on are only informative
> references? It probably needs to update IP handling.
>
> The modes this adds are good, but it specifically states that the
> implications aren't known. It even promises to update the draft when that
> information is gained.  That suggests that this doc might have an uncertain
> future. What is the chairs' thinking about the draft?
>
> draft-ietf-rtcweb-ip-handling <
> https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling> using bits of
> draft-ietf-rtcweb-mdns-ice-candidates <
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/>.
> >

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Mar 2019 13:15:09 -0800

> future. What is the chairs' thinking about the draft?
Traditionally, Experimental is the best fit for docs with that
characteristic.

Ted

---

From: Roman Shpount <[email-masked]>
Date: Tue, 5 Mar 2019 16:31:55 -0500

> to describe the technique and the latter to describe when it should be

According to Section 3.1 of ietf-rtcweb-mdns-ice-candidates (
https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02#section-3.1)
all host candidates are replaced with mDNS names. Based on
draft-uberti-ip-handling-ex-mdns,  RFC4941 IPv6 addresses in mode 2.1 can
be skipped and left as is. Some language likely need to be added to
ietf-rtcweb-mdns-ice-candidates
section 3.1 to specify that mDNS encoding is optional, at least for RFC4941
IPv6 address.

Furthermore, mdns-ice-candidates section 3.1 specifies that mDNS names can
be re-used. These re-used mDNS names could be used for fingerprinting. For
your draft, it is probably a good idea to limit re-use only to the same
browser session.

Regards,
_____________
Roman Shpount

---

From: westhawk <[email-masked]>
Date: Tue, 5 Mar 2019 21:40:24 +0000

On first reading it seems like there might be a conflation of private IP addresses and local IP addresses.
the [ip-handling] document uses the term 'Private local IP addresses’ where as this document
uses "private IP addresses” in the introduction but then uses "The local IPv4 address” without any
explanation (I can find) of the difference.

Surely this would mean that a standalone device (say a public kiosk) assigned a 
single routable public IP would mask that address with mdns.

Tim.

> On 5 Mar 2019, at 20:22, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> draft-uberti-ip-handling-ex-mdns is a very short draft describing two new modes  related to draft-ietf-rtcweb-ip-handling using bits of draft-ietf-rtcweb-mdns-ice-candidates.
> 
> The chairs would like to ask for a couple of reviews; given that it is four pages long, we are hopeful that it will not take much time.
>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Mar 2019 19:08:08 -0800

On Tue, Mar 5, 2019 at 1:32 PM Roman Shpount <[email-masked]> wrote:

> be skipped and left as is. Some language likely need to be added to ietf-rtcweb-mdns-ice-candidates

This has been addressed in the editor's copy of the mdns-ice-candidates
draft - see
https://rtcweb-wg.github.io/mdns-ice-candidates/draft-ietf-rtcweb-mdns-ice-candidates.html#rfc.section.3.1
.

> your draft, it is probably a good idea to limit re-use only to the same

I believe this is covered by
https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02#section-5.3
.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Mar 2019 19:34:12 -0800

We'll always mask any local addresses with mDNS, since we don't know if
they're public or not. We will also provide a srflx candidate with the
actual address should STUN tell us that information.

Agree though we should be consistent on terminology, will look into what
the best option is there.

On Tue, Mar 5, 2019 at 1:40 PM westhawk <[email-masked]> wrote:

> > draft-uberti-ip-handling-ex-mdns is a very short draft describing two
> new modes  related to draft-ietf-rtcweb-ip-handling using bits of
> draft-ietf-rtcweb-mdns-ice-candidates.
> >

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 5 Mar 2019 20:43:50 -0800

I have reviewed draft-uberti-ip-handling-ex-mdns and in general it looks.

One part is not clear enough to me though: 
- section 3.1 uses the term “preferred interface” for first time (I did not find this term in draft-rtcweb-ip-handling) and it’s not clear to me what it means.
- section 3.2 does not use the term interfaces at all, but instead talks about IP addresses instead.

I’m guessing section 3.2 implicitly refers to all IP addresses from all interface. It would help to make that explicit.
Since “preferred interface” seems to be used first in the draft I think needs to be defined somewhere.
Alternatively the term “preferred interface” in section 3.1 could get replaced with terms referring to IP addresses.

Best regards
  Nils Ohlmeier

> On 5Mar, 2019, at 12:22, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> draft-uberti-ip-handling-ex- <https://datatracker.ietf.org/doc/draft-uberti-ip-handling-ex-mdns/>mdns <https://datatracker.ietf.org/doc/draft-uberti-ip-handling-ex-mdns/> is a very short draft describing two new modes  related to draft-ietf-rtcweb-ip-handling <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling> using bits of draft-ietf-rtcweb-mdns-ice-candidates <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/>.
>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Mar 2019 21:48:48 -0800

On Tue, Mar 5, 2019 at 8:44 PM Nils Ohlmeier <[email-masked]> wrote:

> - section 3.1 uses the term “preferred interface” for first time (I did
> not find this term in draft-rtcweb-ip-handling) and it’s not clear to me
> what it means.
>

Yes, I should have said "interface associated with the default route", to
be consistent with ip-handling.

> I’m guessing section 3.2 implicitly refers to all IP addresses from all
> interface. It would help to make that explicit.
>

Technically correct; however, in Mode 2.* only the addresses from the
'default' interface are provided, so for clarity the document should
reiterate that fact (and that they are all replaced with mDNS names).

> Alternatively the term “preferred interface” in section 3.1 could get
> replaced with terms referring to IP addresses.
>

Open to ideas here; "interface associated with the default route" is kind
of verbose.

---

From: Lennart Grahl <[email-masked]>
Date: Wed, 6 Mar 2019 09:45:07 +0100

> actual address should STUN tell us that information.

IIRC that would mean a publicly reachable local IP address would still
be masked with mDNS first. Once the STUN server's answer arrives, a
srflx candidate with the exposed IP address must be handed out. Is that
assumption correct?

Cheers
Lennart

---

From: westhawk <[email-masked]>
Date: Wed, 6 Mar 2019 10:11:01 +0000

> On 6 Mar 2019, at 03:34, Justin Uberti <[email-masked]> wrote:
> 
> We'll always mask any local addresses with mDNS, since we don't know if they're public or not. We will also provide a srflx candidate with the actual address should STUN tell us that information.

So the ‘always’ should be conditional on how the addresses are ‘found’?
Perhaps a definition of Local IP addresses would help:
“Local IP addresses means addresses discovered by interrogating the operating system for
a list of available interfaces and their associated IP addresses” 

Plus a clarification that “these rules do not apply to addresses that are subsequently found via
STUN or ICE - note that this may cause an address to be listed twice - once as a host candidate with a masked mdns
and a second time with it’s IP address as a reflex candidate”

(I’ve a feeling there is section of the ICE RFC that talks about eliminating reflex candidates that duplicate host candidates 
but can’t find it)

Tim.  

> 
> Agree though we should be consistent on terminology, will look into what the best option is there.
> 
> On Tue, Mar 5, 2019 at 1:40 PM westhawk <[email-masked] <mailto:[email-masked]>> wrote:
> > On 5 Mar 2019, at 20:22, Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Howdy,
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 6 Mar 2019 09:34:02 -0800

> On 6Mar, 2019, at 02:11, westhawk <[email-masked]> wrote:
> 
> 
> 
>> On 6 Mar 2019, at 03:34, Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Isn’t this the definition of a host candidate?
That would have been my interpretation of local addresses any way.

> (I’ve a feeling there is section of the ICE RFC that talks about eliminating reflex candidates that duplicate host candidates 

Yes it has. It might be hidden in one of the sections about peer reflexive candidates.

  Nils

---

From: Justin Uberti <[email-masked]>
Date: Wed, 6 Mar 2019 15:52:24 -0800

> srflx candidate with the exposed IP address must be handed out. Is that

Exactly correct.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 6 Mar 2019 15:55:31 -0800

> STUN or ICE - note that this may cause an address to be listed twice -
> once as a host candidate with a masked mdns

Perhaps this could be simplified by simply referring to 'host' IP
addresses, where 'host' has the same meaning (i.e. local interface) as in
ICE.

>
> (I’ve a feeling there is section of the ICE RFC that talks about
> eliminating reflex candidates that duplicate host candidates
> but can’t find it)
>

There is, but I content it does not apply here, since these srflx
candidates will contain a different (non-hostname) address.

---

From: westhawk <[email-masked]>
Date: Thu, 7 Mar 2019 09:07:13 +0000

> On 6 Mar 2019, at 23:55, Justin Uberti <[email-masked]> wrote:
> 
> 
> 
> On Wed, Mar 6, 2019 at 2:11 AM westhawk <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Perhaps this could be simplified by simply referring to 'host' IP addresses, where 'host' has the same meaning (i.e. local interface) as in ICE. 

Yep, that is probably clearer.

> There is, but I content it does not apply here, since these srflx candidates will contain a different (non-hostname) address.

Yep, but I think it might be worth a clarification note in this document - unless it is clear to everyone else that the de-dupe is done by host name not by underlying address. - Essentially this is a clarification on what order the processing is done across multiple RFCs.

T.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 7 Mar 2019 15:47:30 -0800

On Thu, Mar 7, 2019 at 1:07 AM westhawk <[email-masked]> wrote:

> Yep, but I think it might be worth a clarification note in this document -
> unless it is clear to everyone else that the de-dupe is done by host name
> not by underlying address. - Essentially this is a clarification on what
> order the processing is done across multiple RFCs.
>
> That's reasonable. We'll add a note to this effect in the main
rtcweb-mdns-candidates document.
https://github.com/rtcweb-wg/mdns-ice-candidates/issues/105