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

From: "Bill Storer \(bstorer\)" <[email-masked]>
Date: Thu, 1 Jun 2006 11:14:36 -0700

Hi Laurent,

I have some responses under WFS1.

Thanks,

Bill 

> -----Original Message-----
> From: Laurent Toutain [mailto:[email-masked]] 
> Sent: Thursday, June 01, 2006 2:05 AM
> To: [email-masked]
> Subject: [Softwires] Re: [hubs_spokes] L2TP test {02}
> 
> 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.

WFS1  I don't mean to require authentication at the tunnel level.  I
would just like to allow it in case an SC implementor decides they want
it.  I agree it would be significant extra work for the SC, but it
wouldn't be much effort for the SI to do tunnel authentication with a
host name and password provided by the service provider.  

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

WFS1 This AVP is a notification of the LAC's capabilities to communicate
with a remote user.  It isn't relevant to softwires so it seems
reasonable to not to require a value.  Receivers of this AVP should
ignore it.  To be safe, perhaps we should tell the sender that they
SHOULD set both the A and S bit here.  Less chance of an
interoperability problems that way.   

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

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

---

From: "Florent Parent" <[email-masked]>
Date: Fri, 2 Jun 2006 10:13:04 -0400

> > >depending on tunnel authentication.  This makes the

If tunnel authentication is done, could authentication be skipped at
the PPP LCP? Would existing implementation support this? As you
mentioned, this would a closer model to phase2.

> > the user name.

"then get the username", you mean later on during PPP negotiation?

If tunnel authentication is on, the SI sends a SCCRQ message
containing a challenge and a hostname. The latter could be used to
represent the username (as Bill was mentionning).

Is the issue the fact that current implementations don't support doing this?

Florent

---

From: "Laurent Toutain" <[email-masked]>
Date: Fri, 2 Jun 2006 18:30:17 +0200

> mentioned, this would a closer model to phase2.
Your are not olgiged to do authentication at PPP level, it is just define
by configuration.

Yes but L2TP need more hacking in that case. Currentlty L2TP is based
on a single secred shared by every LNS and LAC and there is no link with
AAA which will store passwd. This could be a phase 1.5 not a phase 1.

> "then get the username", you mean later on during PPP negotiation?

no, you have the hostname AVP by you believe it if the shared secret
is correct.

> represent the username (as Bill was mentionning).

Yes

> Is the issue the fact that current implementations don't support doing this?

Implementation as mentionned before and PPP/CHAP has proved to be working
well, if we rewrite something we will have to prove that it is as
stonger as PPP.

> Florent

Laurent
-- 
-----------------------
Serveur web du Point6 => http://www.point6.net
Laurent Toutain
ENST Bretagne
tel +33 2 99 12 70 26 - Fax +33 2 99 12 70 30