On 3/19/07, Bruno STEVANT <bruno.stevant@enst-bretagne.fr> wrote:

For the Mesh framework, it makes sense to have multicast
considerations = included in the Framework document.
For the H&S framework, deploying= multicast is mostly to give to the
involved components of a Softwire a = role in the multicast topology.
No special encap., signaling, etc.

I was addressin= g the question as to whether the hub is part of the L3 infrastructure (and = therefore running PIM) or is just an L2 dumb hub (transiting/broadcasting P= IM messages to the other spokes) - neither appear as deployment-only issues= to me. Either way it will need some mcast smarts and should be addressed i= n the draft.=20

But= there is still some scenarios to explore : ASM/SSM, emmitter and
receiv= er between SI ... This will probably be part of a separate
document, which will be guidelines for deployment.

Again, I don't see these as deployment issues but as actual hub functi= onality issues.

Greg

Le 19 mars 07 =E0 18:07, Greg Shepherd a =E9crit :

> While I agre= e with the mcast portion of the draft - mcast protocols
> run over th= e tunnels - there's no mention of the protocol end-
> points; ie = - is the hub expected to be part of the mcast topology,
> replicating accordingly?
>
> Thanks,
> Greg
&= gt;
> On 2/16/07, Bruno STEVANT <bruno.stevant@enst-bretagne.fr> wrote:
> Hi a= ll,
>
> Carlos and I finally got an update on the H&S draft ou= t yesterday.
> http://www.ietf.org/internet-drafts/draft-ietf-= softwire-hs-framework-
> l2tpv2-03.txt
>
> Now we ask to anyone on the list= to take 10 minutes of their time and
> read this version carefully.<= br>> Any remarks and comments are welcome ! From these feedbacks we hope
> to release a new version before the cut-off for Prague.
>> Enjoy your read !
> --
> Bruno STEVANT - ENST Bretagne>
>
>
> _____________________________________________= __
> Softwires mailing list
> Softwires@ietf.org
> https://www1.ietf.org/mailman/listinfo/softwires >

--
Bruno STEVANT - ENST Bretagne

