[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Do we actually need dynamic ports?

At 5:05 PM -0800 3/26/02, Jan Vilhuber wrote:
On Tue, 26 Mar 2002, Paul Hoffman / VPNC wrote:

> Why is this a requirement? Has the lack of dynamic ports 
 significantly hurt IKEv1? If so, what other protocol did the folks
 who required dynamic ports use?


There is no other protocol they COULD use.

And yet they exist today. This argues against dynamic ports being a requirement (although they could still be useful).

 The workaround, as Scott
Kelly posted, is to open up ALL TCP ports (in the case of FTP) and do
stateful filtering on both ends, which is not interoperable. If you
don't do stateful inspection, you simply keep all ports open and pass
more traffic than you were hoping for, which is also suboptimal.

It is suboptimal, but it works today.

Adding dynamic ports to IKE would certainly not simplify it or make it more understandable to end users.

> This sounds a lot like a rat-hole that will have next to no chance of
interoperating and will not help many users.


I think it WILL help many users. The ability to do dynamic port
additions (or even dynamic address additions) will make configurations
simpler (try 'ftp' instead of 'port 21 and whatever else ftp
negotiates'), and will not impact interoperability.

Those aren't the options. The options are "FTP" or "all ports". "All ports" is understandable.

 I think it's
fairly well defined in both angelos' draft for sctp and Pyda
Srisuresh's draft (of which I'm coauthor). This is not brain-surgery.

Well, it is scary enough for this working group to have avoided it so far.

Given that ip telephony is being used more and more, and given that
h.323 is the mechanism (or one of them?) I'd say this is important.

Important for some customers who only trust their communicating parties to use selected ports, yes. A requirement for all users, no.

Whether it needs to happen in IKE, or, as Hillarie suggested, as part
of some as yet unspecified protocol in IPSP is up for discussion, but
the problem must be addressed.

Addressing it outside of IKE allows the parties who actually need it to use it, but those who don't need it and don't want to deal with the additional administration to ignore it.

Problem with doing it via IPSP is that (as someone else pointed out)
said IPSP protocol would need to be done before SOI can become an
RFC. I'd prefer not to make such a linking, since I don't think this
is overly complex... Opinions vary (obviously.. this is ipsec afterall).

But does it have to be part of the key negotiation at all? This sounds like stuff that is done *after* key negotiation. If so, there is no linkage to SOI at all.

--Paul Hoffman, Director
--VPN Consortium