ietf
[Top] [All Lists]

Re: existing (and questionable) application designs [was Re: US DoD and IPv6]

2010-10-08 08:01:09

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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>