[e2e] What if there were no well known numbers?

[Jon Crowcroft]

history aside...

the reason this is a hot(ish) topic is that we moved from
having identifiers in packets to tell you where a packet should go 
(next hop, next subnet, host, process on post, etc etc)
to  mechanisms to STOP a packet going where you don't want it next.

As the arms race in attack and defense moves on, people have re-leared systems lessons 
(e.g. default off) and distributed systems lessons (e.g. early binding) so the way identifiers 
that can be used to make forwarding versus filtering decisions
ought to work for the majority case which has changed.

this, aside from the additional functioanlity we've tried to heap on IP (e.g. mobility and multicast)
means that the semantics (such as they are) of ports and addresses are no so complex (and context dependant)
that you cannot say what a packet means at some point in the net (hence it is dificult to build systems to stop
ddos, topological attacks, spam, etc etc, but also it is dificult to build policy control for things like mobile
and multicast ip)...

from the point of view of easy of programming with defauls, well-knownness is a quick and dirty bootstrap that made
sense...but
well known-ness is just the other side of a coin of security through obscurity when it comes to nats, firewals etc

anyhow, most the apps people have built in this post-rfc-relevance era 
work with dynamic ports and work through nats so de facto, if not de jure,
we know we didnt need well known ports (or globally significant IP addresses:)
for the internet to work - but we probably did need them to bootstrap stuff while everyone was
getting used to the idea of an open programmable data net:)

having services that describe themselves by their actions might be cute (c.f all the programmes that will use TCP
behaviours to tell you what OS someone is running:) - can we take that idea further..? and retain low latency/small
number of packets to startup a service?

oh and I think we should have an explicit protocol for establishing a
capability to _receive_
ip packets

chrs

j.