Re: [L2tp-develop] lns only likes 1 peer udp port

[Simon H. <sd...@ab...>]

>QUESTION TO THE GROUP:  Is having multiple tunnels per peers an important
>feature?


Yes.

Redback have the capability to switch tunnels at their box to produce
something like the switching of traffic from 1 ingress tunnel onto a
different egress tunnel. A corporate could aggregate traffic onto two
different tunnels both destined for the 'tunnel switch' so that  the traffic
from each tunnel would be treated differently at the switch. The Redback
site is a good source of information in this.


>The idea is actually quite reasonable.  There really aren't any good
>reasons to have multiple tunnels between peers.  The session creation

I disagree with your comment here.


> Is having RADIUS controlled quality of service
>important?

Yes.

I see RADIUS as the service selection mechanism. If you look at the
freeRADIUS project, there is a range of Redback defined TLVs for
implementing this kind functionality. I'd like to see a range of TLVs
defined within the freeRadius project which can be passed to the L2TP LAC to
determine tunnel characteristics. Some are already in place.



When it comes to the use of udp ports, the guiding principle should be the
rfc:

RFC 2661 (L2TP) Remarks on L2Tp over UDP

8.1 L2TP over UDP/IP

L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP packet,
including payload and L2TP header, is sent within a UDP datagram. The
initiator of an L2TP tunnel picks an available source UDP port (which may or
may not be 1701), and sends to the desired destination address at port 1701.
The recipient picks a free port on its own system (which may or may not be
1701), and sends its reply to the initiator's UDP port and address, setting
its own source port to the free port it found. Once the source and
destination ports and addresses are established, they MUST remain static for
the life of the tunnel.

Thus, each tunnel can have its own socket with its own locally assigned udp
port.

Your implementation operates within the rfc but precludes the flexibility
afforded by allowing the client/servers to choose their own ports, in the
time honoured tradition of sockets programming.



>There is a problem however.  Peer's UDP port is derived solely from the
>configuration file.  It should be fixed only when explicitedly specified
>to a non-zero value.  If zero (any port), the source port of the SCCRQ
>message should used.  This is an easy fix.
>

Thanks for this. I'll try it today.

Simon

-----Original Message-----
From: Bill Baumann <bba...@sp...>
To: l2t...@li... <l2t...@li...>;
Simon Hughes <sd...@ab...>
Date: Wednesday, February 06, 2002 8:54 PM
Subject: Re: [L2tp-develop] lns only likes 1 peer udp port


>
>QUESTION TO THE GROUP:  Is having multiple tunnels per peers an important
>feature?  Also stated; Is having RADIUS controlled quality of service
>important?
>
>Simon's question brings up a limitation in the software.  Currently,
>only a single tunnel is allowed between peers.
>
>The issue goes back to confusion from the RFC.  Currently, the software
>allows only a single tunnel between peers.  The confusion lies in the tie
>breaker mechanism.  Should LAC and LNS both try to create a new tunnel at
>the same time, the tie breaker mechanism arbitrates a single tunnel.  I
>misinterpreted this to indicate that LAC and LNS should have only a single
>tunnel between them always.
>
>The idea is actually quite reasonable.  There really aren't any good
>reasons to have multiple tunnels between peers.  The session creation
>mechanism should handle any quality of service information.
>Unfortunately, the RADIUS spec doesn't work that way...  Quality of
>service differentiation happens at the tunnel level.  If you want every
>session to behave slightly differently, they all need their own tunnels.
>
>The multiple tunnels between peers isn't a hard fix, but it is related to
>the tie breaker mechanism.  We have to make sure we don't introduce bugs
>in the process.
>
>
>Simon, getting back to you're original issue...
>
>This error shows up in the message log?  Its the same code for both 6.2
>and 7.1 and should behave identially on both.
>
>Actually, the comment is wrong (sort of).  The code here is actually
>correct.
>
>The snippet of code occurs for data packets only.  For data, the peer's
>UDP port must match that expressed by the signalling layer during tunnel
>creation.  To do otherwise would leave the system more vulernable to
>spoofing attacks.  This line of code should only execute when receiving a
>frame that matches the Tunnel ID and IP address, but with a UDP port that
>doesn't.
>
>There is a problem however.  Peer's UDP port is derived solely from the
>configuration file.  It should be fixed only when explicitedly specified
>to a non-zero value.  If zero (any port), the source port of the SCCRQ
>message should used.  This is an easy fix.
>
>Bill Baumann
>
>
>
>On Wed, 6 Feb 2002, Simon Hughes wrote:
>
>> Hi Bill
>>
>> I have my driver working but I'm running into problems with the RH 6.2
LNS.
>>
>> My re-write of data_xmtr.c uses sockets, one socket on udp 1701 for
>> listening and then 1 socket per created tunnel. All l2tp data packets are
>> sent on the socket for the appropriate tunnel. This causes a problem for
the
>> RH 6.2 LNS. because of the following in data_xfer.c:
>>
>>
>>       /* I think the peer is allowed to change his UDP address in his
first
>> msg... */
>>       else if ( tun->peer_udp != peer_udp )
>>         {
>>           /* FIXME: some implementations may move source UDP port
>>            * to fix this, an interface needs to be created at data layer
>>            * and signaling layer connectors to allow transport to set the
>>            * udp address.  transport also has to be changed to something
>> like
>>            * in rx_ctrl, if known peer_udp == 0, use new port & tell data
>> layer. */
>>           L2TP_LOG_severe( ( "udp addresses do not match.  This could be
a
>> hack or an implementation problem, see code" ) );
>>           status = L2TP_STATUS_peer_udp_port_incorrect;
>>         }
>>
>>
>> Is this the same situation in the RH7.1 release? Any chance of fixing
this ?
>>
>> I need to come back to you RE the processing of lcp packets in
>> /ppp/pppd/l2tp.c (rej/nak ing certain packets). When I get a moment, I'll
>> respond.
>>
>> Simon
>>
>>
>> _______________________________________________
>> L2tp-develop mailing list
>> L2t...@li...
>> https://lists.sourceforge.net/lists/listinfo/l2tp-develop
>>
>>
>
>