[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
[192.94.214.100])
by portal.ex.tis.com (8.9.1/8.9.1) with ESMTP id HAA26526
for <ipsec@ex.tis.com>; Fri, 6 Nov 1998 07:35:31 -0500 (EST)
smap (4.1)
id xma019984; Fri, 6 Nov 98 08:00:11 -0500
watchdog-rtp.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id MAA17264; Fri, 6
Nov 1998 12:54:25 GMT
Date: Fri, 6 Nov 1998 07:53:52 -0500 (EST)
From: "W. Mark Townsley" <townsley@cisco.com>
To: Stephen Waters <Stephen.Waters@digital.com>
cc: Daniel Harkins <dharkins@cisco.com>, ipsec@tis.com, l2tp@zendo.com
Subject: RE:
In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C02155FCB@wade.reo.dec.com>
Message-ID: <Pine.GSO.3.96.981106074552.7215D-100000@claret.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
On Fri, 6 Nov 1998, Stephen Waters wrote:
> >>
> >> 11. If L2TP and IPSec are used in conjuc=nction, and there is no ID
> payload
> >>in
> >> the
> >> IKE Phase 2 exchanges, should the default be to a)apply IPSec protection
> to a
> >>ll
> >> IP
> >> packets, b) apply IPSec protection only to packets going through the L2TP
> >> tunnel,
> >> or c) reject the SA proposal?
> >> Consensus appeared to be that only the "tunneled" traffic should get
> >> IPSec
> >> protection.
> >
> > I'm sorry to go against consensus but the draft (when can I start saying
> >RFC?) is specific about this behavior. I originally had some tangled
> verbage
> >on what it meant without client IDs in Quick Mode. Due to WG input it was
> >rewritten to state the following (this in section 5.5 of IKE):
> >
> > The identities of the SAs negotiated in Quick Mode are implicitly
> > assumed to be the IP addresses of the ISAKMP peers, without any
> > implied constraints on the protocol or port numbers allowed, unless
> > client identifiers are specified in Quick Mode.
> >
> >This is then overridden by any information in the client identities. So
> >if there are no client identities the SA is for the whole IP address of
> >the peer with no constraining port/protocol information. It doesn't matter
> >if you're doing L2TP or not. In fact, if you're not passing client IDs
> >how can the peer know your intent is to do L2TP and decide to accept
> >cleartext packets for everything except UDP port 1701?
> >
> > Dan.
>
> Good point. Some interesting points came out of the IPSEC+L2TP testing:
>
> 1) most folk seemed to 'default' to transport-mode IPSEC protection - taking
> the IP/UDP/L2TP
> frames as 'originating packets' - saves adding yet another IP header, and
> there is a good
> chance L2TP has just added an 'Internet' header anyway.
>
> 2) the L2TP spec (I think) allows the UDP port to 'wonder', which makes
> selector-based IPSEC
> tricky (for our implementation at least). It would be 'nice' if the damn
> thing would stick to one port :)
>
> 3) With this 'wondering' in mind, we did contemplate doing some
> 'socket-based' approach for l2tp, so that
> when it opened a UDP port, it would request IPSEC protection on it and the
> quick mode could then
> easily request the exact src/dest UDP port (l2tp folk?). Applying IPSEC at
> the socket layer to support
> L2TP appears to be identical to adding transport-mode once the L2TP packet
> has gained UDP and IP
> headers.
L2TP is allowed to wonder, but a peer is always required to respond to the
source port you select. Thus, you always have control over the source port
for outgoing traffic, and the destination port for incoming traffic. This,
together with the source and destination IP address, is enough to define
an individual l2tp tunnel.
Among other things, it is important to allow multiple source ports in case
you wish to have different policies for different users (tunnels) between
the same two tunnel endpoints (ip addresses).
>
> If L2TP can't be tied-down to a port/set-of-ports, I guess you either lump
> all UDP traffic in the same
> security slot, or do something at the transport-protocol interface (sockets
> approach).
>
> Cheers, Steve.
>
>
>
>