> The referral problem he refers to is real, but I see it more as a consequence 
> of the IETF being too rigid in its approach to address numbering.

How would changing IETF's approach to address numbering help the referral 
problem?

> The basic question here is that we have two hosts that are to connect for a 
> peer-peer protocol in which either endpoint can initiate or respond to a 
> connection request.
> 
> 
> Clearly this is rather challenging if the boundaries between addressing 
> schemes are arbitrary and becomes somewhat simpler in a uniform addressing 
> model.
> 
> But the real Internet is not like that. It is a network of networks and 
> crossing the boundary between a private network and the interconnect space 
> between the networks has consequences.
> 
> One of those consequences is that addresses can change at the 
> private/interconnect border. Another consequence is that crossing that 
> boundary should have security consequences.

In the "real" Internet, the boundary between a private network and "the 
interconnect space" is fuzzy and arbitrary, especially from a security 
point-of-view, and becoming moreso all the time. 

> Opening up a port to receive connection requests has considerably greater 
> security consequence than making the request. The requester is opening a 
> communication channel with a single, specified entity, the responder is 
> opening access to any host on the Internet.

And far better mechanisms than "opening up a port" are feasible even within the 
classic Internet architecture.  If the industry hasn't provided them, that's 
not the fault of the architecture.

> So opening a port is an event that should be mediated by access control at 
> the host level and private/interconnect border at a minimum. In a default 
> deny network there will be additional policy enforcement within the private 
> network. 

There's a fundamental problem in that people have come to expect that somehow 
the network is responsible for keeping hosts secure from attack.  Again, that's 
not the fault of the architecture.

Keith


_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to