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

Re: Do we actually need dynamic ports?



On Wed, 27 Mar 2002, Paul Hoffman / VPNC wrote:

> 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.
>

I hardly call that working. It's a hole in your security
policy. Customers are forced to do this because of a short-coming in
the protocol. I hardly call it workable.


> 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.
>

Yes, but may not be what the local security policy OUGHT to be. It's
too wide.



> >  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.
>

All due to the moratorium on changes to IKE.


> >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.
>

This is no different than creating a second SA, I suppose. You want
traffic for the FTP data channel? Create a new SA for
it. Alternatively, and this is what Pyda's and my draft does, pass an
indicator that identifies the previous SA, and ADD to it. Saves
memory, at almost no additional cost.

I really don't see the problem here. We're taking the 'dumb down IKE'
a BIT too far, I think. Is IKE a key management protocol? Or a key
agreement protocol?

To me it's a key management protocol. We can make SOI a key agreement
protocol (as JFK suggests), but then we also need to come up with a
management protocol on top of it. That doesn't exist yet, whereas a
completely workable management protocol already exists in IKEv1 and
improved in IKEv2.

jan


> --Paul Hoffman, Director
> --VPN Consortium
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847