Subject: [midcom] Firewall interaction with BEEP

From: [email-masked]
Date: Fri, 6 Jul 2001 15:33:43 -0700 (PDT)

As many of you may know, beep is an application protocol framework
standardized within the IETF as a method for reusing common protocol
elements for connection-oriented application protocols (see RFCs 3080
and 3081 for the core specs and the mapping onto TCP).  Thinking about
how beep works, it occured to me that there might be a requirement for
MIDCOM agents to refer to specific protocols layered on top of beep.

With his permission, I've attached below an email response from
Marshall Rose on the issue; his basic message is that an effective
message to a firewall about a beep connection will need a tuple of
(src, dest, profiles) to cover the policy requirements.  On the
positive side, as he notes, all elements of a beep session are
currently bound to a single TCP connection and there are not
FTP-data type problems to contend with.

Despite there being no current firewall applications that are
beep capable, I believe we may need language in the requirements
document to cover the use of profiles within beep sessions.
			regards,
				Ted Hardie

>From [email-masked]  Fri Jul  6 12:33:01 2001

>> Do you have any information on how current firewall configurations
>> handle beep's ability to handle multiple applications, and do you have
>> a sense of whether src,dest,application is a sufficient tuple for the
>> applicationof firewall logic?

>hi. i'm not aware of any firewalls that are beep capable. that's probably
>because the first set of beep applications haven't rolled out yet, and most
>firewall vendors operate in a reactive mode with respect to the market.

>at a first cut, a tuple of <src, dst, profiles> is adequate.

>this is a bit different that what you suggest, for two reasons.

>first, i use the term "profile" rather than "application", since this is the
>term that beep knows about and exchanges. that is, a firewall could be
>figured to allow traffic from a particular src/dst pair, if it looked like
>beep, but only if profiles from allowed list were started.

>second, i use the plural "profiles" because you may want more than one. for
>example, the first thing the peers might do is start up a sasl channel for
>authentication, and then they might start one or more data channels for
>exchange.

>there is one nuance to all this: if the TLS profile (or a SASL profile that
>does privacy in addition to authentication) is on the allowed list, then the
>firewall is going to lose the ability to observe traffic. the same is true
>if the tunnel profile from the idxp working group is on the allowed list.
>maybe this is an okay thing, it's up to the administrator to setup the list
>of acceptable profiles to start.

>of course, things like APEX imply the same kind of issues that you'd find
>with allowing SMTP traffic; similarly, things like SOAP imply the same kind
>of issues that you'd find with allowing HTTP traffic.

>on the bright side, since all the traffic for a beep session is currently
>bound to a single tcp session, you don't have the ftp-data/h.323 issue.

>hope that helps.

>/mtr

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 6 Jul 2001 22:21:36 -0400

> document to cover the use of profiles within beep sessions.

I think this comes down to a statement that the midcom protocol syntax
needs to be flexible enough to do not just what we are focused on right
now, but what others might need to do in the future -- we already have
this covered -- and that we should add beep-based communications to the
list of possible future needs.  I don't see a problem here.

...Scott

---

From: [email-masked]
Date: Mon, 9 Jul 2001 10:31:24 -0700 (PDT)

Scott,
	Adding beep-based communications to the list of possible
future needs would help, but I think we need more than a statement
that the protocol syntax needs to be flexible.  I think we need to
explicitly say that the MIDCOM protocol must be able to handle control
channels that fall into three categories: port based, mux-based, and
external channel.  For the midcom protocol to handle a port-based
protocol (like WHOIS, for example) is pretty easy: the agent can
request a pinhole for the specific port on a specific destination.
For the external channel, the agent uses data from one channel to
request a pinhole for a distinct src/dest pair.  For a mux-based
protocol, the agent must be able to do more, because the src/dest pair
doesn't make for a full tuple; it must name the profiles as well.
Without that, all beep profiles would have to be considered
equivalent; the result would look much like a firewall control protocol
that could only specific IP address (and could not specify port number):
all tcp and udp-based protocols would look the same.  Though I
can't point to an existing firewall implementation to prove it, I
have a strong suspicion that that won't suffice.
				regards,
					Ted Hardie

---

From: Keith Moore <[email-masked]>
Date: Mon, 09 Jul 2001 14:27:00 -0400

I think this is just further demonstration that we need for each
protocol that the network is going to know about to have a unique 
port assignment, even if it's layered over a substrate such as BEEP.
Expecting the network to sort out details of protocols higher 
than the packet level is not only a gross layering violation,
it doesn't scale well.  It's one thing to build firewalls that
do this as a stopgap measure, but we shouldn't invest time trying
to standardize such hacks.

