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

[Bill B. <bba...@sp...>]

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