Subject: RE: [midcom] Firewall interaction with BEEP

From: Melinda Shore <[email-masked]>
Date: Mon, 09 Jul 2001 15:02:53 -0400

At 11:14 AM 7/9/01 -0700, Christian Huitema wrote:
>I don't think that it is a good idea to add additional requirements at
>this point in the game. We understand protocols and ports very well, and
>we should specify that. 

I don't think that we should be requiring specifically 
BEEP profiles as demultiplexors, but it doesn't seem to
me to be a huge stretch to require that the language be
expressive enough to be able to transport stuff in addition
to ports and addresses.  

Melinda

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

---

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

> expressive enough to be able to transport stuff in addition

to me this is a very huge stretch.  why do we have layering
at all if every network element is going to expect to look
at arbitrary layers of the protocol stack?

---

From: Melinda Shore <[email-masked]>
Date: Mon, 09 Jul 2001 16:45:28 -0400

At 04:18 PM 7/9/01 -0400, Keith Moore wrote
>at arbitrary layers of the protocol stack?  

If a firewall is going to to pass BEEP traffic it's going to be 
looking into the payload, anyway.  This is a symptom, not the
disease.

Melinda

---

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

> looking into the payload, anyway.  This is a symptom, not the

in that case, seems like the disease is trying to decide whether you 
can reasonably pass the traffic by looking at the content, rather than 
by looking at whether the parties are authorized to communicate.

but my point is - we need to be working on scalable and technically 
sane approaches, not trying to standardize non-scalable hacks.

Keith

---

From: "Scott Brim" <[email-masked]>
Date: Mon, 9 Jul 2001 16:56:48 -0400

> looking into the payload, anyway.  This is a symptom, not the

But it doesn't have to look at it with higher layer semantics (if it
does we've just reproduced the current situation).  I think we can do
this.

---

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

> does we've just reproduced the current situation).  I think we can do

we shouldn't standardize looking below the packet layer.  if people
want the network to distinguish different kinds of traffic, they need
to expose that distinction to the network - not expect the network
to parse the traffic streams.

anybody else remember when we understood why separation of function 
between layers was important?

Keith

---

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

>between layers was important?

We're headed off-topic.  Let's not.

Melinda

---

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

Keith,

Sorry that I hadn't read this before I sent my previous response.  The
point I'm making is that parties may be authorized to carry out one
communication type but not another.  Given that beep allows you to
multiplex different types of communication over a single session,
someone attempting to decide whether to authorize the communication
can do one of several things:

1) Authorize any communication which might use that session
	The consequence is that any beep-substrate protocol being allowed
	allows all beep-substrate protocols

2) Deny any communication which might use that session
	The consequence is that denying any beep-substrate protocol
	denies all beep-substrate protocols

3) Assign a different port to each beep-substrate protocol
	(a)If you trust the port assignment to eliminate beeps
	capability to multiplex different types of communication
	over the same session, you are back to src,dest

	(b)If you do not trust the port assignment, you are at (1)
	or (2), depending on whether you allow or deny.

4) Permit communication based on specific profiles
	
	(a)If you trust the profiles asserted the only ones which
	will use the assigned session, you open the pinhole and you're
	done.
	
	(b)If you don't trust that the profiles asserted are the
	only ones which one party might use during the session, you
	inspect the session and close it if a profile other than
	one asserted is used.

Fundamentally, the issue of protocol layers comes down to this:
beep does not use a classic port-assignment method of opening
communication channels.  It uses a profile negotiation method
within a session.  If we don't deal with that, we will not have
restored the classic port-assignment method, we will simply have
produced a middlebox communication protocol that is less useful
than it might be.
			regards,
				Ted Hardie

---

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

> We're headed off-topic.  Let's not.

if separation of layers is off topic, this entire group is off topic.

---

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

> communication type but not another. 

and my point is that the communication type needs to be exposed
where firewalls can look at it.  burying it inside beep just makes
the firewall more complex, and doesn't do anything for security.

beep shouldn't feel compelled to repeat the mistakes of those who
want to layer arbitrary things over HTTP (or insert other misused
protocol), and even if it does, midcom shouldn't feel compelled to 
encourage such mistakes.

Keith