Re: Do we actually need dynamic ports?

["Scott G. Kelly" <skelly@SonicWALL.com>]

I think a distinction should be made here: support for dynamic selectors
is first an IPsec architecture issue, and then maybe a SOI issue. If we
don't have a way to express such a policy in the SPD, then the rest of
the discussion is moot. If we do come up with a way, then we next need
to discuss whether we need special signalling to support this
functionality, or whether the required selector adaptations can be made
dynamically by each end of the SA via protocol inspection.

Scott

"Mani, Mahalingam (Mahalingam)" wrote:
> 
> There's a definite justification to be made for an increasing number of (peer-peer) protocols that negotiate dynamic
> ports, such as in H.323, that prividing for it in SOI will not only actually make it less of a rat-hole for securing
> the protocols but also prevent / minimize invention of drastic number of new security protocol variations replicated for
> each such special cases (protocols).
> 
> Considering better applicability of SOI to such protocols should probably become one of SOI requirements as well.
> - though not at the expense of making IKEv2 more complex.
> 
> Extensibility to protocol without complicating the base protocol is another challenge.
> 
> This helps scale the efforts of Security Area Directorate efforts at securing other protocols as well.
> 
> > -----Original Message-----
> > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> > Sent: Wednesday, March 27, 2002 7:44 AM
> > To: Jan Vilhuber
> > Cc: ipsec@lists.tislabs.com
> > Subject: 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).
> >
> 
> This means IKE/IPsec is not conducive to secure their protocols - even if it could otherwise have been
> 
> > >  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.
> 
> But doing so extensibly is not going to make it any less understandable.
> 
> >
> > >  > 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.
> >
> 
> It does not have to carry additional administration baggage for those who don't need 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.
> 
> Inasmuch as we allow for Transport level selectors to be negotiated this is equally fair game.
> 
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
> >
> 
> -mani