[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.