Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt

From: Alissa Cooper <[email-masked]>
Date: Fri, 1 Apr 2016 20:13:48 -0500

> On Mar 22, 2016, at 6:10 PM, Ted Hardie <[email-masked]> wrote:
> 
> Speaking as an individual, rather than chair:
> 
> On Tue, Mar 22, 2016 at 3:31 AM, Drage, Keith (Nokia - GB) <[email-masked] <mailto:[email-masked]>> wrote:
> The header of this document says "standards track".
> 
> The title of the document says "recommendations" which would equate to a normative document of SHOULD strength
> 
> The abstract says "best practices"
> 
> Throughout the document I detected lots of lower case usage of RFC 2119 terms but did not see any upper case usage (but may have missed it).
> 
> All of which leaves me confused.
> 
> Would the chairs like to clarify the intent of this document in terms of document type?
> 
> Regards
> 
> Keith Drage
> 
> 
> I don't think this document describes any new protocol mechanisms, so the lack of upper case RFC 2119 terms seems to me personally fairly natural.  What it does instead is lay out the results of doing IP address handling in specific modes, along with a recommendation on which would make a reasonable default. 
> 
> Clearly it could have been part of JSEP, which would have made it part of a standards track doc.  The value to me of it being separate is that the advice can be revised independently of the core protocol specification.  To that extent, it is somewhere between "Applicability statement" and "BCP" in our formal terminology, with a thumb very slightly on the scale toward BCP. Ultimately, though, I am willing to be guided by our ADs or the community about the exact status. 

I could see an argument for either standards track or BCP and don’t have a strong feeling either way. In either case some adjustments would be necessary to make clear the normativity or non-normativity of the guidance.

Alissa

> The high order bits are the advice and its decomposability.
> 
> regards,
> 
> Ted 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 3 Apr 2016 15:18:57 +0200

The confusion if occured between English authors may mean that we can get
confusions among non-English authors as well, I recommend if a guidance
draft is written we will need many non-Enlish native speekers involved.

AB

On Mon, Mar 28, 2016 at 9:58 PM, Brian E Carpenter <
[email-masked]> wrote:

> There are times when I think RFC2119 was a really bad idea, despite it
> having
> become probably the most frequently cited RFC (inside and outside the
> IETF).
> It seems to create as much confusion as it avoids.
>
> There are four words whose RFC2119 meaning is different from the dictionary
> meaning: should, recommended, may and optional. Having special typography
> for them is useful, because it signals the RFC2119 meanings. But if a spec
> uses, for example, a mixture of SHOULD and should, who knows what the
> authors
> intended? To that extent, the proposed clarification is helpful.
>
> The other words (must, shall, required, not) mean what they always mean.
> The only argument for upper-casing them is aesthetic symmetry. If a spec
> uses alternatives like mandatory, necessary or forbidden, they are just as
> powerful.
>
> So
> > these definitions are only meaningful if the words are capitalized
> can be applied to should, recommended, may and optional if we want,
> but strictly doesn't apply to must, shall, required, not, mandatory,
> necessary, forbidden, need, or any other such words.
>
> Where we can get into real trouble is if a spec contains should,
> recommended,
> may and optional *plus* other non-categorical (fuzzy) words like ought,
> encourage, suggest, can, might, allowed, permit (and I did not pull those
> words out of the air, but out of draft-hansen-nonkeywords-non2119). What do
> they mean? It can be very unclear. If a node receives a message containing
> an element covered in the spec by "allowed" instead of "OPTIONAL", is the
> receiver supposed to interoperate or to reject the message?
>
> If we are issuing guidance, it should probably include a specific warning
> to use any such fuzzy words with extreme care.
>
>    Brian
> On 29/03/2016 03:13, Scott O. Bradner wrote:
> > one minor tweak
> >
> >> On Mar 28, 2016, at 10:09 AM, Barry Leiba <[email-masked]>
> wrote:
> >>
> >>> The wishy washy descriptive rather than proscriptive language in the
> abstract was because I,
> >>> the IESG and the community were not of one mind to say that the use of
> such capitalized
> >>> terms should be mandatory - quite a few people felt that the english
> language was at
> >>> least good enough to convey  the writer’s intent without having to
> aggrandize specific words.
> >>> Thus the abstract basically was saying: if you want to use capitalized
> words here is a standard
> >>> way to say what they mean
> >>
> >> Ah.  Then perhaps the clarification needs to go a little further and
> >> make this clear:
> >> - We're defining specific terms that specifications can use.
> >> - These terms are always capitalized when these definitions are used.
> >
> > these definitions are only meaningful if the words are capitalized
> >
> >> - You don't have to use them.  If you do, they're capitalized and
> >> their meanings are as specified here.
> >> - There are similar-looking English words that are not capitalized,
> >> and they have their normal English meanings; this document has nothing
> >> to do with them.
> >>
> >> ...and I'd like to add one more, because so many people think that
> >> text isn't normative unless it has 2119 key words in all caps in it:
> >>
> >> - Normative text doesn't require the use of these key words.  They're
> >> used for clarity and consistency when you want that, but lots of
> >> normative text doesn't need to use them, and doesn't use them.
> >>
> >> Barry
> >
> >
>
>

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 26 Apr 2016 10:11:08 +0200

Am 20.03.2016 um 23:31 schrieb [email-masked]:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF.
>
>          Title           : WebRTC IP Address Handling Recommendations
>          Authors         : Justin Uberti
>                            Guo-wei Shieh
> 	Filename        : draft-ietf-rtcweb-ip-handling-01.txt
> 	Pages           : 8
> 	Date            : 2016-03-20

I stumbled upon a (now deleted) stackoverflow posting yesterday in which 
obfuscated code "used webrtc" to hack the users router.
Basically webrtc was used to get the local ip address from which the 
routers ip is inferred. Then a default admin account is tried.

It turns out the idea is not knew, I heard from some former coworkers 
that they used this in penetration testing before. But it has now 
reached stackoverflow which means there will soon be rumors and all 
kinds of "webrtc allows hacking your router" stories.

The principal problem here is default passwords. WebRTC makes it 
slightly easier by removing the need to run a series of http requests to 
find out the routers ip. Should this be mentioned as an example in #1 of 
the problem statement?