RE: [BEHAVE] Re: CPE equipments and stateful filters

["Dan Wing" <dwing@cisco.com>]

> > ...or the server would need to tell its firewall to permit  
> > unsolicited incoming traffic.
> 
> It would be more accurate to describe that method like this: the  
> server would need to solicit the firewall to permit 1) inbound IKE  
> initiations from arbitrary remote addresses, and 2) IPsec ESP/AH  
> flows for negotiated security associations. 

Agreed.

> Neither of these two  
> forms of traffic could reasonably be described as "unsolicited" in  
> this case.

We have different definitions of 'solicited traffic' and 
'unsolicited traffic'.  Other than opening a listener on UDP/500 
for IKE (and telling the upstream firewall to please open a 
permission for incoming traffic), the host didn't do anything to
solicit an incoming IKE packet.  I call that incoming traffic
'unsolicited', because the host (and its firewall) are unaware
of when a client will send a packet to establish a connection.
An HTTP server or SMTP server fall into this category, for 
example.


This differs from the SIP model and the RTSP 2.0 model.  In
both SIP and RTSP 2.0, an offer/answer exchange allows the 
server to learn the client desires a new session.  With that
knowledge, the server can communicate more specific information
to its firewall about the client's IP address; in this way, the
firewall doens't need to necessarily permit incoming IKE packets
from arbitrary remote addresses, unless those are first signaled
with SIP or RTSP.  This model is also used by HIP and EME, two
working groups in the IRTF (www.irtf.org).  This is what I would
consider 'solicited traffic'.


What are your definitions?

-d