Ouroboros - Revision history

Dimitri: /* How is this supposedly going to work? */

2024-11-08T08:08:06Z

How is this supposedly going to work?

← Older revision		Revision as of 08:08, 8 November 2024
Line 46:		Line 46:
	Once in possession of a freshly minted service name and its certificate, it can be ''registered'' in one or more Ouroboros network at certain locations. There's a lot more to it, but just assume that these locations are at certain network addresses<ref>It is important to note, however, that the location is ''not'' specified by an address while registering.</ref>. The naming system of the O7s network (called the ''directory'') stores the address(es) together with the service name certificate.		Once in possession of a freshly minted service name and its certificate, it can be ''registered'' in one or more Ouroboros network at certain locations. There's a lot more to it, but just assume that these locations are at certain network addresses<ref>It is important to note, however, that the location is ''not'' specified by an address while registering.</ref>. The naming system of the O7s network (called the ''directory'') stores the address(es) together with the service name certificate.

	To communicate with a service, the client application needs to request a ''flow'' to that service from the Ouroboros system. The system will figure out in which networks that service is registered (if any) and where in the network it is by quering network directories. If one responds, the client side O7s system will know 3 things:		To communicate with a service, the client application needs to request a ''flow'' to that service from the Ouroboros system. The system will figure out in which networks that service is registered (if any) and where in the network it is by quering network directories. If (at least) one responds, the client side O7s system will know 3 things:

	# the O7s network(s) in which the service is available		# the O7s network(s) in which the service is available

Dimitri: /* Ouroboros characteristics */

2024-11-07T09:01:00Z

Ouroboros characteristics

← Older revision		Revision as of 09:01, 7 November 2024
Line 61:		Line 61:

	= Ouroboros characteristics =		= Ouroboros characteristics =

			The following should be possible with a full implementation:

	Cryptographic primitives retrieved from naming system instead of peers		Cryptographic primitives retrieved from naming system instead of peers

Dimitri: /* Ouroboros characteristics */

2024-11-07T08:32:00Z

Ouroboros characteristics

← Older revision		Revision as of 08:32, 7 November 2024
Line 62:		Line 62:
	= Ouroboros characteristics =		= Ouroboros characteristics =

	~~Application name first, cryptographic~~ primitives retrieved ~~when querying a name~~		Cryptographic primitives retrieved from naming system instead of peers
	* authenticated connection establishment		* authenticated connection establishment
	* authentication before first byte = zero trust of network hosts		* authentication before first byte = zero trust of network hosts

Dimitri: /* Ouroboros characteristics */

2024-11-07T08:30:57Z

Ouroboros characteristics

← Older revision		Revision as of 08:30, 7 November 2024
Line 62:		Line 62:
	= Ouroboros characteristics =		= Ouroboros characteristics =

	O7s has '''no well-known ports''', ephemeral endpoint identifiers (EIDs) ~~are defined at the model's [[Ouroboros Functional Layering\|network end-to-end layer]] and~~ are (randomly) assigned ~~at runtime - the sole exception is the~~ flow ~~allocator at EID 0~~. This implies:		Application name first, cryptographic primitives retrieved when querying a name
	* no direct tie between ~~the~~ network protocols and certain application, and thus no need to 'standardize' ~~certain~~ values ~~for certain identifiers (Ethertype/protocol/port)~~.		* authenticated connection establishment
	* no need to define, track and/or de-conflict port values when ~~setting up~~ networked applications		* authentication before first byte = zero trust of network hosts
	* no hacks such as port-scanning a server for (vulnerable) applications
			O7s has no '''well-known ports''', ephemeral endpoint identifiers (EIDs) are(randomly) assigned during flow allocation. This implies:
			* no direct tie between network protocols and a certain application, and thus no need to 'standardize' EID values.
			* no need to define, track and/or de-conflict port values when configuring networked applications.

	The flow allocator is a '''single point of contact''':		The flow allocator is a '''single point of contact''':

Dimitri at 08:21, 28 September 2024

2024-09-28T08:21:17Z

