Subject: [Mtgvenue] filtering, take 32

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Aug 2017 15:57:11 +0200

Hi everyone,

I've had some offline conversations, and let's try this again.  What I
think we are after is as definitive text as we can get, relating to this
specific issue, which is really the one outstanding issue we have left
in the draft.  To reiterate Andrew's point: the text in the draft
provides too big an out for governments to require filtering.  We want
to send a stronger signal.  To reiterate Stephen's point, when filtering
is required in a Venue we are considering, the community should be
consulted.

To address both of their concerns, as well as make the requirement
clear, I now propose to split it into two sentences.  The first
addresses the need for confidentiality of communications.  I don't think
anyone here wants us to go to a place that REQUIRES that we break our
own encryption, for instance.  Second,  when filtering is going to be
used, we are not yet to the point where we can draw a clear line for all
cases.  We need more experience where such issues arise.  And so, here's
what I'm proposing:

> Internet service to the Facility and IETF Hotels MUST NOT require
> exposing of any communications between participants and each other or
> their customers and partners. The IASA MUST consult the community
> prior to making a decision about any venue that would interfere with
> communications between participants and each other or their partners
> or customers.

To be clear, we do not really want the IASA querying us TOO much.  It's
slow, leads to habituation, and often gets us into a meta meta
discussion, which for me is two metas too many.  This requirement for
consultation itself will probably encourage selection of venues where a
consultation is not necessary.  But this text also leaves open the door
for the community to decide that certain forms of filtering are
acceptable in certain instances (think BCP-38, for instance), and allows
for us to evolve our views based on the circumstances.  It also doesn't
require chapeau changes that might require a fuller review of all
requirements in the doc.

Thoughts?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Aug 2017 10:26:32 +1200

On 30/08/2017 01:57, Eliot Lear wrote:
...

> Second,  when filtering is going to be

Generally, I agree with the intent. Two comments:

1) I suggest "third parties" instead of "their customers or partners",
to cover all the bases.

2) Does NAT interfere with communications? Or again, is BCP38 filtering
considered "interference"? I think there needs to be a little wiggle
room in the second sentence; otherwise the IASA will have to consult
about every little thing.

(cf RFC4084 and the IAB's interest in updating it.)

    Brian

---

From: Jim Martin <[email-masked]>
Date: Tue, 29 Aug 2017 19:12:03 -0400

> On Aug 29, 2017, at 9:57 AM, Eliot Lear <[email-masked]> wrote:
> 
Eliot,
	I fear we’ve gone too far down the rabbit hole here (*). What we want is for our attendees to have appropriate connectivity to allow them to work and do their day-to-day Internet activities, which for our crowd also means being able to prototype and experiment with new protocols. I and my team have taken that to mean that we need:

	- Sufficient bandwidth to the greater Internet
	- No middle boxes messing with traffic
	- Native public v4 and v6
	- No filtering beyond what is needed to protect the net (think OOB access to the servers) or BCP 38
	- Sufficient redundancy to handle equipment and provider failures

	In your proposed paragraph you delve into the concept of “exposing communications” … by your definition, the “ietf-legacy” SSID would have to go, as someone snooping wireless traffic would be able to see all the packets fly by. Let’s not get into what someone (Black Hat, govt, or whatever) could see if they happened to have a tap at the far end of our links, something we wouldn’t have any way of knowing.

	I think what we’re really trying to say here is that we want clean, unadulterated Internet access from the IETF. If we choose to go somewhere where we know we can’t get that, we should consult the community. It really is that simple.

	-Jim

(*) - You can take this as specifically relating to the net portions or the overall meeting selection document … your choice.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Aug 2017 00:17:30 +0100

On 30/08/17 00:12, Jim Martin wrote:
>>> Internet service to the Facility and IETF Hotels MUST NOT
>>> require exposing of any communications between participants and
>>> each other or their customers and partners. The IASA MUST consult
>>> the community prior to making a decision about any venue that
>>> would interfere with communications between participants and each
>>> other or their partners or customers.
> Eliot, I fear we’ve gone too far down the rabbit hole here (*). What
> we want is for our attendees to have appropriate connectivity to
> allow them to work and do their day-to-day Internet activities, which
> for our crowd also means being able to prototype and experiment with
> new protocols. I and my team have taken that to mean that we need:
> 
> - Sufficient bandwidth to the greater Internet - No middle boxes
> messing with traffic - Native public v4 and v6 - No filtering beyond
> what is needed to protect the net (think OOB access to the servers)
> or BCP 38 - Sufficient redundancy to handle equipment and provider
> failures
> 
> In your proposed paragraph you delve into the concept of “exposing
> communications” … by your definition, the “ietf-legacy” SSID would
> have to go, as someone snooping wireless traffic would be able to see
> all the packets fly by. Let’s not get into what someone (Black Hat,
> govt, or whatever) could see if they happened to have a tap at the
> far end of our links, something we wouldn’t have any way of knowing.
> 
> I think what we’re really trying to say here is that we want clean,
> unadulterated Internet access from the IETF. If we choose to go
> somewhere where we know we can’t get that, we should consult the
> community. It really is that simple.

I agree.

FWIW, my suggested text in an offlist exchange with Eliot was
this:

"Internet service to the Facility and IETF Hotels MUST NOT
require increased exposure of the communications of IETF
participants, compared to traditional IETF meeting network
setups. [ref] The IASA MUST consult the community as early
as possible should meeting this requirement be at risk at
any stage in meeting planning."

[ref] could be a pointer to e.g. IETF-99 n/w setup info
or something similar.

I'm not sure if that's much better or not, but while I
could live with Eliot's most recent proposal, I do think
something like the above is closer to what we want.

Cheers,
S.

> 
> -Jim
> 
> 
> (*) - You can take this as specifically relating to the net portions
> or the overall meeting selection document … your choice.
> 
> 
> 
> _______________________________________________ Mtgvenue mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/mtgvenue
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Aug 2017 22:52:52 -0400

Hi,

Replying to two messages at once.

> > community. It really is that simple.

I don't think anyone disagrees at the highest level.  But I don't
think it helps to say, "This is obvious."  There were _lots_ of things
that people thought were obvious that weren't, or else we wouldn't
have had this WG.  So, let's press a little on "clean, unadulterated"
access.

I agree that someone could sniff traffic (and, assuming it was itself
unencrypted, perhaps recover something) on the non-WPA wireless
network.  I agree that this is within our norms (your choice, your
loss).

I agree that anything approaching TLS intervention is Not Allowed.

Is content-based blocking ok?  What about for $specific_content?  What
about conditionally, knowing as we do the propensity of some
governments to collect and store all that metadata?  This all speaks
to "clean", or maybe "unadulterated", and I'm not sure we have a crisp
answer to this.

---

> any stage in meeting planning."

The nice thing about this formulation is that it draws the boundary:
the rules apply fro the Facility and IETF Hotels, and nowhere else.
It has the disadvantage that it does not prohibit the thing we don't
want _within_ the IETF network (a national authority could intervene
there), and it does not say anything about other network experiences
such as what happens from an Overflow Hotel.  Maybe that's ok; I just
want us to be clear.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 30 Aug 2017 06:56:51 +0200

Andrew, Stephen,

> such as what happens from an Overflow Hotel.  Maybe that's ok; I just

So long as someone can fill in the ref, the first sentence is fine.  The
2nd sentence should stick to the original formulation because we already
have text that covers what happens when a mandatory changes later on.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 Aug 2017 10:27:14 +0200

In the absence of a good reference for Stephen's text (which has been

>> or BCP 38 - Sufficient redundancy to handle equipment and provider

The Facility and IETF hotels MUST allow support for public IPv4 and IPv6
connectivity with sufficient bandwidth and redundancy to the Internet
for attendees to communicate without interruption or interference.  Only
BCP38 filtering and other necessary defensive filtering mechanisms as
agreed by the IASA are acceptable.  The IASA MAY make an exception to
this requirement after having consulted the community.

How about that?

Eliot

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 31 Aug 2017 10:32:29 +0200

+1

However, I will say that something such as
“The IASA MAY make an exception to
    this requirement after having consulted the community.”

should be generic for the complete document, not just for this requirement.

And, not sure if it is IASA or IAOC …

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Eliot Lear <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 31 de agosto de 2017, 10:27
Para: Stephen Farrell <[email-masked]>, Jim Martin <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [Mtgvenue] filtering, take 33 (was 32)

    
    
    How about that?
    
    Eliot
    
    _______________________________________________
    Mtgvenue mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mtgvenue

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Jim Martin <[email-masked]>
Date: Thu, 31 Aug 2017 08:43:25 -0400

> On Aug 31, 2017, at 4:27 AM, Eliot Lear <[email-masked]> wrote:
> 

   Hmm, by my reading of this, if we were getting DDoSed during a meeting I'd need to convene a meeting of IASA before I could ask the ISP to help us mitigate the attack. What are we winning by adding stricture above and beyond what I wrote when we started this whole process?

    -Jim

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 31 Aug 2017 11:20:22 -0400

On Thu, Aug 31, 2017 at 08:43:25AM -0400, Jim Martin wrote:
>    Hmm, by my reading of this, if we were getting DDoSed during a meeting I'd need to convene a meeting of IASA before I could ask the ISP to help us mitigate the attack.

Wouldn't it be enough to get a general approval from IASA for DDoS
protections and other such filtering (presumably, to be reviewed
whenever the techniques change)?  It's easy to refer to BCP38 but
harder to refer to a list that changes over time :)

