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

[peter_blatherwick@mitel.com]

YES!  Definitions are very important
here, or we'll wind up talking in circles.  

> ... We
have different definitions of 'solicited traffic' and 
> 'unsolicited traffic'. ...

Interesting observations Dan.  The
differences are around what prior knowledge is available.  I think
it can be generalized and expanded.  (Whipping out my handy dictionary.)
 

> I call that incoming traffic [intentionally listened
for]
> 'unsolicited', because the host (and its firewall) are unaware
> of when [or from where] a client will send a packet to establish 
> a connection.

"Unsolicited" does seem to
be a good term for this category.  Perhaps "Expected" would
be a good characterization also.  

> ... [some protocol] 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 [and timing 
> of the required pihole]; ...  This is what
I would
> consider 'solicited traffic'.

Yup, "Solicited".  "Negotiated"
or "Signalled" might also be appropriate terms.    Note
also, the actual signalling, leading up to the Solicited traffic, may well
have been some other category.  

I would add: 

"Unexpected / unwanted" --
traffic which was not explicitly indicated as ready to receive, either
by listening at the server and (potentially) opening the corresponding
pinhole in the firewall (either of Unsolicited or Solicited above), or
by client initiation (next).   This is the "bad stuff" that
should be dropped on the floor.  

"(Client) Initiated" -- traffic
that started from the "inside", by the client.  

Just typing out loud... 

-- Peter Blatherwick

"Dan Wing" <dwing@cisco.com> Sent by: owner-v6ops@ops.ietf.org 31.07.07 13:46

To:        "'james woodyatt'" <jhw@apple.com>, "'IPv6 Operations'" <v6ops@ops.ietf.org>, "'Behave WG'" <behave@ietf.org>         cc:                 Subject:        RE: [BEHAVE] Re: CPE equipments and stateful filters

> > ...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