------=_Part_97388_3846483.1174327020978-- --===============0759177875== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Softwires mailing list Softwires@ietf.org https://www1.ietf.org/mailman/listinfo/softwires --===============0759177875==-- From softwires-bounces@ietf.org Mon Mar 19 17:32:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTPSh-0002yl-Rd; Mon, 19 Mar 2007 17:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTPSg-0002yH-IS for softwires@ietf.org; Mon, 19 Mar 2007 17:32:14 -0400 Received: from [2001:660:7301:3192:211:43ff:fea3:7e4b] (helo=laposte.rennes.enst-bretagne.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTPSN-0004I3-9u for softwires@ietf.org; Mon, 19 Mar 2007 17:32:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id l2JLVeUC004116; Mon, 19 Mar 2007 22:31:40 +0100 Received: from l2.rennes.enst-bretagne.fr (l2.rennes.enst-bretagne.fr [192.44.77.4]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id l2JLVdef004109; Mon, 19 Mar 2007 22:31:39 +0100 Received: from [192.168.1.101] (gr8k.fasmz.org [82.240.213.5]) (authenticated bits=0) by l2.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id l2JLVa7U003948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 22:31:38 +0100 In-Reply-To: <38c19b540703191057x23368afag1715c2de6d45f72b@mail.gmail.com> References: <38c19b540703191007j55028465yb2dca3ca38ba7d99@mail.gmail.com> <97909878-8CE2-4042-B04E-683B382EA4E7@enst-bretagne.fr> <38c19b540703191057x23368afag1715c2de6d45f72b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Bruno STEVANT Subject: Re: [Softwires] Updates on H&S framework draft Date: Mon, 19 Mar 2007 22:31:16 +0100 To: "Greg Shepherd" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: softwires@ietf.org X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: softwires-bounces@ietf.org Le 19 mars 07 =E0 18:57, Greg Shepherd a =E9crit : > > On 3/19/07, Bruno STEVANT wrote: =20 > For the Mesh framework, it makes sense to have multicast > considerations included in the Framework document. > For the H&S framework, deploying multicast is mostly to give to the > involved components of a Softwire a role in the multicast topology. > No special encap., signaling, etc. > > I was addressing the question as to whether the hub is part of the =20 > L3 infrastructure (and therefore running PIM) or is just an L2 dumb =20= > hub (transiting/broadcasting PIM messages to the other spokes) - =20 > neither appear as deployment-only issues to me. Either way it will =20 > need some mcast smarts and should be addressed in the draft. > The hub (or Softwires Concentrator as we call it) has one main =20 connection to the IPv6 network and several tunnels. In Phase 0, using L2TPv2, bridging between tunnel and main connection =20= (Ethernet) is not possible (or am I wrong somewhere ?) So SC is part of L3 infrastructure as a router, and indeed should =20 include features to enable multicast. Softwires Problem Statement mentions Multicast as one of the =20 requirement as : "Existing multicast solutions can be used over the softwire." I think we addressed that requirement sufficiently with : "Multicast protocols simply run over L2TPv2 Softwires transparently =20 together with other regular IP traffic." Now what about the SC role in the multicast infrastructure ? We shall also ask the same question about the SI. Should they be proxy ? Multicast router ? I think that answering such question is already talking about =20 deployment. And therefore this should be addressed in a separate =20 document. --=20 Bruno STEVANT - ENST Bretagne _______________________________________________ Softwires mailing list Softwires@ietf.org https://www1.ietf.org/mailman/listinfo/softwires From softwires-bounces@ietf.org Mon Mar 19 18:02:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTPvs-0004YM-GG; Mon, 19 Mar 2007 18:02:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTPvr-0004Y9-3q for softwires@ietf.org; Mon, 19 Mar 2007 18:02:23 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTPvU-0000W8-HH for softwires@ietf.org; Mon, 19 Mar 2007 18:02:23 -0400 Received: by nf-out-0910.google.com with SMTP id l36so62336nfa for ; Mon, 19 Mar 2007 15:01:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qazIM/0TqYkm+SpYAze9MOrLXwoj28Qpy43vwCQFLwnZUHdbW2M5gtQFBs7n8SJ/QrRWppbG24cfu5fw2jExYsI6IM2runJuRaQrr0sHaeiyyraw/PjC/Vg8CsGjgdpxRAu+3OJbdxh6s5LdPMutXmJVdOp3JspTExsnY/MKkKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=L3HCDYP3am7McMLVpKa8wL8jqN3iGDq5yeArtkIPCcvp7TdKc3nMrbeinZfQz2a5ZibL4Zzxk+x8SZoi5s557p/OR15CZRRDIb52iswrStDCqFrgYcvZo3IPBcDo1HEG7d64Fh4oe4ussZFBRA/493QdA3i/x5bZdRoIsme6JSo= Received: by 10.78.181.13 with SMTP id d13mr2703259huf.1174341718920; Mon, 19 Mar 2007 15:01:58 -0700 (PDT) Received: by 10.78.14.18 with HTTP; Mon, 19 Mar 2007 15:01:58 -0700 (PDT) Message-ID: <38c19b540703191501t54013116ia632cfd4052b581d@mail.gmail.com> Date: Mon, 19 Mar 2007 15:01:58 -0700 From: "Greg Shepherd" To: "Bruno STEVANT" Subject: Re: [Softwires] Updates on H&S framework draft In-Reply-To: MIME-Version: 1.0 References: <38c19b540703191007j55028465yb2dca3ca38ba7d99@mail.gmail.com> <97909878-8CE2-4042-B04E-683B382EA4E7@enst-bretagne.fr> <38c19b540703191057x23368afag1715c2de6d45f72b@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: softwires@ietf.org X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1842979211==" Errors-To: softwires-bounces@ietf.org --===============1842979211== Content-Type: multipart/alternative; boundary="----=_Part_100789_24290090.1174341718830" ------=_Part_100789_24290090.1174341718830 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/19/07, Bruno STEVANT wrote: > > > Le 19 mars 07 =E0 18:57, Greg Shepherd a =E9crit : > > > > On 3/19/07, Bruno STEVANT wrote: > > For the Mesh framework, it makes sense to have multicast > > considerations included in the Framework document. > > For the H&S framework, deploying multicast is mostly to give to the > > involved components of a Softwire a role in the multicast topology. > > No special encap., signaling, etc. > > > > I was addressing the question as to whether the hub is part of the > > L3 infrastructure (and therefore running PIM) or is just an L2 dumb > > hub (transiting/broadcasting PIM messages to the other spokes) - > > neither appear as deployment-only issues to me. Either way it will > > need some mcast smarts and should be addressed in the draft. > > > > The hub (or Softwires Concentrator as we call it) has one main > connection to the IPv6 network and several tunnels. > In Phase 0, using L2TPv2, bridging between tunnel and main connection > (Ethernet) is not possible (or am I wrong somewhere ?) > So SC is part of L3 infrastructure as a router, and indeed should > include features to enable multicast. > > Softwires Problem Statement mentions Multicast as one of the > requirement as : > "Existing multicast solutions can be used over the softwire." > > I think we addressed that requirement sufficiently with : > "Multicast protocols simply run over L2TPv2 Softwires transparently > together with other regular IP traffic." > > Now what about the SC role in the multicast infrastructure ? > We shall also ask the same question about the SI. > Should they be proxy ? Multicast router ? > > I think that answering such question is already talking about > deployment. And therefore this should be addressed in a separate > document. Maybe I'm miss-understanding the use of the work "deployment". These sound like implementation issue. Greg -- > Bruno STEVANT - ENST Bretagne > > > ------=_Part_100789_24290090.1174341718830 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 3/19/07, Bruno STEVANT <bruno.stevant@enst-bretagne.fr> wrote:

