[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: phase 2 and ports
On Mon, 26 Jun 2000, Jari Arkko wrote:
> Jan Vilhuber wrote:
>
> > 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
>
> This is a real problem.
>
> Maybe we could come up with an API or a protocol to enable applications
> to control security services in the manner you propose.
>
> >a) port-ranges would be usefull for applications that know a priori what
>
> I remember in the last IETF Steven Bellovin gave a talk about a similar
> problem for SCTP (one of the signaling protocols). There the problem was
> with several IP addresses. If somebody's going to extend ID payloads,
> such extensions should cover both issues.
>
> > 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
>
> Isn't this because, say, L2TP client is has a wildcard port number and
> the server a fixed one?
Actually the server starts on a fixed port and then may move to a dynamic port
on its reply.
The potential flow is:
LAC to LNS: SCCRQ (src UDP port = Wildcard, dst UDP port = 1701)
LNS to LAC: SCCRP (src UDP port = Wildcard, dst UDP port = Wildcard)
LAC to LNS: SCCCN (src UDP port = Wildcard, dst UDP port = Wildcard)
Currently IKE doesn't have a method for negotiating such a sequence without
negotiated 2 phase 2 SA's or negotiating ANY to ANY on the ports, or Fixed to
Any on the ports. The later two cases allow for traffic other than L2TP to be
put into the tunnel which is not desirable. The Security Gateways would be
required to implement secondary acls behind the IPsec SAs to stop non-L2TP
traffic if ANY is negotiated. In the L2TP security draft we have proposed
negotiating 2 phase 2 SAs if both peers need to float their UDP ports. It would
definitely be nice if IKE had a built in method for taking care of this.
-Skip
>
> Jari
>
>
References: