Purpose of ALD (was Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03)

[james woodyatt <jhw@apple.com>]

On Aug 27, 2008, at 12:54, Dan Wing wrote:
> [I wrote:]
> > I must chime in here and repeat for the record that ALD is most  
> > emphatically NOT a protocol for enabling hosts to control filtering  
> > devices.  I took Great Pains to specify it as a protocol for  
> > filtering devices to learn about interior applications that are  
> > soliciting inbound traffic from arbitrary exterior nodes regardless  
> > of their remote address.
> >
> > Please please please I am VERY resistant to positioning ALD as a  
> > method for nodes to use in "controlling" firewall devices.
>
> Er, it seems the same to me.  Are you just saying that the interior  
> host is not necessarily *overriding* the filtering device's rules?   
> If that's what you're saying, I agree, and I think that's fine.

I'm actually making a somewhat stronger statement.

I'm saying that the Purpose of ALD is *NOT* for interior nodes to  
control their corresponding states in filtering middleboxes, but  
rather for middleboxes to learn about state at interior nodes relevant  
for network filtering.  The design of ALD is a reflection of this  
statement of purpose, which is why it defines no mechanism for  
informing endpoint nodes whether and/or why not filtering rules have  
changed as a result of the notifications they send.

I don't mean to sound like I'm picking nits, but I really do think  
it's a big mistake to formulate the problem statement around a  
perceived need for endpoint nodes to "control" the state of  
middleboxes.  I contend there is no such need.  There is only a need  
for filtering middleboxes to be better aware of endpoint state so that  
they do not intrude on network transparency unnecessarily, i.e. when  
security policy does not require it.


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering