Subject: [Netrqmts] IETF 105 Minutes

From: Russ Housley <[email-masked]>
Date: Tue, 30 Jul 2019 12:26:12 -0400

https://datatracker.ietf.org/meeting/105/materials/minutes-105-netrqmts-00

Please review.  Send corrections to this mail list.

Russ

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 30 Jul 2019 17:48:30 +0000

No changes - looks accurate. It'd be good if someone, such as from the NOC, could circulate a 1st draft of the survey questions for the 3 separate surveys:
1 - IETF Meeting Venue Network Preferences
2 - IETF Hotel Network Preferences
3 - Terminal Room Preferences and Usage 

On #3 - Terminal Room (TR), here are some I drafted based on my notes during the meeting at IETF-105:
- Have you used the TR before (at this or any prior IETF) or is this your first time? [prior user / first time]
- Do you regularly use the TR at each IETF meeting, or only as needed? [regular user / as needed]
- This week, have you used or do you plan to use the TR more than once? [frequent user / one time user]
- Does your use of the TR depend on whether or not you stayed at the primary IETF hotel, such that if you are NOT at the primary IETF hotel you use the TR between WG sessions? [yes, use TR when not at IETF hotel / no, my usage does not change based on my hotel accommodations]
- Does whether the IETF meeting venue has sufficient common area seating influence your use of the TR, such that if the venue has less common area seating you are more likely to use the TR? [yes, less common seating = more likely to use TR / no]
- Do you depend on having a printer in the TR? [yes / no]
- Do you require a wired Ethernet in TR or is WiFi sufficient? [MUST have Ethernet / WiFi is fine]
- Do you depend on 24-hour access to the TR? [Yes, need 24-hour access / No, during regular IETF meeting hours is fine]
- When you use the TR, do you use the power strips to charge / power your devices? [yes / no]
- If the TR was eliminated, how would that affect you? [My IETF week would be less effective / I could not do my regular job / I don't care whether or not there is a TR]
- Are there any unmet TR requirements or preferences that you have? [free form text]
- Are there any current TR features that should be eliminated? [free form text]
- Do you have any other comments? [free form text]

Also regarding the Terminal Room, we should decide if someone is asked to take the survey each time they visit the room or once for the entire week. I may recommend we at least advertise the need for a survey in the terminal room itself with the survey URL - and a call to action. For example: "The IETF is current re-evaluating our needs for a Terminal Room and what attendees find most useful. Please complete a survey on your usage of the Terminal Room at XXXXX." 

JL

On 7/30/19, 12:26 PM, "Netrqmts on behalf of Russ Housley" <[email-masked] on behalf of [email-masked]> wrote:

    
    Russ
    
    -- 
    Netrqmts mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netrqmts

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2019 15:20:03 -0400

I didn't go to this BOF at the last minute due to a conflict.
thanks for the notes.  I haven't seen the slides or watched the video yet.

>   ???: To get my job done without a real network, I'd be three levels
>    deep in SSH tunnels. The question is how much this gets in the way.

+5.
I find that the most important thing that the IETF meeting (network) does for
people, is that it gives them an idea what a real end-to-end transparent
network *can* be like.  Suddenly things that never worked for them work.

>   Lars: We can overengineer the network.  We could provide less and we
>     would still have less.  The network is awesome.  We could scale
>     back a little.  Our bar is so high we exclude venues that might be
>     cheaper.  I can run certbot on a laptop and renew a cert.  Do I
>     need that?  Not really.

Until IPv6 is ubiquitously available in the guest rooms, I don't know how we
can do less.  I agree that we shouldn't have to do so much... but Bob Hinden is right!

If we are going to continue to make such investments, can we somehow do so in
a useful way?   Can we collaborate with the hotel to make changes that persist?  
This goes into returning to the same hotels regularly, and *is* a mtgvenue
discussion, not a netrqmts discussion.

I think that we should split up the discussion into perhaps four areas.

1) the L2/WiFi coverage of the meeting rooms for IETF participants

2) the availability of IPv6 in the guest rooms [I don't mind captive portals,
   *if* they follow our WG's specification...]
   
3) the availability and flexibility of the bandwidth in/out of the conference
   hotel(s).

4) the architectural requirements for good IPv6 and good meetecho experience
   within the venue.

I think that the document tries to do this, but I don't get the impression
the discussion split things up.

One could imagine a situation where the Meetecho network was a different
network from the Participant network.  I'm not saying that's a good plan, but
I'm saying that I think that we should think about whether we are expending
a lot of effort in one area for reasons that are relating to another area.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jul 2019 22:24:39 +0200

> network *can* be like.  Suddenly things that never worked for them work.

As i said in my prior mail to this list (which went without any reply),
most people nowadays wouldn't even know what it means to be directly on
the internet without any firewall, and i really question whether it is
prudent to ONLY have this option and NOT document it very clearly to all
those users not working at the network level. I also think that folks
who want to test if their applications work well and invested into
ICE/STUN and other firewall traversal mechanisms (like RTCweb and other
app groups), would maybe like to have something more reflective of
relevant end-user access (with firewall).

As much as we network layer nerds may like it, we should understand and
acknowledge that it doesn't represent a reasonable end-user-device
access method to not have any firewall. And i am mostly concerned about 
all those company notebooks used in IETF which too would expect even at starbucks
to have some degree of protection against scanning attacks. At leat on
one SSID.

> discussion, not a netrqmts discussion.

I am already surprised how much the IETF noc team has been able to work
with hotels existing AP and access-LAN infrastructure and make it work
as good as possible. I do not always like the results (like in
montreal), but lets not underestimate the complexity of the job of the
noc doing this. 

> 4) the architectural requirements for good IPv6 and good meetecho experience

Where would the discussion about what type of security options to offer/
document fit ?

> a lot of effort in one area for reasons that are relating to another area.

Not sure what other think to be meetecho problems. I only thoght the
video quality from remote participants sucked but didn't get an answer
whether thats because of unavoidable remote participant upstream limits
or application level enforced uper bandwidth/quality limits.

Cheers
     Toerless

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2019 18:08:45 -0400

Toerless Eckert <[email-masked]> wrote:
    >> +5.  I find that the most important thing that the IETF meeting
    >> (network) does for people, is that it gives them an idea what a real
    >> end-to-end transparent network *can* be like.  Suddenly things that
    >> never worked for them work.

    > prudent to ONLY have this option and NOT document it very clearly to

We used to see those people, they were in the terminal room re-installing
windows 98.   Those days are over.  Firewalls have not prevents 14B a year of
damage from trojans, and they never will as long as the MIME Security
Considerations continues to be ignored.

    > all those users not working at the network level. I also think that
    > folks who want to test if their applications work well and invested
    > into ICE/STUN and other firewall traversal mechanisms (like RTCweb and
    > other app groups), would maybe like to have something more reflective
    > of relevant end-user access (with firewall).

A $22 home router fixes that problem.

    >> If we are going to continue to make such investments, can we somehow
    >> do so in a useful way?  Can we collaborate with the hotel to make
    >> changes that persist?  This goes into returning to the same hotels
    >> regularly, and *is* a mtgvenue discussion, not a netrqmts discussion.

    > montreal), but lets not underestimate the complexity of the job of the

I have been a NOC volunteer in decades past, and I've been involved in
pulling "Long Range Ethernet" into places... at 4m vertical/floor, and 100m
total for GbE over copper,  the 30th floor of some hotels was a problem.
(Atlanta...)
We aren't having to do this anymore.

    >> 2) the availability of IPv6 in the guest rooms [I don't mind captive
    >> portals, *if* they follow our WG's specification...]
    >> 
    >> 3) the availability and flexibility of the bandwidth in/out of the
    >> conference hotel(s).
    >> 
    >> 4) the architectural requirements for good IPv6 and good meetecho
    >> experience within the venue.

    > Where would the discussion about what type of security options to
    > offer/ document fit ?

I'd put them in /dev/null.
I think that IETF participants are adults, and don't need this, and
I don't think the IETF should take on the liability of offering anything that
probably won't really help anyway.

    >> I think that the document tries to do this, but I don't get the
    >> impression the discussion split things up.
    >> 
    >> One could imagine a situation where the Meetecho network was a
    >> different network from the Participant network.  I'm not saying that's
    >> a good plan, but I'm saying that I think that we should think about
    >> whether we are expending a lot of effort in one area for reasons that
    >> are relating to another area.

    > or application level enforced uper bandwidth/quality limits.

Meetecho gets wired infrastructure into each meeting room.  
If not for that, if the hotel had decent Access Points, then we might not
have to wire the meeting rooms at all.  If the hotel had large enough
capacity Internet, but perhaps too poor (bufferbloated) latency, we might be
able to get by providing an appropriate network for Meetecho only via other
means.

I know that Meetecho is used at other conferences, and I assume that those
conferences do not bring the same kit that IETF brings, so I wonder what they
do there, and what problems we are avoiding.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jul 2019 00:23:40 +0200

> Considerations continues to be ignored.

Be that as it may. Whats the point of presenting an access thats
different from 99.999% of what users are experienced to ?

> A $22 home router fixes that problem.

Sure, but why would i have to bring my own WiFi<->WiFi home router to
the IETF to give me that function for the company notebook.

> We aren't having to do this anymore.

Sure, but in return you're presented with all type of crappy
pre-existing L2 WiFi/LAN setup from the hotel, right ? Thats at least
what i was told when i asked about the Montreal setup. Sure, its
replacing real physcial labor with solving likely often proprietary
vendor configuration riddles. But impressive either way.

> probably won't really help anyway.

Well, i think it does need at least to be documented better. And
actually asking the complete set of IETF attendents more formally via
something like a SurveyMoneky, would give more insight what they are
thinking after they have been educated.

> able to get by providing an appropriate network for Meetecho only via other

I guess the best thing i could think of would be to have a BCP RFC for
how hotels should build out their network infrastructure to be best
prepared for conferences/workshops etc. This could easily proliferate to
all the big hotel chain network people if many of us would just continue
to ask other conferences to check that document and discuss with the
hotel they are using. The Meetecho example would be excellent to justify
a better buildout. Likewise the need to easily be able to set up
multiple SSID, have easily accessible policies for multicast/broadcast
policing (the issue we had in Montreal), IMHO also private-VLAN style
security, and so on and so forth. But if we only pick to mention one
particular narrow and very IETF centric security model, i don't think
such a document would be seen as too useful.

> do there, and what problems we are avoiding.

Right.

Toerless

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2019 18:42:24 -0400

> the IETF to give me that function for the company notebook.

Laptops are regularly attacked at the Coffee Shop from BEHIND the NAT44
"firewall".  No firewall the IETF provides will solve that.

As your company IT guy why they gave you an insecure laptop for travel.
So seriously, go ask them.  NOT AN IETF PROBLEM.
Better yet, bring your company IT guy to IETF, so that they learn what's it
like to be connected to the actual Internet. As you say, most have never been online.

    > prepared for conferences/workshops etc. This could easily proliferate

It's a great idea, and I sure wish it would occur.

To be effective, they hotel chains would need to solicit this document, and
pay a significant figure for the consulting.  Otherwise, they will ignore it.

capport WG has been struggling for attention of the same types.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jul 2019 00:58:43 +0200

> "firewall".  No firewall the IETF provides will solve that.

That IMHO today an untypical and recgonizeable bad hotspot setup.

> So seriously, go ask them.  NOT AN IETF PROBLEM.

Providing access that is less secured than what users can normally
expect at work/hotspots/home is an explicit IETF choice, and i am
questioning why people would think its a good idea to only provide that
choice.

> like to be connected to the actual Internet. As you say, most have never been online.

Nobody connects endpoint to the actual Internet without firewalls in between.

Yes, a good travel notebook should have that firewall built-in. Many may
be good. Windows probably a lot better than Linux. But its a kind of
strange policy to provide such an uncommon type of access without
communicating it clearly to the whole community and understanding their
preferences.

> pay a significant figure for the consulting.  Otherwise, they will ignore it.

If a lot of conferences would refer to it, the hotels would not ignore
it. Otherwise we might worst case support the business model of useless
consultants reading our doc, and recommending its points for a lot of
money to hotels.

But yes, its work, so the question is whether there is enough critical
mass to write it.

> capport WG has been struggling for attention of the same types.

I think thats a fundamentally different problem space.

To automate the captive portal problem, you need to be able to tie every
IoT devices authenticatication to some poor human, who forcefully has to absorb the
advertisement of the portal and bear legal responsiblity requested by
the portal. So pretty much you need a mobile phone app and cloud broker
where iot device manufacturer can hire middle school kids that will then
continuously watch advertisement clips from those portal operators and
whose parents will pay the bail when the kid has to go to jail for
something the IoT device did do wrong.

Or else the business model of the captive portal has to change.

Cheers
    toerless

-- 
---
[email-masked]

---

From: Alessandro Amirante <[email-masked]>
Date: Wed, 31 Jul 2019 11:27:42 +0200

> do there, and what problems we are avoiding.

Meetecho is mostly used at other conferences for _streaming_ only, not 
for actual _remote participation_. I.e., no remote audio/video injection 
into the physical room, no virtual queue. RTC servers are not deployed 
on site. A good uplink bandwidth from the conference venue is still 
required.

At IETF, Meetecho deploys remote participation servers at the meeting 
venue mainly for two reasons:
	1. minimize the delay, which is critical to have remote participants 
participate to Q&A or give presentations;
	2. feed them with audio+video from the meeting rooms via LAN, over a 
dedicated vLAN, so to not be affected by packet loss and external 
network conditions.

Alessandro

-- 
Alessandro Amirante, Ph.D.

Meetecho S.r.l.
www.meetecho.com

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 31 Jul 2019 13:12:56 +0000

>    We used to see those people, they were in the terminal room re-installing
    windows 98.   

It's not really for us to decide or judge IMO. I'd suggest we simply include a question in this area to gauge user preferences at the IETF and let their responses guide what sorts of network features & types are offered. 

Jason

---

From: Alessandro Amirante <[email-masked]>
Date: Wed, 31 Jul 2019 15:22:08 +0200

> Nobody connects endpoint to the actual Internet without firewalls in between.

This can be true for IPv4. It isn't for IPv6. I've had a NAT-ted v4 
address and a public v6 address for quite some time, both at home and at 
the office.

A.

-- 
Ing. Alessandro Amirante, Ph.D.

Meetecho S.r.l.
www.meetecho.com

Via Riviera di Chiaia 124
80122 Napoli, Italy

Mobile: +39 329 6178743
E-mail: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2019 14:27:30 -0400

> A $22 home router fixes that problem.

Actually, I realized in the shower this morning, that the ietf-nat64 
network provides all the "security" of a home router, in that TCP SYN 
packets leave, but can never enter.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2019 14:32:25 -0400

Alessandro Amirante <[email-masked]> wrote:
    >> I know that Meetecho is used at other conferences, and I assume that
    >> those conferences do not bring the same kit that IETF brings, so I
    >> wonder what they do there, and what problems we are avoiding.

    > for actual _remote participation_. I.e., no remote audio/video
    > injection into the physical room, no virtual queue. RTC servers are not
    > deployed on site. A good uplink bandwidth from the conference venue is
    > still required.

Thanks for this update.
Can you explain the reasons why other conferences/meetings do not do remote
participation?  Is it economic (too expensive for them), or just logistical
(it's unidirectional slideware really), or it is because they lack a
real Internet connection, and so you can't even consider discussing it.

    > 1. minimize the delay, which is critical
    > to have remote participants participate to Q&A or give presentations;

I can't estimate what about of incremental work this requirement causes
for the NOC over what we do *today*.  I suspect it's non-trivial, but
not complex.

Clearly, if we had a fully NAT44 network that most other meetings have, that
we'd be looking at more effort.  Either bringing in real networking, or
having some cloud component.

This is, I think, an example of synergies that we get from having a real
network.  We are lowering the bar for things like Meetecho, but we might
never consider doing this just for Meetecho.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jul 2019 20:33:55 +0200

Right. Kinda unavoidable in that case. But lets ignore IPv4.
The question really is whether we should going forward expect all
network connected devices to have a firewall themselves, and if so,
what, and if not, then what should the network in front of them do.
Thats at least the IETF stds. relevant conversion of my ask.

McAffee on this one:

https://www.amazon.com/Grillbot-Automatic-Cleaning-Carrying-Accessories/dp/B01HJCQ3D4/ref=asc_df_B01HJCQ3D4/?tag=hyprod-20&linkCode=df0&hvadid=167125192708&hvpos=1o4&hvnetw=g&hvrand=7572155483155878630&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032151&hvtargid=pla-340511541004&psc=1

;-))

Someone should do a web-page/blog on "worst IoT ideas".

Cheers
    Toerless

On Wed, Jul 31, 2019 at 02:27:30PM -0400, Michael Richardson wrote:
> Actually, I realized in the shower this morning, that the ietf-nat64 network
> provides all the "security" of a home router, in that TCP SYN packets leave,
> but can never enter.
> 
> 
> 
> -- 
> Netrqmts mailing list
> [email-masked]

-- 
---
[email-masked]

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 31 Jul 2019 19:26:31 +0000

Jason, 

We (the NOC) will work up a draft of the survey. I am mostly offline this week so apologies in advance for digging into the rest of this thread early next week.

Karen

> On Jul 30, 2019, at 1:48 PM, Livingood, Jason <[email-masked]> wrote:
>

---

From: Alessandro Amirante <[email-masked]>
Date: Wed, 31 Jul 2019 21:29:14 +0200

---- Michael Richardson ha scritto ----

> real Internet connection, and so you can't even consider discussing it.

They are conferences: they're not interested in having remote participants contribute with questions or even presentations. My guess is that they want people to show up in person, pay the conference fee...

I'd love to push remote participation to other SDOs, though!

A.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2019 16:55:12 -0400

Alessandro Amirante <[email-masked]> wrote:
    >> Alessandro Amirante <[email-masked]> wrote: >> I know that Meetecho
    >> is used at other conferences, and I assume that >> those conferences
    >> do not bring the same kit that IETF brings, so I >> wonder what they
    >> > Meetecho is mostly used at other conferences for _streaming_ only,
    >> not > for actual _remote participation_. I.e., no remote audio/video >
    >> injection into the physical room, no virtual queue. RTC servers are
    >> not > deployed on site. A good uplink bandwidth from the conference
    >> venue is > still required.
    >> 
    >> Thanks for this update.  Can you explain the reasons why other
    >> conferences/meetings do not do remote participation?  Is it economic
    >> (too expensive for them), or just logistical (it's unidirectional
    >> slideware really), or it is because they lack a real Internet
    >> connection, and so you can't even consider discussing it.

    > They are conferences: they're not interested in having remote
    > participants contribute with questions or even presentations. My guess
    > is that they want people to show up in person, pay the conference
    > fee...

    > I'd love to push remote participation to other SDOs, though!

Thank you for the reply.
Making our use of Meetecho more similar to other users is probably good for
all of us.  If that means encouraging others to be more like us, then fine :-)

If the networks that we "upgrade" in conference centers make that easier,
that's something... as we would be improving the Internet :-)

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 31 Jul 2019 22:38:48 +0000

> On Jul 31, 2019, at 14:27, Michael Richardson <[email-masked]> wrote:
> 
> Actually, I realized in the shower this morning, that the ietf-nat64 network provides all the "security" of a home router, in that TCP SYN packets leave, but can never enter.

Not exactly.  You still have a public IPv6 address on this network.  IPv6 TCP SYNs can still enter.

Joe

---

From: Michael Breuer <[email-masked]>
Date: Thu, 1 Aug 2019 08:53:26 +0200

Hej,

> On 1. Aug 2019, at 00:38, Joe Clarke (jclarke) <[email-masked]> wrote:
> 

That’s exactly how my home network works, I get public IPv6 open to/from the internet. My ISP offers a „security“ feature which includes some basic firewall but also dns redirects (you get redirected to the ISP‘s portal page in case of missing dns etc, generating ad revenue for them). I switched that off.

Michael