Keith

---

From: [email-masked]
Date: Mon, 9 Jul 2001 14:21:15 -0700 (PDT)

Keith,
	Given the threat model firewalls address, I find it very
unlikely that assigning a port number to specific beep-substrate
protocols would solve the problem.  I believe it very likely that the
firewalls will have to inspect at least the control channel of beep
sessions to meet their security requirements.  On the other hand, I
expect that if a firewall sees something that is not allowed in such a
session it will close the whole beep session, rather than trying to
eliminate some channel in the mux.
	This isn't the worst case, but as you note, it isn't pretty.
Unfortunately, I can't see how a firewall could meet its security
requirements in the face of beep's characteristics without doing so.
If you have another way of approaching the problem, now is the
time to get it out, because we don't have any beep-capable firewalls
to work around and we have a reasonable opportunity to suggest
less problematic behavior. 
	I raised this issue because this seems to be the time to
ensure that the MIDCOM protocol syntax has sufficient flexibility to
include information beyond host and port.  There seem to me cases in
which appropriate communication with firewalls does seem to require
that the tuple for identification of permitted application goes beyond
src,dest.  Beep seems to me an important case in point.  
	I agree with Christian that we understand src, dest well and
do not understand all of the nuances of (src, dest, profiles), but I
disagree that the work of getting that out should be put off.  I
strongly suspect that doing the work of understanding the needed
semantics now will make getting an appropriate syntax correct far
easier than working it out later as an addendum.  After all, the base
semantics for src,dest might need an "or" syntax at all, where the
beep capable syntax needs to be able to handle something like "src and
dest and (profile1 or profile2 or profile3)" or even "src and dest and
not (profile1 or profile3)".
				regards,
					Ted Hardie

---

From: Keith Moore <[email-masked]>
Date: Mon, 09 Jul 2001 17:38:18 -0400

> sessions to meet their security requirements.  

I have no doubt that firewalls that inspect content will continue
to exist.  The question is whether these should be explicitly 
supported with standard Internet protocols for controlling them.
I think it is a terrible idea, because it encourages poor design
and it doesn't scale.  

> less problematic behavior.

I think midcom is inherently trying to solve a very limited problem,
because as soon as you try to generalize it, it becomes intractable.
So it needs to stick with the subset of the problem that is tractable.
Yes, it's probably the case that whatever midcom produces will be only
of limited utility.  But I think that's a direct consequence of the 
solution space that midcom anticipates.  

> src,dest.  Beep seems to me an important case in point.

I think it would be a very poor decision if we taught MIDCOM to 
deal with protocol information beyond host and port.  MIDCOM should
not try to support and encourage everything that firewalls do.
That way lies madness.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Mon, 09 Jul 2001 17:47:37 -0400

>I think it is a terrible idea, because it encourages poor design

Uh, Keith - what we're trying to do here is provide the infrastructure
to allow firewalls to work without inspecting content.  I think you
have us confused with that other proposed working group, over there.

Be that as it may, midcom is an existing working group with a
specific charter and specific deliverables.  If you expect us not
to wander into the weeds that you happen not to like, please do not
try to drag us into the weeds that you do like.

Melinda

---

From: Keith Moore <[email-masked]>
Date: Mon, 09 Jul 2001 17:50:39 -0400

> have us confused with that other proposed working group, over there.

Uh, Melinda - one way to read what I'm saying is that midcom should stay 
within its charter, in response to suggestions that it should deviate 
from its charter.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Jul 2001 18:08:02 -0700

Ted,

I'm sorry I didn't respond earlier to you, and so the following might seem
like closing the barn door after the animals have left.

I think we wandered into the woods when we started considering which
applications are going to be availing themselves of network services,
rather than focusing on those services themselves.  BEEP may allow
multiple applications to run in a single L4 data stream, but that doesn't
mean it's a good idea.

I would back up and give some guidance on just this point as it relates to
firewalls.  Otherwise we could easily re-invent the "everything over port
80" problem all over again.  But while this idea was contemplated in the
BEEP WG, is anyone actually doing this sort of thing?
--
Eliot Lear
[email-masked]

---

From: "Marshall T. Rose" <[email-masked]>
Date: Mon, 9 Jul 2001 18:29:28 -0700

> BEEP may allow

BEEP allows multiple channels to be running over a single L4 data stream,
and those channels can be the same profile or different ones.

the problem, i think, deals with terminology. in beep, an "application
protocol" equals BEEP + 1 or more profiles + authorization policies +
provisioning rules.

provisioning rules deal with things like using SRV RRs or static port
numbers or whatever.

