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

Re: phase 2 and ports

   Jan,

   It's a big problem that we punted on. I believe (correct me if I'm wrong
Steve) that the draft that became RFC2401 actually discussed selector 
parameters for port ranges but that was removed because it was not possible 
to express them in IKE (using ISAKMP inside of the DOI).

   This issue is part of http://www.lounge.org/ike_doi_errata.html which
drove the son-of-ike draft, which quietly expired. There was discussion in
Adelaide about what to do with IKE and whether it would produce any progeny
but there didn't seem to be any concensus. Of course reving the key
management troika (or even better combining those three into 1 new document) 
would also cause RFC2401 to be revved. 

   Dan.

On Fri, 23 Jun 2000 17:05:43 PDT you wrote
 > I was wondering if anyone had a good solution to this problem, or if people
 > are interested in one in general. Maybe people don't think this is a problem?
 > I'd like to hear opinions.
 > 
 > Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to
 > name a few). Other protocols a priori use more than one port (can't think of
 > any examples, but I don't see why this couldn't be the case), yet the ID
 > payload has a field for a single port only. There's no way in IKE to
 > negotiate something like src-ip=A, src-port=8-10, dst-IP=B, dst-port=8-10 (an
 > example only).
 > 
 > As far as I can tell, you'd have to negotiate one SA per port, i.e. 3 SA's in
 > the above example (times 2, since we're doing bidirectional).
 > 
 > There's really TWO problems here:
 > 
 > a) port-ranges would be usefull for applications that know a priori what
 >    ports they are going to use. On a side note, it's always kind of bothered
 >    me that we need 2 ID payloads. I assume this is so we can reuse the ID
 >    payload from phase 1, but it might be handy to define a generic payload
 >    that defines the selector as a whole in a single payload.
 > b) an application-ID would be usefull for applications that do NOT know a
 >    priori what ports to use (l2tp for example). I could see using the tuple
 >    protocol:port as an application identifier, and somehow 'teach' ipsec to
 >    identify what traffic constitutes that application (note I'm not
 >    advocating adding l2tp code into ipsec; this could conceivably be done via
 >    some API between the two..).
 > 
 > Has anyone come up with a solution for this? Does someone think this is NOT a
 > problem (in which case I'd like to hear some proposed ways of dealing with
 > the above; but see PS below)? From my readings of the rfc's, I don't see how
 > this can be done, although ipsec certainly can handle multiple ports. You
 > just can't negotiate it in IKE...
 > 
 > jan
 > 
 > P.S. I know of at least one vendor that solves this problem by using port=0
 > (i.e. 'all ports') and filtering traffic behind ipsec. I don't consider that
 > a good solution, since the peer may not know of this filtering and needlessly
 > encrypts and sends stuff that the other side is just going to toss anyway. It
 > wastes CPU on both sides and wastes bandwidth. It's also a bit hard to debug
 > ("We negotiated all ports... I wonder why none of my traffic is getting
 > through...")
 >  --
 > Jan Vilhuber                                            vilhuber@cisco.com
 > Cisco Systems, San Jose                                     (408) 527-0847
 >
Follow-Ups: References: