Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt

From: [email-masked]
Date: Mon, 25 Jun 2001 18:13:07 +0100

Christian,

> The examples about RTP have outlined the fact that RTP pin-hole
> typically are of the form "allow data from unknown sources 
> and ports to
> reach a specific address and port." It is true that the average RTP
> session will require 2 pinholes. But in this case, the direction is
> expressed trivially; there is no need for a multi-value field.
> 

While possible as an option I don't think openning ports to allow allow data
from unknown sources and ports is necessarily wise as a security policy for
a complete solution. We should allow for more precise cases where a more
strict policy is applied( open an RTP stream from THIS source and port to
THAT source and port.), shouldn't we?

regards

Richard

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

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 25 Jun 2001 15:12:20 -0400

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Monday, June 25, 2001 1:13 PM
Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt

> THAT source and port.), shouldn't we?
Unfortunately, in SIPland, we don't know the source address and port. The
SDP in SIP messages contains only the receiving address and port for each
flow. There is no requirement with RTP for the sending address and port to
match the receiving address and port. Probably the best we could do is use a
prefix or netmask to narrow down the range of acceptable source addresses.

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 25 Jun 2001 16:09:22 -0500 (CDT)

> prefix or netmask to narrow down the range of acceptable source addresses.

	The same is true of H.323.

	While we don't know where the RTP is coming from, we can
(as Bob suggests) sometimes guess the general vicinity of the source
as a network or something. This is the SIP Agent's problem, and presumably
would be subject to customer configuration.

	More often, we know what interface the RTP will be coming
from. For example, we might know that that RTP will be coming from the
"outside" someplace, simply because we know it's not one of my internal
phones.

	In general, the following information completely defines
a 'pinhole':

	source address
	source port
	dest address
	dest port
	protocol (TCP, UDP, etc)
	expected ingress interface
	expected egress interface
	bidirectional-flag

	All of these fields, except the protocol can usefully be made
"vector" as opposed to "scalar" quantities. That is, it makes sense
to, in the fully general notion, specify a SET of source addresses,
ports, dests, interfaces, and so on. In practice, a bitmask seems to
suffice. It also seems to be widely implemented. It may be
acceptable to standardize bitmasks (or even prefix lengths, that
is, bitmasks which look like 111...111000...000) as the way MIDCOM does
things?

	Pinhole specifications which work well for, say, RTP streams in
SIP or H.323 look like:

	SA: 0.0.0.0 / 0.0.0.0
	SP: 0 / 0
	DA: 1.2.3.4 / 255.255.255.255
	DP: 50000 / 0xfffe           <-- allow ports 50,000 and 50,001
	Proto: UDP
	Ingress: "Open"
	Egress: "Secure"
	Bidirectional: No

	A pinhole specification which would work well for active FTP
might look like this:

	SA: 1.2.3.4 / 255.255.255.255
	SP: 21 / 0xffff                <-- assume "standard" server
	DA: 5.6.7.8 / 255.255.255.255
	DP: 12980 / 0xffff
	Proto: TCP
	Ingress: "Open"
	Egress: "Secure"
	Bidirectional: Yes

Or:

	SA: 1.2.3.4 / 255.255.255.255
	SP: 0 / 0                        <-- assume non-priv. server
	DA: 5.6.7.8 / 255.255.255.255
	DP: 12980 / 0xffff
	Proto: TCP
	Ingress: "Open"
	Egress: "Secure"
	Bidirectional: Yes

	These two, being directional, could just as well be written
the other way around, from the outside to the inside.

	Should there be additional stuff in there to specify which
direction the data stream(s) corresponding to the pinhole can be created?
That is, which way is a TCP SYN packet w/o ACK allowed to go? (This is
the equivalent of cisco's 'established' keyword, or the Aravox
'tcp_connect_request' pattern, and everyone else in the world's own
thing).

	Sometimes implementations allow (such as the one I work with
daily) allow 'to', 'from' and 'bi-directional', where 'from' does nothing
more than reverse the sense of source and dest. This is obviously
redundant since the same effect can be obtained by reversing source
and dest. I think it exists merely to satisfy someone's warped sense of
symmetry.

	Note that the ingress/egress interface specification is more
useful than merely testing spoofed addresses. In the RTP case, you don't
even know the source port. The ingress interface specification can
serve as a very coarse "source" check, though.

		Andrew