in addition to the "raison d'etre" profile, profiles can also include things
like what you use to tune the session for the desired security properties.

thus far, this thread doesn't seem to deal with this nuance, which is
unfortunate, because it's an important one.

if someone defines the "foo application protocol" as using BEEP, they are
perfectly free to get a well-known port number for foo.

so here's a simple question: does midcom care whether stuff on port 25 is
actually smtp or not?

if so, you have a larger problem than the dynamicism of beep. if not,
whether an application protocol uses beep is a non-issue.

/mtr

---

From: [email-masked]
Date: Tue, 10 Jul 2001 11:25:52 -0700 (PDT)

My sense is that some firewalls do care that the stuff on port 25 is
actually smtp.  I personally believe that that ability to name the
application using a port would be useful in communications with
firewalls that do care about such things.

I also believe, however, that we don't have consensus in this working
group on whether MIDCOM will require the ability to communicate to a
firewall about what application/protocol is permitted on a specific
port.  Since we don't have consensus on that, the application of that
ability to a multi-channel protocol like BEEP doesn't have a base to
build on.

The base requirement for MIDCOM in the firewall part of the fog is
clearly to be able to request a pinhole by naming a src,dest pair.
There seems to be some support for the ability to extend the MIDCOM
semantics beyond src,dest to include other information.  One extension
might be to name the src, dest, and permitted profiles for beep
sessions.  Until that "some support" becomes consensus, though, I
suggest that the requirements' doc include the weaker language Scott
originally proposed, which supports flexibility but does not require
explicit support of any particular extension.

I don't want to take up working group time in London on this, but it
might be useful for some of us with opinions on this to take advantage
of some high-bandwidth hallway time to see if we can come to consensus
on bringing this in or leaving it out.
				regards,
					Ted Hardie

---

From: [email-masked]
Date: Tue, 10 Jul 2001 12:30:06 -0700 (PDT)

Scott,
	I think the charter actually does pretty good job of
putting this:

 Decomposing applications requiring policy decisions by removing
 application logic from the middle box and instead providing a
 generalized communications interface provides a number of benefits,
 including improved performance, lower software development and
 maintenance costs, improved ability to support traversal of packet
 filters by complex protocols, easier deployment of new applications,
 and the ability to consolidate management functions. For example, by
 moving stateful inspection of protocols such as H.323 and SIP out of
 firewalls, it is possible to improve performance and scalability and
 reduce development and costs.

	By raising this issue, I'm not trying to subvert the charter,
sow confusion, or otherwise cause anyone's ulcer to grow.  I am trying
to point to an emerging protocol family based on a multi-channel
architecture.  APEX, IDXP, and other protocols are being developed in
IETF contexts now using BEEP.  Because they are multi-channel, they
may admit of a less granular decomposition than other protocols; with
a one-to-one mapping onto known ports, they may also look to a
firewall exactly like protocols based directly on tcp.
	I have suggested using a bit of face time in London (outside
the working group time) to discuss this further.  A review of RFC 3080
and RFC 3081 for those interested would be useful.  
				regards,
					Ted Hardie

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 10 Jul 2001 15:49:07 -0400 (EDT)

> protocol" equals BEEP + 1 or more profiles + authorization policies +
 
What do you call this? Application intelligence? Application
awareness? Isn't that what we are trying to avoid? 

How does beep integrate currently with the framework? Can you
say that a beep agent (in-path) would do the trick and isolate
the awareness from the middlebox? Would OOP agent do it?
Even if you use something like a profile to classify flows
how can you escape NATing within the payload?

Rather than re-inventing the framework to suit beep, can
beep architecture been accommodated within the current
framework?

regards
Abdallah

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 10 Jul 2001 15:49:07 -0400 (EDT)

regards
Abdallah

---

From: "Scott Brim" <[email-masked]>
Date: Tue, 10 Jul 2001 14:44:31 -0400

On 10 Jul 2001 at 11:25 -0700, [email-masked] apparently wrote:
> port.

My sense is that we have strong consensus that a middlebox shouldn't
have to care, perhaps shouldn't be allowed to care, about the *meaning*
of a particular port number, or anything else that implies anything
about higher layer activity.  We want middleboxes to be stupid.  Educate
your agents.

> sessions.

I want to know, functionally, what you mean by "a profile".  Is a
profile represented by a particular byte value at a particular position
in packets of a flow?  How simple is it to find that value by looking at
a packet as a string of bits and using downloadable rules?  If it's easy
then middleboxes can be dumb.  If it's not I believe we should think
about whether to support it in the midcom protocol.  The midcom protocol
has a chance of being lean and mean.  If we have to make the protocol
overweight just in order to support a case which might not even see
widespread deployment, and which might be the only case requiring such
complexity, then it might be better for everyone if you have your own
specialized protocol.