← Older revision		Revision as of 08:21, 28 September 2024
Line 36:		Line 36:
	On an abstract level, the Internet model is rife with internal contradictions and inconsistencies. Examples abound of protocols that are jammed into the model without fitting - if IP is L3, how is ICMP also L3 as it runs on top of IP? Such contradictions hint at an incomplete understanding of fundamental rules that underly all packet networks.		On an abstract level, the Internet model is rife with internal contradictions and inconsistencies. Examples abound of protocols that are jammed into the model without fitting - if IP is L3, how is ICMP also L3 as it runs on top of IP? Such contradictions hint at an incomplete understanding of fundamental rules that underly all packet networks.

	There is no incremental path to fix the Internet starting from TCP/IP~~. TCP/IP implementations does not potentially contain CVE's. By nature of its architecture TCP/IP ''is'' a CVE~~.		There is no incremental path to fix the Internet starting from TCP/IP.

	In a nutshell, our objectives are to simplify and reduce network and service configuration and prevent ossification, and to do this by cleaning up and polishing the architecture and its protocols.		In a nutshell, our objectives are to simplify and reduce network and service configuration and prevent ossification, and to do this by cleaning up and polishing the architecture and its protocols.

Dimitri: /* Motivation and Objectives */

2024-09-28T08:16:50Z

Motivation and Objectives

← Older revision		Revision as of 08:16, 28 September 2024
Line 36:		Line 36:
	On an abstract level, the Internet model is rife with internal contradictions and inconsistencies. Examples abound of protocols that are jammed into the model without fitting - if IP is L3, how is ICMP also L3 as it runs on top of IP? Such contradictions hint at an incomplete understanding of fundamental rules that underly all packet networks.		On an abstract level, the Internet model is rife with internal contradictions and inconsistencies. Examples abound of protocols that are jammed into the model without fitting - if IP is L3, how is ICMP also L3 as it runs on top of IP? Such contradictions hint at an incomplete understanding of fundamental rules that underly all packet networks.

	~~In a nutshell, our objectives are~~ to ~~simplify and reduce network and service configuration and prevent ossification, and to do this by cleaning up and polishing~~ the architecture ~~and its protocols~~.		There is no incremental path to fix the Internet starting from TCP/IP. TCP/IP implementations does not potentially contain CVE's. By nature of its architecture TCP/IP ''is'' a CVE.

	~~There is no incremental path~~ to ~~fix~~ the ~~Internet starting from TCP/IP. TCP/IP implementations does not potentially contain CVE's, TCP/IP ''is'' a CVE~~.		In a nutshell, our objectives are to simplify and reduce network and service configuration and prevent ossification, and to do this by cleaning up and polishing the architecture and its protocols.

	= How is this supposedly going to work? =		= How is this supposedly going to work? =

Dimitri: /* Motivation and Objectives */

2024-09-28T08:15:47Z

Motivation and Objectives

← Older revision		Revision as of 08:15, 28 September 2024
Line 38:		Line 38:
	In a nutshell, our objectives are to simplify and reduce network and service configuration and prevent ossification, and to do this by cleaning up and polishing the architecture and its protocols.		In a nutshell, our objectives are to simplify and reduce network and service configuration and prevent ossification, and to do this by cleaning up and polishing the architecture and its protocols.

	''There is no incremental path to fix the Internet starting from TCP/IP''. TCP/IP implementations does not potentially contain CVE's, TCP/IP ''is'' a CVE.		There is no incremental path to fix the Internet starting from TCP/IP. TCP/IP implementations does not potentially contain CVE's, TCP/IP ''is'' a CVE.

	= How is this supposedly going to work? =		= How is this supposedly going to work? =

Dimitri: /* Motivation and Objectives */

2024-09-28T08:15:21Z

Motivation and Objectives

← Older revision		Revision as of 08:15, 28 September 2024
Line 38:		Line 38:
	In a nutshell, our objectives are to simplify and reduce network and service configuration and prevent ossification, and to do this by cleaning up and polishing the architecture and its protocols.		In a nutshell, our objectives are to simplify and reduce network and service configuration and prevent ossification, and to do this by cleaning up and polishing the architecture and its protocols.

	''There is no incremental path to fix the Internet starting from TCP/IP''.		''There is no incremental path to fix the Internet starting from TCP/IP''. TCP/IP implementations does not potentially contain CVE's, TCP/IP ''is'' a CVE.

	= How is this supposedly going to work? =		= How is this supposedly going to work? =

Dimitri at 20:28, 12 August 2024

2024-08-12T20:28:56Z

← Older revision		Revision as of 20:28, 12 August 2024
Line 59:		Line 59:

	This framework allows for many small (and not-so-small) simplifications to protocols and APIs used in the current TCP/IP network stack.		This framework allows for many small (and not-so-small) simplifications to protocols and APIs used in the current TCP/IP network stack.

	~~= Do you guys think you can replace TCP/IP? =~~
	No-one can replace TCP/IP. We think the TCP/IP stack is - from a modern day perspective - incredibly rickety. All we can do is take what we learned over the past 25 years and try to come to a better integrated solution for secure and reliable end-to-end packet networking. We have no control over technology adoption, all we can do is provide a possible path for it. Ouroboros runs fine as an overlay on top of TCP/IP. There is no need to throw out your routers and switches. Replacing TCP/IP is not up to us, it's completely up to you.

	= Ouroboros characteristics =		= Ouroboros characteristics =

