Re: Do we actually need dynamic ports?

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

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