Le 19 mars 07 =E0 18:57, Greg Shepherd a =E9crit :
>
> On 3= /19/07, Bruno STEVANT <bruno.stevant@enst-bretagne.fr> wrote:
> For the Mesh framewo= rk, it makes sense to have multicast
> considerations included in the Framework document.
> For the= H&S framework, deploying multicast is mostly to give to the
> in= volved components of a Softwire a role in the multicast topology.
> N= o special encap., signaling, etc.
>
> I was addressing the question as to whether the hub is par= t of the
> L3 infrastructure (and therefore running PIM) or is just a= n L2 dumb
> hub (transiting/broadcasting PIM messages to the other sp= okes) -
> neither appear as deployment-only issues to me. Either way it will=
> need some mcast smarts and should be addressed in the draft.
&g= t;

The hub (or Softwires Concentrator as we call it) has one main
connection to the IPv6 network and several tunnels.
In Phase 0, usin= g L2TPv2, bridging between tunnel and main connection
(Ethernet) is not = possible (or am I wrong somewhere ?)
So SC is part of L3 infrastructure = as a router, and indeed should
include features to enable multicast.

Softwires Problem Statemen= t mentions Multicast as one of the
requirement as :
"Existing mu= lticast solutions can be used over the softwire."

I think we ad= dressed that requirement sufficiently with :
"Multicast protocols simply run over L2TPv2 Softwires transparentl= y
together with other regular IP traffic."

Now what about th= e SC role in the multicast infrastructure ?
We shall also ask the same q= uestion about the SI.
Should they be proxy ? Multicast router ?

I think that answering= such question is already talking about
deployment. And therefore this s= hould be addressed in a separate
document.

Maybe I&= #39;m miss-understanding the use of the work "deployment". These = sound like implementation issue.=20

Greg

--
Bruno STEVANT - ENST Bretagne