Dimitri: /* Motivation and Objectives */

2024-08-11T13:19:46Z

Motivation and Objectives

← Older revision		Revision as of 13:19, 11 August 2024
Line 32:		Line 32:
	Core Internet technology itself has become ''ossified''; the core protocols haven't changed much in 30 years because making changes that are easy in theory, such as adding a new L3 protocol (IPv6) has become a decades-long slog. There are many ''layer violations'' creating unnecessary and unwanted ties between different layers in the model: L2 (Ethertype), L3 (protocol field), L4 (well-known ports) and L5 (struct sockaddr_in/_in6). A change in one of the layers permeates all the way through the network stack. To make things worse, standardization and research bodies have been established along the (blurry) demarcation lines of the 5-Layer Internet model. [https://en.wikipedia.org/wiki/Conway%27s_law Conway's Law] prevents any significant architectural or structural innovations from taking root.		Core Internet technology itself has become ''ossified''; the core protocols haven't changed much in 30 years because making changes that are easy in theory, such as adding a new L3 protocol (IPv6) has become a decades-long slog. There are many ''layer violations'' creating unnecessary and unwanted ties between different layers in the model: L2 (Ethertype), L3 (protocol field), L4 (well-known ports) and L5 (struct sockaddr_in/_in6). A change in one of the layers permeates all the way through the network stack. To make things worse, standardization and research bodies have been established along the (blurry) demarcation lines of the 5-Layer Internet model. [https://en.wikipedia.org/wiki/Conway%27s_law Conway's Law] prevents any significant architectural or structural innovations from taking root.

	The Internet is not a friendly place. Deploying a service over the Internet is more akin to venturing out into a lawless warzone than taking a nice stroll in the friendly neighborhood park. The first thing on any dotcom entrepreneur's mind is cybersecurity (quickly followed by how much it's going to cost him or her when the inevitable security breach comes). We would argue that the reason that the Internet has become ossified is also the reason for many network-level exploits: its bloated protocols rolled out the red carpet for cybercrime, cyberterrorism and cyberwarfare. TCP/IP has enabled an Internet that is robust to physical attacks on its infrastructure but left vulnerable to cyberattacks on its services~~. The Internet ecosystem is expertly divided so that any responsibility for security flaws can always be passed onto the next link down the supply chain. It shouldn't be~~. Unless we revise its architecture and core protocols, mitigating cyberthreats will remain a perpetual arms race between application developers, service providers and malicious hackers<ref>[https://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho/ The DDoS That Knocked Spamhaus Offline (And How We Mitigated It)]</ref>.		The Internet is not a friendly place. Deploying a service over the Internet is more akin to venturing out into a lawless warzone than taking a nice stroll in the friendly neighborhood park. The first thing on any dotcom entrepreneur's mind is cybersecurity (quickly followed by how much it's going to cost him or her when the inevitable security breach comes). We would argue that the reason that the Internet has become ossified is also the reason for many network-level exploits: its bloated protocols rolled out the red carpet for cybercrime, cyberterrorism and cyberwarfare. TCP/IP has enabled an Internet that is robust to physical attacks on its infrastructure but left vulnerable to cyberattacks on its services. Unless we revise its architecture and core protocols, mitigating cyberthreats will remain a perpetual arms race between application developers, service providers and malicious hackers<ref>[https://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho/ The DDoS That Knocked Spamhaus Offline (And How We Mitigated It)]</ref>. The Internet ecosystem is so expertly divided so that any responsibility for security flaws can always be passed onto the next link down the supply chain. It shouldn't be.

	On an abstract level, the Internet model is rife with internal contradictions and inconsistencies. Examples abound of protocols that are jammed into the model without fitting - if IP is L3, how is ICMP also L3 as it runs on top of IP? Such contradictions hint at an incomplete understanding of fundamental rules that underly all packet networks.		On an abstract level, the Internet model is rife with internal contradictions and inconsistencies. Examples abound of protocols that are jammed into the model without fitting - if IP is L3, how is ICMP also L3 as it runs on top of IP? Such contradictions hint at an incomplete understanding of fundamental rules that underly all packet networks.