Subject: [Softwires] Re: [hubs_spokes] L2TP test {02}

From: Laurent Toutain <[email-masked]>
Date: Thu, 01 Jun 2006 11:04:48 +0200

Bill Storer (bstorer) wrote:

>Hi Laurent,

Hi,

I moved the thread to Softwires.

>In an effort to make things more readable I've cut out the text from
>your original note and included a fresh copy here.  I've marked my
>comments as WFS.  
>
>
>Thanks,
>
>Bill
>
>  
>
>X.1 Tunnel establishement
>
>The following diagram resumes messages exchange and AVP used to
>establish a communication between a SI (LAC) and a SC (LNS). They
>represent a subset of exchanges defined in [RFC 2661] mostly to limit
>implementation complexity on the SI side. One session per tunnel is
>only needed, since the LAC does not act as a PPP session concentrator.
>The LAC MUST always establishes the session and no outgoing nor
>analogical calls are specified. L2TP attributes SHOULD NOT be hidden.
>
>WFS I'm not sure what you mean above by analog calls.  
>
>
>LAC (SI)    LAC (SC)
>----------  ----------
>SCCRQ ->
>Mandatory AVP
> Message Type
> Protocol Version
> Host Name
> Framing Capabilities
> Assigned Tunnel ID
>Optional AVP:
> Receive Window Size
> Firmware Revision
> Vendor Name
>
>WFS I think challenge should be allowed here as an optional AVP.  
>
OK I will add challenge between parenthesis

>The
>password used by the LNS for an individual LAC can be associated with
>the host name of that LAC.  So you can have a different password for
>each client and do authentication at the earliest possible step here.
>Also, if we decide to go with a "no ppp" option for phase 2, we'll be
>depending on tunnel authentication.  This makes the transition easier.  
>  
>
Phase 1 requires no modification to existing software. Normally current 
implementation, as far
as I know, authentifies the LNS through the shared secret and then get 
the user name. What
you suggested means the opposite take the name and then  do 
authentication. This means that
we have to modifiy LNS (LAC will not be changed). This imply also that 
we link the L2TP
process to AAA.

In the Softwires context, SC needs more design effort since it will be 
linked to AAA and  DHCPv6
and this is a tricky thing. May be it is worth to include that change, 
but I would like to have mailing
list opinion, because we are changing some behaviors from exisiting 
standard and this was not the
purpose of phase 1.

>
>            <- SCCRP
>            Mandatory AVP:
>             Message Type
>             Protocol Version
>             Framing Capabilities
>             Host Name
>             Assigned Tunnel ID
>            Optional AVP:
>             Firmware Revision
>             Vendor Name
>             Receive Window Size
>
>WFS I'd allow challenge and challenge response AVPs as mentioned above.
>
>  
>
OK

>
>SCCCN ->
>Mandatory AVP:
> Message Type
>
>            <- ZLB ACK
>
>WFS I'd allow the challenge response AVP here as mentioned above.  
>
>  
>
OK
...

>Framing Capabilities AVP
>
>        Synchronous bit MUST be set to 1
>
>WFS How about a SHOULD here with a note that it should be ignored by the
>receiver?  Like with Connect Speed below.
>  
>
I don't know. I was thinking that Synchronous means that when LAC receives
a packet from a LNS it sends a packet to the user. and for asynchronous it
sends the packet byte per byte. So we have to mandate Synchronous bit to 1
and we don't care for asynchronous. But of course, if we can avoid to 
take this
AVP into account, that's better.

...

>X.1.2 AVP optional for Softwires
>
>Challenge and Challenge Response AVP :
>
>           Session authentication as defined in [RFC 2661] is based on
>           a shared secret known by LACs and LNSs, and is not designed
>           to authenticate a specific user.  This AVP is not required
>           since security enhancement is not guaranteed. It can be used
>           to limit DoS attack but since this secret has to be known by
>           all users accessing the service, an attacker can learn it
>           easily.
>
>WFS As I mentioned above, while a single secret is required between a
>given LAC and the LNS, it is normal to have a different secret for each
>LAC.  The LNS uses the hostname avp to determine the proper secret for
>the LAC.  I think it would be OK to say something like, "While user
>authentication is typically done at the PPP level, tunnel authentication
>may be helpful in preventing DoS attacks."
>  
>
See my comments below.

>
>            User authentication, if necessary is done at PPP level.
>
>
>X.1.3 AVP not required for Softwires:
>
>Bearer Capabilities and Bearer Type AVP are not needed since no
>outgoing calls are established.
>
>Tie Breaker AVP is not needed since only LAC will establish session to
>the LNS
>
>Physical Channel ID, Called Number, Calling Number and Sub-Address AVP
>are not required since no telephone system are involved in Softwires
>context.
>
>WFS  I would skip the above paragraphs and say something like:  
>
>"L2TP specifies numerous AVPs that, while allowed for a given command,
>are irrelevant to a Softwire.  Softwire implementions should not send
>these AVPs.  However, they should ignore them when they are received.
>This will make it easier to create softwire applications on top of
>existing L2TP implemnetations."
>
>
>
>X.2 Tunnel maintenance
>
>Periodically, SI must transit some message to the SC to maintain
>context in the NAT and can be used to detected tunnel failure (but
>PPP/LCP may be more reactive).  LNS and LAC can generate HELLO
>messages. As specified in [RFC2661] HELLO messages SHOULD be generated
>if no other messages are sent for a period of time. The value of 60
>seconds recommended by [RFC2661] fulfills Softwires constraints.
>
>X.3 Tunnel Teardown
>
>SI and SC can teardown the session and then the tunnel. No change or
>specific parameter are required compared to [RFC2661]. The SI or the SC
>sends an CDN message, acknowledged by ZLB message. The initiator of the
>tunnel teardown, MUST immediately after close the tunnel by sending a
>StopCCN message, acknowledged by a ZLB message.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  
>

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires