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

Re: phase 2 and ports

On 26 Jun 00, at 12:21, Dan Harkins wrote:

Jan, Dan,

actually there is another problem here: while IKE can negotiate level 
of traffic protection (by means of SA payload), it currently is 
unable to negotiate scope of this protection - initiator can only 
suggest this scope (via IDui & IDur payloads) and responder can only 
accept it or reject the whole exchange. This is due to (as Dan 
pointed out far ago) ID payload semantics currently is overloaded - 
in Quick Mode it simultaneously represents scope of protection 
desired by initiator and, hidden in it, actual parameters of IP 
packet that has triggered this Quick Mode.

One of the possible solutions would be to separate this functions by 
introducing new payload, say Policy Payload. Its format must allow to 
represent complex policy constructions, such as lists and ranges of 
IP addresses, protocols and ports. In this case initiator would send 
both ID payloads and Policy payload in Quick Mode. ID payloads must 
indicate actual IP packet parameters that has triggered this 
negotiation and Policy payload must indicate the desirable for 
initiator scope of protection. Of course, parameters represented in 
ID payloads must "fit" into Policy payload. Responder must return ID 
payloads intact (as currently), but is allowed to modify Policy 
payload according to its local policy requirements regarding scope of 
protection. For security reasons it must be allowed only to "narrow" 
scope of protection. Of course, ID payloads must still "fit" into 
this modified scope. On receipt of this message initiator decides 
whether this modified scope is acceptable for him, or not, and 
continues exchange or terminates it accordingly.

This is rather simple sceme that, by the way, allows backward 
compatibility with current approach.

Regards,
Valera.

>    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
>  > 
> 
>
References: