Subject: [Softwires] RE: draft-ietf-softwire-hs-framework-l2tpv2-00 comments

From: "Bill Storer \(bstorer\)" <[email-masked]>
Date: Fri, 7 Jul 2006 10:52:07 -0700

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Laurent Toutain
	Sent: Friday, July 07, 2006 3:14 AM
	To: Bill Storer (bstorer)
	Cc: JF Tremblay; Carlos Pignataro (cpignata);
[email-masked]; Bruno STEVANT
	Subject: Re: draft-ietf-softwire-hs-framework-l2tpv2-00 comments

		5.1.2.  IPv4
		
		   A Softwire Concentrator MAY provide either globally
routable or 
		   private IPv4 addresses.  If private addresses are
used, the delegated
		   prefix should be in the same address space than the
PPP endpoint to
		   avoid nested NAT configurations.  A globally routable
address is 
		   preferable, since in most cases, it is expected the
CPE device will
		   perform the IPv4 NAT function.
		
		   The PPP link for the IPv4 softwire SHOULD be assigned
a /30.
		
		WFS Why a /30?

	I imagine that since  it is a point to point link /30 allows to
number both ends.
	Do you think shorter prefixes should be allocated if user wants
to have a network
	instead of a host connected to the v4 Internet ?  
	 
	I would think we would assign a single /32 address with IPCP.
Then if we want to assign more
	that would be handled via DHCP PD.  

		   Framing Capabilities AVP
		
		      Synchronous bit MUST be set to 1 and Asynchronous
bit to 0.  This
		      AVP SHOULD be ignored by the receiver.
		
		WFS I still think we should recommend to set both bits
here.  They are
		really meaningless in this context but being less
restrictive should 
		increase our chance of interoperating.
		Perhaps we should run this by Mark Townsley.

	we can swap SHOULD and MUST  
	
	      Synchronous bit SHOULD be set to 1 and Asynchronous bit to
0.  This
	      AVP MUST be ignored by the receiver.

		   Challenge and Challenge Response AVPs 
		
		      Session authentication as defined in [RFC2661] 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 I'm OK with not requiring tunnel authentication.
However, we should
		remove 
		    the statement that the shared secret has to be known
by all users.
		    Both LAC and LNS much have the same secret, however
that secret can
		    be different for each LAC as long as each LAC has a
different
		hostname.

	OK, we can  remove last sentence
	
	      Session authentication as defined in [RFC2661] 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.  

		      While user authentication is typically done at the
PPP level, 
		      tunnel authentication may be helpful in preventing
DoS attacks.
		
		6.2.2.  LCP
		
		   Once the L2TP session is established, the SI
initiates the PPP
		   connection by sending a LCP Configuration Request
message.  The SC 
		   also sends a LCP Configuration Request containing at
least the
		   Maximum Receive Unit option and and authentication
protocol.  If no
		   authentication protocol option is present, the SI
considers the
		   service as un authenticated (see Section 6.2.3).
Each party answers
		   with a Configuration Ack message to finish the link
configuration.
		
		   ### Laurent, do you have an example for this section?

	I will send you some dump of our traffic to specify options. 

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

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