All those "mights" are why I want to know exactly what is required.
What does it take to state a rule about a profile, when a middlebox
knows nothing about your higher layer semantics?

...Scott

---

From: Melinda Shore <[email-masked]>
Date: Tue, 10 Jul 2001 16:15:36 -0400

>might be to name the src, dest, and permitted profiles for beep

At this point we're really only talking about the protocol between
an agent and a middlebox.  We care about what the middlebox does to the
extent that it shapes what we have to put in the protocol.

Inasmuch as we're not specifying a protocol here, it seems to me
that it's probably enough to put some text in the requirements
document that the protocol language needs to be sufficiently 
expressive to be able to convey protocol and protocol demultiplexor
information.  

In the meantime, as a point of information and NOT as a required
part of the documents, if anybody has a firewall that already supports
BEEP I'd personally be curious to know what they do.

Melinda

---

From: Matt Squire <[email-masked]>
Date: Tue, 10 Jul 2001 17:55:33 -0400

>  We want middleboxes to be stupid.  Educate
> your agents.
> 

At the risk of reinforcing the obvious: Yay, double yay, and a really
big yay to go along with it.  

- Matt

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Jul 2001 13:32:21 -0700

Ultimately, Marshall, I think that the problem is not really BEEP's, but
that of firewall vendors.  Here is an example scenario which I think could
happen:

Some popular application, like the web, converts from HTTP to BEEP.  Then
someone builds a utility library for retrieval of pages based on URLs. 
That library in turn might call a process which does localized caching. 
So now you have multiple applications using the same code space, perhaps
even going to the same locations.  That's where things get interesting,
especially if what we are talking about is a web cache.

But as you say, all of this could virtually be done today, from a web
cache, and the 5 tuple might not be enough to determine authorization.  So
that leaves open the question of "what is enough?"  and how do you keep
this from becoming a generalized query/response mechanism between the
middlebox and the end host?

Now there are perhaps some perverse things you could do with BEEP that
would make Keith (and a whole lot of other good people) wretch all over
their keyboards; like for instance, intercepting the BEEP connection and
looking for particular profiles whose specific purpose is to communicate
with midcom boxes.  There are an infinite number of bad ideas out there. 
I cite this one simply for the purpose of demonstrating to friends a
multicolored vegetable that used to be green.
--
Eliot Lear
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 10 Jul 2001 20:53:35 -0400

> semantics beyond src,dest to include other information. 

never mind that it's out of scope, or that it doesn't scale, or
that it doesn't make good architectural sense.  

if there's "some support", we have to do it!

I have a solution to this dilemma:
Let every monkey have his own typewriter.
Just don't expect IETF to endorse the results.

---

From: "Marshall T. Rose" <[email-masked]>
Date: Tue, 10 Jul 2001 18:05:47 -0700

> complexity, then it might be better for everyone if you have your own

in beep, "session", "profile" and "channel" are specific terms that have
well-defined meanings. i'll answer all of your questions by using one
example:

       MSG 0 1 . 52 120
       Content-Type: application/beep+xml

       <start number='1'>
          <profile uri='http://iana.org/beep/SASL/OTP' />
       </start>
       END

this is a beep frame that contains a message on channel 0 asking to start a
profile on channel 1.

Accordingly:

> Is a
> in packets of a flow?

if you s/profile represented/channel for a profile started/, then the answer
is "no". first, the frame header ("MSG ...") is variable-length; second, the
payload for channel 0 is xml-based, so it too is variable-length,
whitespace-friendly, etc.

> How simple is it to find that value by looking at
> a packet as a string of bits and using downloadable rules?

if the "downloadable rules" can make use of a beep packet and xml
interpreter, i'm sure it's trivial (insert a lot maniacal laughter here..)

so, what does this tell us?

to me, it says to stick with filtering on the basis of tcp header
information (ip addrs, portnos) and not to deal with the data conveyed by
tcp.

that will certainly work for the things being developed by the ietf that use
beep (e.g., the reliable syslog spec requests a well-known port number).

/mtr

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 11 Jul 2001 09:10:45 -0400

> interpreter, i'm sure it's trivial (insert a lot maniacal laughter here..)

I actually did laugh.

> beep (e.g., the reliable syslog spec requests a well-known port number).

Right.  Beep is clearly so far up the stack that filtering out different
profiles, or even channels, shouldn't be a concern of the network.  I
think hosts are going to have to take care of their own security at that
level.

...Scott