3 ms·

They point out that different networks have different needs: home network, deep space network, iot network, in-car network, etc. They call these "domains" (bad

They point out that different networks have different needs: home network, deep space network, iot network, in-car network, etc. They call these "domains" (bad name, as it can be confused with DNS). These networks can be isolated, or connected to the Internet trough a boundary. But each of these has specific needs, therefore they argue that interoperability should not not be strictly necessary between new protocols that are designed for a domain-specific use-case (up to now, I think every protocol had to work everywhere and be able to reach, ie, from one home network to another trough the internet[1]) In part 6, they argue that a protocol is needed to (securely/cryptographically) discover what machine belongs to which domain (this is a bit unclear, but likely to determine what domain a new machine is supposed to join, and where the domains boundaries are). [1] Which obviously wasn't the case in practice: you want to filter some packets to avoid someone on the internet playing whatever they want on your TV, or print something. You could allow anyone on your home network to do so, but not necessarily in a company network either. Such filtering has been done with firewalls, deep packet inspection, etc. until now.

MayeulC 6y ago
I'm replying separately to separate this from the explanation. Quotes from the RFC: > We conclude that it is reasonable to explicitly define limited-domain protocols, either as standards or as proprietary mechanisms, as long as they [..] clarify how the domain is defined. [...] However, [new] mechanisms are needed to support domain membership operations. > Note that this conclusion is not a recommendation to abandon the normal goal that a standardized protocol should be global in scope and able to interoperate across the open Internet. It is simply a recognition that this will not always be the case. ----- A few example use-cases that spring to my mind: in a given IoT network, every sensor could conceivably send unencrypted data if the threat model allows it. In a home network, more information could be exchanged between devices, while not being published on the internet: static addresses, device owner, location... This allows scoping the protocols, to tailor security to a threat model in a given environment, for instance, or to specific bandwidth/topology requirements. (incidentally, I find that "scope" is a way better name than "domain". I think that's a comment I'm going to send, this is an RFC after all).

MayeulC 6y ago

I'm replying separately to separate this from the explanation. Quotes from the RFC: > We conclude that it is reasonable to explicitly define limited-domain protocols, either as standards or as proprietary mechanisms, as long as they [..] clarify how the domain is defined. [...] However, [new] mechanisms are needed to support domain membership operations. > Note that this conclusion is not a recommendation to abandon the normal goal that a standardized protocol should be global in scope and able to interoperate across the open Internet. It is simply a recognition that this will not always be the case. ----- A few example use-cases that spring to my mind: in a given IoT network, every sensor could conceivably send unencrypted data if the threat model allows it. In a home network, more information could be exchanged between devices, while not being published on the internet: static addresses, device owner, location... This allows scoping the protocols, to tailor security to a threat model in a given environment, for instance, or to specific bandwidth/topology requirements. (incidentally, I find that "scope" is a way better name than "domain". I think that's a comment I'm going to send, this is an RFC after all).