At 19:03 1999-03-31 -0800, Matt Holdrege wrote:
If you are using ESP, there are no worries. The endpoints unwrap the original packet and process it as normal. The firewall doesn't know or care about the original internal packet.
In Melinda's case, and I think it applies to the megaco messages as well, if that pdu contains protocol addresses, and the firewall wants/needs to unblock them (but not translate them), it certainly does care. I think we are talking about firewalls that filter/block all but a few configured ports, and open others when genuine needs are detected.
But if we are talking about MEGACO and I originally thought we were, you don't need to use ESP if you don't want to. For security's sake, you may wish to use AH in which case the firewall will simply authenticate the packet and pass it through without any worries.
Assume for the moment that the MG lives behind a firewall, and the MGC is "out there", communicating on the well known and open port allocated to megaco. An RTP session needs to be opened, on a dynamically allocated port that the firewall is blocking. The session is to be made from another dynamically allocated port, on a different MG, somewhere "out there".
For security reasons, the megaco protocol exchanges between the MGC and MG are encrypted, according to a security association between themselves. The firewall is seeing encrypted pdu's that it cannot examine for addresses. How will media flow to these blocked ports?
I think that the other questions were similar, but the messages were Q.931 setup, or H.245 OLC and the firewall problem was the PER coding. It's worse with ESP/TLS than with PER, but it's still the same-ish problem.
Using AH does not provide privacy. An eavesdropper can snoop dial strings, which can be sensitive. An eavesdropper can spot IP/port pairs, which it knows are going to be opened by the firewall, for targeting denial of service attacks. It would not be impossible to find ESP being used on megaco.
The only worries are if you are using NAT.
And yes, the problem also arises with NAT, where the firewall also wants to _change_ the pdu.
See: http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-00 .txt :-)
At 11:14 AM 4/1/99 +1000, Douglas Clowes wrote:
Hi Matt,
I've read 2401 (IPsec), 2402 (AH), and 2406 (ESP) before. I've also skimmed, but probably not understood, the ones on IKE and ISAKMP and OAKLEY too. I've just re-skimmed 2401/2/6 and still don't have the answer.
Re-reading the postings, they're about H.323 proxies, call signalling, and H.245 - some people are talking about H.323 rather than megaco/H.gcp, and that's part of the problem: different threads by different people.
My points are several, and relate to firewalls (as noted by the subject change).
In a mode 3 security association:
- neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2 | Gwy 1 Gwy 2 | | | | | | --Security Assoc 1 (tunnel)- | | | -----------Security Association 2 (tunnel)-----------
where Security Association 2 is ESP, how is SG1 or SG2 going to do packet filtering and port opening?
Or, if SG1/SG2 is a single entity, as in Case 4:
====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server
or SG2, here, is "just" a firewall, instead of a Signalling Gateway.
Assuming that the SA between H1 and H2 involves payload encryption, such as ESP, and is call signalling or H.245, how does SG2 cope with finding the IP/port pairs, even in a text based protocol?
My interest extends beyond megaco/H.gcp, and includes Annex G. How do we handle this in the more general case?
Douglas
At 16:05 1999-03-31 -0800, Matt Holdrege wrote:
You can read RFC 2401 & 2402 to find out about IPsec and AH. And this discussion is about MEGACO/H.GCP which is not the same as H.323.