------=_Part_100789_24290090.1174341718830-- --===============1842979211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Softwires mailing list Softwires@ietf.org https://www1.ietf.org/mailman/listinfo/softwires --===============1842979211==-- From softwires-bounces@ietf.org Wed Mar 21 09:29:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0sW-00015V-Aa; Wed, 21 Mar 2007 09:29:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0sU-00015L-Ii for softwires@ietf.org; Wed, 21 Mar 2007 09:29:22 -0400 Received: from modemcable210.79-70-69.static.videotron.ca ([69.70.79.210] helo=mail.beon.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU0sK-0003ch-CQ for softwires@ietf.org; Wed, 21 Mar 2007 09:29:22 -0400 Received: from dhcp-1670.ietf68.org (dhcp-1670.ietf68.org [130.129.22.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Florent.Parent@beon.ca", Issuer "Beon Solutions CA" (verified OK)) by mail.beon.ca (Postfix) with ESMTP id D83B6AD768; Wed, 21 Mar 2007 09:29:07 -0400 (EDT) Date: Wed, 21 Mar 2007 14:29:09 +0100 From: Florent Parent To: Yasuhiro SHIRASAKI Subject: Re: [Softwires] Comments on draft-ietf-softwire-security-requirements-02 Message-ID: In-Reply-To: <20070319.185723.52905704.yasuhiro@nttv6.jp> References: <20070319.185723.52905704.yasuhiro@nttv6.jp> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.2 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: softwires@ietf.org X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: softwires-bounces@ietf.org Hello Yasuhiro. Thanks for taking time to comment the draft. My comments inline. --On 19 mars 2007 18:57:23 +0900 Yasuhiro SHIRASAKI wrote: > Hi, > > I just read the draft and I had some comments as follows: > >> 1. Introduction >> Layer Two Tunneling Protocol (L2TPv2) selected for "Hubs and Spokes" >> solution MUST use IPsec if the secure communication is >> required[RFC3193]. This document provides the implementation >> guidance (and proper usage) of IPsec as the security protection >> mechanism by considering the various security vulnerabilities in >> "Hubs and Spokes" scenarios. IKEv2 SHOULD be used in the key >> management protocol for IPsec as the reason of the future proven >> technology as opposed to IKEv1. > > I think it's less important to secure the communication > of the devices which have direct access to its home carrier > network. therefore I think it's better to clarify that > securing the communication for normadic access scenario > is important by modifying first sentence. e.g. > > 'For normadic access scenario of "Hubs and Spokes" solution, > using IPsec as described in [RFC3193] is applicable and strongly > desired and recommenced to secure the communication.' This document does not want to mandate IPsec in *all* cases. We tried to identify scenarios where security is required, and what security to apply (IPsec). We'll change some text in the introduction to clarify this. The security analysis in RFC 3193 is quite appropriate for this draft. This draft will describe how recommendations from RFC 3193 can be applied using the new IPsec security architecture (RFC4301) and IKEv2. > >> 3.1. Deployment Scenarios >> However, the host device may not always have direct access to its >> home carrier network, to which the user has subscribed. For example, >> the softwire initiator in the laptop PC can access various access >> networks such as Wi-Fi hot-spots, visited office network. This is >> the nomadic case, which the Softwire SHOULD support. > > ditto, I think it's better to add the words for clarification. > e.g. 'in this normadic case, using IPsec is strongly desired > and recommended. therefore, IPsec implementation SHOULD be > suppored by the softwire.' The reason IPsec is not mentioned here is that we haven't yet discussed what are the security requirements (defined in 3.4). We're just stating a "use case" for softwire. > >> 3.4.1.1. PPP Authentication >> >> PPP can provide mutual authentication between the SI and SC using >> CHAP [RFC1994] during the connection establishment phase (Link >> Control Protocol, LCP). PPP CHAP authentication can be used when the >> SI and SC are on a trusted, non-public IP network. >> >> Since CHAP does not provide per-packet authentication, integrity, or >> replay protection, PPP CHAP authentication MUST NOT be used >> unprotected on a public IP network. > > I think here is a gap in the logic. PPP CHAP and other mechanism > (IPsec) could be co-existent. so there seems to be no reason > to eliminate PPP CHAP. I agree that we should not eliminate CHAP, and we are not. The key word here is "unprotected". If you're L2TP tunnel is protected using IPsec, nothing here prohibits using CHAP user authentication. > >> 3.4.1.1.1. L2TPv2 Authentication >> >> L2TPv2 provides an optional CHAP-like[RFC1994] tunnel authentication >> during the control connection establishment [RFC2661, 5.1.1]. The >> same restrictions apply to L2TPv2 authentication and PPP CHAP. > > ditto. Ditto :) We'll add some text to clarify that L2TPv2 should not be used unprotected, as for CHAP. Sounds ok? Thanks again. Florent _______________________________________________ Softwires mailing list Softwires@ietf.org https://www1.ietf.org/mailman/listinfo/softwires From softwires-bounces@ietf.org Wed Mar 21 10:50:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU299-00051f-Oe; Wed, 21 Mar 2007 10:50:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU293-0004mf-SK; Wed, 21 Mar 2007 10:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HU292-0003Zt-I0; Wed, 21 Mar 2007 10:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 78A3C2AC5D; Wed, 21 Mar 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HU28Y-0007Ws-8g; Wed, 21 Mar 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: softwires@ietf.org Subject: [Softwires] I-D ACTION:draft-ietf-softwire-problem-statement-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: softwires-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Softwire Problem Statement Author(s) : S. Dawkins Filename : draft-ietf-softwire-problem-statement-03.txt Pages : 29 Date : 2007-3-21 This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-problem-statement-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-softwire-problem-statement-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-softwire-problem-statement-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-21061338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-softwire-problem-statement-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-softwire-problem-statement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-21061338.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Softwires mailing list Softwires@ietf.org https://www1.ietf.org/mailman/listinfo/softwires --NextPart-- From softwires-bounces@ietf.org Thu Mar 22 08:45:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMg1-00032T-OT; Thu, 22 Mar 2007 08:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMg0-00031b-HG for softwires@ietf.org; Thu, 22 Mar 2007 08:45:56 -0400 Received: from gura.nttv6.jp ([2001:218:1:1040::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMfj-0004YW-Mo for softwires@ietf.org; Thu, 22 Mar 2007 08:45:56 -0400 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [IPv6:2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 81DDC1FE3F; Thu, 22 Mar 2007 21:45:22 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 0768E1296F9; Thu, 22 Mar 2007 21:45:22 +0900 (JST) Date: Thu, 22 Mar 2007 21:45:09 +0900 (JST) Message-Id: <20070322.214509.41631973.yasuhiro@nttv6.jp> To: Florent.Parent@beon.ca Subject: Re: [Softwires] Comments on draft-ietf-softwire-security-requirements-02 From: Yasuhiro SHIRASAKI In-Reply-To: References: <20070319.185723.52905704.yasuhiro@nttv6.jp> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: softwires@ietf.org X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: softwires-bounces@ietf.org Hi Florent, On Wed, 21 Mar 2007 14:29:09 +0100, Florent Parent wrote: > > Hello Yasuhiro. > > Thanks for taking time to comment the draft. My comments inline. > > --On 19 mars 2007 18:57:23 +0900 Yasuhiro SHIRASAKI > wrote: > > > Hi, > > > > I just read the draft and I had some comments as follows: > > > >> 1. Introduction > >> Layer Two Tunneling Protocol (L2TPv2) selected for "Hubs and Spokes" > >> solution MUST use IPsec if the secure communication is > >> required[RFC3193]. This document provides the implementation > >> guidance (and proper usage) of IPsec as the security protection > >> mechanism by considering the various security vulnerabilities in > >> "Hubs and Spokes" scenarios. IKEv2 SHOULD be used in the key > >> management protocol for IPsec as the reason of the future proven > >> technology as opposed to IKEv1. > > > > I think it's less important to secure the communication > > of the devices which have direct access to its home carrier > > network. therefore I think it's better to clarify that > > securing the communication for normadic access scenario > > is important by modifying first sentence. e.g. > > > > 'For normadic access scenario of "Hubs and Spokes" solution, > > using IPsec as described in [RFC3193] is applicable and strongly > > desired and recommenced to secure the communication.' > > This document does not want to mandate IPsec in *all* cases. We tried to > identify scenarios where security is required, and what security to apply > (IPsec). We'll change some text in the introduction to clarify this. > > The security analysis in RFC 3193 is quite appropriate for this draft. This > draft will describe how recommendations from RFC 3193 can be applied using > the new IPsec security architecture (RFC4301) and IKEv2. When I read the draft, I was afraid that IPsec would be mandated. That's the reason why I sent my comments. I believe the clarification helps a lot. > >> 3.1. Deployment Scenarios > >> However, the host device may not always have direct access to its > >> home carrier network, to which the user has subscribed. For example, > >> the softwire initiator in the laptop PC can access various access > >> networks such as Wi-Fi hot-spots, visited office network. This is > >> the nomadic case, which the Softwire SHOULD support. > > > > ditto, I think it's better to add the words for clarification. > > e.g. 'in this normadic case, using IPsec is strongly desired > > and recommended. therefore, IPsec implementation SHOULD be > > suppored by the softwire.' > > The reason IPsec is not mentioned here is that we haven't yet discussed > what are the security requirements (defined in 3.4). We're just stating a > "use case" for softwire. agree. > >> 3.4.1.1. PPP Authentication > >> > >> PPP can provide mutual authentication between the SI and SC using > >> CHAP [RFC1994] during the connection establishment phase (Link > >> Control Protocol, LCP). PPP CHAP authentication can be used when the > >> SI and SC are on a trusted, non-public IP network. > >> > >> Since CHAP does not provide per-packet authentication, integrity, or > >> replay protection, PPP CHAP authentication MUST NOT be used > >> unprotected on a public IP network. > > > > I think here is a gap in the logic. PPP CHAP and other mechanism > > (IPsec) could be co-existent. so there seems to be no reason > > to eliminate PPP CHAP. > > I agree that we should not eliminate CHAP, and we are not. The key word > here is "unprotected". If you're L2TP tunnel is protected using IPsec, > nothing here prohibits using CHAP user authentication. I got your point. > >> 3.4.1.1.1. L2TPv2 Authentication > >> > >> L2TPv2 provides an optional CHAP-like[RFC1994] tunnel authentication > >> during the control connection establishment [RFC2661, 5.1.1]. The > >> same restrictions apply to L2TPv2 authentication and PPP CHAP. > > > > ditto. > > Ditto :) > > We'll add some text to clarify that L2TPv2 should not be used unprotected, > as for CHAP. Sounds ok? sounds nice. thanks. -- Yasuhiro SHIRASAKI @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 _______________________________________________ Softwires mailing list Softwires@ietf.org https://www1.ietf.org/mailman/listinfo/softwires