> What are we winning by adding stricture above and beyond what I wrote when we started this whole process?
> 

The stricture is there to make the document an accurate portrayal of
the community expectations.

I'm not sure which text you mean by what you "wrote when we started
this whole process", but in general I think the document has gradually
been getting more concrete about the things that are and are not
permitted.  My own evaluation of text has always been done by
imaginging myself in the shoes of an IAOC member, and asking whether a
bit of text sets clear expectations for making a decision.  Much of
the early text, in my opinion, basically told the IAOC to use its
judgement or else to defer to the Meetings Committee, and since that
was the situation that obtained before this WG started I didn't think
it was an acceptable answer.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jim Martin <[email-masked]>
Date: Thu, 31 Aug 2017 12:40:33 -0400

Gentlepeople,
    Let me jump back to the beginning on this. I believe we’re trying to address the following text from 3.1:

The venue MUST provide unfiltered access to the Internet, to the extent permitted by governing laws and regulations.

	And as I understand it, the concern was that the “to the extent permitted...” was felt to provide too much of an out for restrictive legislation.  Hence, the approach was to more accurately describe what we MUST have to have an effective meeting (Since this was in the Mandatory section). I believe our absolute minimum requirements are (largely taken from my earlier message):

	- Sufficient bandwidth to the greater Internet
	- No middle boxes altering traffic (NAT, FW, Captive Portal, etc)
	- Native public v4 and v6
	- No filtering that would materially negatively impact the ability of IETF attendees to conduct their day-to-day Internet use.
	- Sufficient redundancy to handle equipment and provider failures

	I also believe that I started going down the wrong road myself, as I was interpreting these as strictures on what we do to our own network, or what we ask the providers to do on our behalf, rather than what they enforce upon us.

	Given that I’d like to propose an alternative text:

It MUST be possible (through donation or purchase) to provision Internet Access to the Meeting Venue that allows attendees to utilize the Internet for all their IETF, business, and day to day needs. This includes, but is not limited to, native and unmodified IPv4 and IPv6 connectivity, global reachability, and no additional limitation that would materially impact their Internet use. To ensure availability, it MUST be possible to provision redundant paths to the Internet.

       Thoughts?

- Jim

> On Aug 31, 2017, at 11:20 AM, Andrew Sullivan <[email-masked]> wrote:
>