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

phase 2 and ports

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: