[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE:
>>
>> 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.
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.