Comments

[acooper@…]

In July we had a discussion about this document and the post-standardization document, and the conclusion was that further discussion was needed in the IP Evolution program (see transcript below). Did that happen? Could someone summarize the results of that discussion?

I'm a bit unsure as to what we would be trying to achieve with this document, and about its framing. It seems like there are two objectives: listing the implications of consolidation onto ports 80/443, and making some recommendations based upon those implications. Listing the implications seems ok, although not useful enough on its own.

As for the recommendations, I wonder whether they are recommending steps that are not already taken in practice. For example, do we really see a proliferation of new application protocols that *aren't* using HTTP as a substrate?

As to the recommendation for access networks, this is where I see the framing issue. Sections 1 and 2 frame the problem as a proliferation of access networks blocking all ports except 80 and 443. But I don't think the problem is _how many_ access providers block these ports. All it takes is a fraction of enterprises (with a large number of users) blocking these ports to create the implications in section 3. Making a recommendation that is only likely to be followed by smaller providers, even if it gets followed by all small providers, won't fix the problem.

Alissa

Transcript from previous discussion:

6. Technical Topic: The New Hourglass (Leads: Marc Blanchet and Hannes Tschofenig)

Marc: 2 drafts on topic. draft-blanchet-internetoverhttp claims that too many access networks are only allowing port 80/443 outbound connections. The first goal of the draft was to identify the impacts. If you want to do traffic policing, it's not possible since all different traffic goes over the same ports, and you an't differentiate traffic. If you want to deploy new protocols and new transport protocols, it's not possible because there's only 2 ports.

Hannes: That specific issue depends what your QoS architecture is. You don't suddenly have many different ports. If you multiplex everything over http, you don't get that visibility into the network anymore. Was that the right thing to do?

Marc: Do a lot of address port policing.

Ross: If people are filtering all ports except two, it's almost like they're trying to block new applications.

Joel: The internet is not over HTTP. The access networks are over HTTP.

Dave: Not trying to block new apps, but are trying to constrain them.

Joel: The fact that it don's work means that by default we should be trying to filter […]

Marc: Increasing the ineffective use of IP addresses. Two non-http addresses service use 2 IP addresses on the server side.

Marc: More complex network operations, netflow graphics see only 2 ports.

Jari: That could be a feature.

Marc: User account apps have to over HTTP or websockets? Internet transport is HTTP.

Marc: WHat do we do with this draft?

Joel: Makes me uncomfortable to recommend this approach to folks.

Marc: We're in agreement. One idea is if you're inventing a new protocol, look for your transport…

Hannes: BCP 56. Even if you use HTTP, doesn't mean you have to run it on port 80.

Marc: Are we obsoleting this in the sense that this doc says you may use a different port for your HTTP traffic.

Marc: Would be characterized by what jinx of protocol you have.

Joel: Lots of protocols that aren't subject to this constraint. Things that are in a data center, it's not infrastructure. They may choose to, but I don't think we have to require or recommend it.

Joel: Not that people shouldn't use websockets, but that we shouldn't say everyone everywhere should use websockets.

Bernard: Interesting implications, media may have gone over port 80 but that's a different issue.

Marc: You're designing your own new thing, that's a standard way to do this if you're in th category of you care about this problem. Maybe it could be a BCP for access providers: please open your port.

Dave: I don't think that's sufficient. They might not be doing it to constrain the apps, but because HTTP has solved certain problems that haven't been solved in general. You can't tell them to open their ports without giving them an alternative.

Joel: Especially for enterprise operators.

Dave: For 10-20 years, at Microsoft, you've had to authenticate in order to get out.

Ross: One thing this breaks that I don't see in the draft, for splitting across multipath, routers can filter on port fields. If they're always the same, that won't work.

Marc: The other draft is draft-tschofening-hourglass.

Hannes: Over time we saw NATs and firewalls showing up. By now everyone notices that you have to take that into considerations. Certain protocols difficult to extend. Things not working through firewalls. Moving away from I to UDP and TCP, have to deal with connectivity checks. All these developments from ICE; NAT and firewalls.

Hannes: There's a question of whether IPv6 will change all this. What relates to the discussion we had yesterday is the rise of web developers feel comfortable with http and the use it for a foundation for protocol designs.

Bernard: This is frequently done but not ins standardized way. You can derail a lot of otherwise interoperable protocols through this.

Hannes: Not necessarily saying you have to use http/s. Some networks are very restrictive, think of military networks, enterprise networks that have policies most people would see in open internet. BUt that's only one part of network. While there is filtering applied to network it's not clear that developers shave to use http/s since the waist has moved again. Some data points, but not enough. Not sure switching to http in the long run will solve anything.

Hannes: Very little data available. Have a presentation this week about censorship. The message not to filter in public networks is more in line with the IAB. We heard in the hot spot session that many of the enterprise networks install fake certificates in your browser. They have control of your device.

Joel: DANE make that more interesting? You can't go to any old CA and say give me a certificate.

Hannes: I didn't look into this. Don't think it's an option to tell people not to use http/s. What would be useful is encouraging more discussions about the degree of filtering that is happening. As we tell the community, the researchers should be acknowledged, both for protocol design, and on what things work and do not work based on existing behavior.

Bernard: people assert things, ad the situation is more complicated than it looks like. Likely candidate to employ a DPI device for example. This DPI thing doesn't like websockets, or it wants its TLS to be 1.0 rather than 1.2, etc. WOuld be helpful to get some research to see what the data is.

Marc: So do we adopt on, both, merge?

Hannes: Can we provide a useful recommendation?

Joel: I gave trouble seeing what we could say that would serve the standards process.

[Dave, Jari, Joel agree would be good to move to IP Evolution]

Bernard: There have been questions in WG, and I'm not sure they've found good answers yet. There have been policy questions that keep coming up.

Dave: There's something possibly worth saying on looking for your transport at plan http/restful, websockets. One way to interpret that, not even adding new http headers.

Joel: Open question to determine whether there is work to be done, and the place to do that is the IP Evolution Program.