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

RE: phase 2 and ports



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

In mind, this is still the theoretically "correct" way of solving the
problem. The way to avoid black holes is to use a firewall policy sharing
protocol.

Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber
> Sent: Friday, June 23, 2000 8:06 PM
> To: ipsec@lists.tislabs.com
> Subject: 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
>
>



References: