From secdir-bounces@ietf.org Sat Nov 1 17:21:53 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5753A6866; Sat, 1 Nov 2008 17:21:53 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8833A6866 for ; Sat, 1 Nov 2008 17:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MpI2pnArn5P for ; Sat, 1 Nov 2008 17:21:50 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5DB803A67AC for ; Sat, 1 Nov 2008 17:21:50 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA20Lmjf028897 for ; Sat, 1 Nov 2008 20:21:48 -0400 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA20LgaJ028875 for ; Sat, 1 Nov 2008 20:21:42 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id mA20LLTK025753; Sat, 1 Nov 2008 20:21:23 -0400 (EDT) Received: from morannon (ool-43501d19.dyn.optonline.net [67.80.29.25]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mA20LGaj015537 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 1 Nov 2008 20:21:17 -0400 (EDT) From: "Uri Blumenthal" To: "'Avri Doria'" , "'Jamal Hadi Salim'" , "'Ross Callon'" References: <4C5E6457CD7911469A07260381288C280A171EAF@orsmsx502.amr.corp.intel.com> <1222602418.5157.77.camel@localhost> <1223842467.4934.84.camel@localhost> <1224531850.4755.5.camel@localhost> <1225286967.4692.12.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013095@emailwf1.jnpr.net> <1225374490.4684.21.camel@localhost> Date: Sat, 1 Nov 2008 20:21:18 -0400 Organization: Massachusetts Institute of Technology Message-ID: <6FB661FFA3244D41A23FFC862AB6A23A@morannon> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: Thread-Index: Ack6oRCiRSJ5Jvo7RUmPi0q0KUK4FQB3tEzw X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: 'Weiming Wang' , secdir@mit.edu, "'Khosravi, Hormuzd M'" , iesg@ietf.org, 'Patrick Droz' , 'Robert Haas' Subject: Re: [secdir] Review of draft-ietf-forces-protocol-16 (now -18) X-BeenThere: secdir@ietf.org Reply-To: uri@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 1. Apologies for dealying the response - but reply to my comments missed my "sweet spot" in the schedule and thus had to wait till my next window opens. 2. In general, Security Considerations section of the Architecture document (RFC 3746) adequately deals with the issue. However RFC3746 is an INFORMATIONAL document, while this draft seems to claim the STANDARD track. I think that Standards-track document cannot refer to Informational. If I'm wrong (and you can) - just rename the existing (unmodified) "Security Consideration" section to "Security Mechanisms" or such, and add a one-statement "Security Consideration" that refers the reader to RFC 3746. If I'm right (that you can refer to Informational), then instead of the text you're proposing you'd have to copy the entire section from RFC 3746. -----Original Message----- From: Avri Doria [mailto:avri@ltu.se] Sent: Thursday, October 30, 2008 11:05 To: Jamal Hadi Salim; Ross Callon Cc: uri@MIT.EDU; Khosravi, Hormuzd M; Robert Haas; Weiming Wang; Patrick Droz Subject: Re: Review of draft-ietf-forces-protocol-16 (now -18) Hi, Thanks for making my excuses. Fortunately with your help I was able to get it submitted. And now off to the airport for a full week of 'fun' with ICANN in Cairo. a. On 30 Oct 2008, at 09:48, Jamal Hadi Salim wrote: > Ross, > > We are going to make a very small change and submit. Avri is going to > be travelling today and will be overloaded in the next week. > She may get to it and submit the new version today. Your call on > whether you want it in this upcoming call or next if we dont make it > in. > > The change we are making (which seems sufficient to address Uri's > concern) is: > > ------------------ Protocol draft section 9 ------- > > 9. Security Considerations > > ForCES architecture identifies several levels of security in > [RFC3746]. ForCES PL uses security services provided by the ForCES > TML. The TML provides security services such as endpoint > authentication service, message authentication service and > confidentiality service. Endpoint authentication service is invoked > at the time of the pre-association connection establishment phase > and > message authentication is performed whenever the FE or CE receives a > packet from its peer. > ---------------------------------------------------------------------- > - > > suggestion changes to: > > ----------- > 9. Security Considerations > > The ForCES Framework document[RFC3746], section 8, goes into a > lot of details and identifies several levels of security > challenges. This document does not repeat that discussion, the > reader is referred to the ForCES Framework document[RFC3746] > for those details and how ForCES architecture addresses them. > > ForCES PL uses security services provided by the ForCES > TML. The TML provides security services such as endpoint > authentication service, message authentication service and > confidentiality service. Endpoint authentication service is invoked > at the time of the pre-association connection establishment phase > and > message authentication is performed whenever the FE or CE receives a > packet from its peer. > --------------- > > cheers, > jamal > > On Wed, 2008-29-10 at 11:00 -0400, Ross Callon wrote: >> Jamal; >> >> I think that if you don't hear back by sometime tomorrow, you should >> go ahead and post the updated draft and I will put it (and its MIB) >> onto the IESG agenda for next week. >> >> Thanks, Ross > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Nov 2 18:46:06 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FB428C244; Sun, 2 Nov 2008 18:46:05 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8EB3A6809 for ; Sun, 2 Nov 2008 18:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.105 X-Spam-Level: X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsHbcNERJNdY for ; Sun, 2 Nov 2008 18:46:04 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id E212D28C1B2 for ; Sun, 2 Nov 2008 18:45:36 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA32jYU2006816 for ; Sun, 2 Nov 2008 21:45:34 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA32jVDX006813 for ; Sun, 2 Nov 2008 21:45:31 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mA32jOfs010016 for ; Sun, 2 Nov 2008 21:45:24 -0500 (EST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 8C19911F3556; Sun, 2 Nov 2008 21:44:10 -0500 (EST) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Sun, 02 Nov 2008 18:44:31 PST Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Nov 2008 18:42:18 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Nov 2008 18:42:18 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 2 Nov 2008 21:42:15 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05013B2E@emailwf1.jnpr.net> In-Reply-To: <1225677420.4692.22.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-forces-protocol-16 (now -18) Thread-Index: Ack9V4NORstqfcWMQF+4saQPNYSjNwAAPa8g References: <4C5E6457CD7911469A07260381288C280A171EAF@orsmsx502.amr.corp.intel.com> <1222602418.5157.77.camel@localhost> <1223842467.4934.84.camel@localhost> <1224531850.4755.5.camel@localhost> <1225286967.4692.12.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013095@emailwf1.jnpr.net> <1225374490.4684.21.camel@localhost> <6FB661FFA3244D41A23FFC862AB6A23A@morannon> <1225677420.4692.22.camel@localhost> From: "Ross Callon" To: , X-OriginalArrivalTime: 03 Nov 2008 02:42:18.0243 (UTC) FILETIME=[C9B9F530:01C93D5D] X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id mA32jVDX006813 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Weiming Wang , secdir@mit.edu, Avri Doria , "Khosravi, Hormuzd M" , iesg@ietf.org, Patrick Droz , Robert Haas Subject: Re: [secdir] Review of draft-ietf-forces-protocol-16 (now -18) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Standards track documents can have normative references to informational documents. However, this needs to be explicitly called out in the IETF last call. Thus to do this would requiring repeating the last call (it also requires listing the downref in a registry, but I can take care of that when putting the document onto an IESG agenda). I didn't get this onto the agenda for this week's telechat (My apologies, I didn't get to it until Friday night, which is too late). Thus it will need to go onto a telechat very soon after the Minneapolis IETF. Thus repeating the IETF last call won't slow it down by much. Thanks, Ross -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] Sent: 02 November 2008 20:57 To: uri@MIT.EDU Cc: 'Avri Doria'; Ross Callon; 'Khosravi, Hormuzd M'; 'Robert Haas'; 'Weiming Wang'; 'Patrick Droz'; secdir@MIT.EDU; iesg@ietf.org Subject: RE: Review of draft-ietf-forces-protocol-16 (now -18) Hi Uri, On Sat, 2008-01-11 at 20:21 -0400, Uri Blumenthal wrote: > 1. Apologies for dealying the response - but reply to my comments missed my > "sweet spot" in the schedule and thus had to wait till my next window opens. Understandable; we all get busy - Thanks for taking the effort to respond. > 2. In general, Security Considerations section of the Architecture document > (RFC 3746) adequately deals with the issue. However RFC3746 is an > INFORMATIONAL document, while this draft seems to claim the STANDARD track. > I think that Standards-track document cannot refer to Informational. If I'm > wrong (and you can) - just rename the existing (unmodified) "Security > Consideration" section to "Security Mechanisms" or such, and add a > one-statement "Security Consideration" that refers the reader to RFC 3746. > If I'm right (that you can refer to Informational), then instead of the text > you're proposing you'd have to copy the entire section from RFC 3746. > I will have to review the rules to be sure. Is rule this documented somewhere? Ross, to reiterate/sumarize what Uri is saying above: The document(RFC 3746) we reference in the security section is informational. Given the protocol is shooting for standard track it cant reference that doc as authoritative and we would have to cutnpaste the statements made in RFC 3746 into the security section of the protocol. I dont think this is a show-stopper for the telechat inclusion; however, if indeed the above is needed we will make a new release probably after your telechat which doesnt change really the semantics of the doc (rather just adds content which was previously being referenced). cheers, jamal _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Nov 3 00:36:00 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618433A69E6; Mon, 3 Nov 2008 00:36:00 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F9C3A6809 for ; Sun, 2 Nov 2008 17:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVRI3jKYmmkD for ; Sun, 2 Nov 2008 17:58:08 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8A58F28C211 for ; Sun, 2 Nov 2008 17:58:08 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA31w6lt031785 for ; Sun, 2 Nov 2008 20:58:06 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA31vwCM031764 for ; Sun, 2 Nov 2008 20:57:58 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mA31vpSh027438 for ; Sun, 2 Nov 2008 20:57:52 -0500 (EST) Received: from mailhub.znyx.com (mailhub.znyx.com [208.2.156.141]) by mit.edu (Spam Firewall) with ESMTP id 0F5E0135BDA7; Sun, 2 Nov 2008 20:57:30 -0500 (EST) Received: from localhost (jeep.znyx.com [208.2.156.20]) by mailhub.znyx.com (8.12.9/8.12.8) with ESMTP id mA31cnPR066530; Sun, 2 Nov 2008 17:38:50 -0800 (PST) (envelope-from hadi@znyx.com) From: Jamal Hadi Salim To: uri@mit.edu In-Reply-To: <6FB661FFA3244D41A23FFC862AB6A23A@morannon> References: <4C5E6457CD7911469A07260381288C280A171EAF@orsmsx502.amr.corp.intel.com> <1222602418.5157.77.camel@localhost> <1223842467.4934.84.camel@localhost> <1224531850.4755.5.camel@localhost> <1225286967.4692.12.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013095@emailwf1.jnpr.net> <1225374490.4684.21.camel@localhost> <6FB661FFA3244D41A23FFC862AB6A23A@morannon> Organization: ZNYX Networks Date: Sun, 02 Nov 2008 20:57:00 -0500 Message-Id: <1225677420.4692.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Mon, 03 Nov 2008 00:35:59 -0800 Cc: 'Weiming Wang' , secdir@mit.edu, 'Avri Doria' , "'Khosravi, Hormuzd M'" , iesg@ietf.org, 'Ross Callon' , 'Patrick Droz' , 'Robert Haas' Subject: Re: [secdir] Review of draft-ietf-forces-protocol-16 (now -18) X-BeenThere: secdir@ietf.org Reply-To: hadi@znyx.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Uri, On Sat, 2008-01-11 at 20:21 -0400, Uri Blumenthal wrote: > 1. Apologies for dealying the response - but reply to my comments missed my > "sweet spot" in the schedule and thus had to wait till my next window opens. Understandable; we all get busy - Thanks for taking the effort to respond. > 2. In general, Security Considerations section of the Architecture document > (RFC 3746) adequately deals with the issue. However RFC3746 is an > INFORMATIONAL document, while this draft seems to claim the STANDARD track. > I think that Standards-track document cannot refer to Informational. If I'm > wrong (and you can) - just rename the existing (unmodified) "Security > Consideration" section to "Security Mechanisms" or such, and add a > one-statement "Security Consideration" that refers the reader to RFC 3746. > If I'm right (that you can refer to Informational), then instead of the text > you're proposing you'd have to copy the entire section from RFC 3746. > I will have to review the rules to be sure. Is rule this documented somewhere? Ross, to reiterate/sumarize what Uri is saying above: The document(RFC 3746) we reference in the security section is informational. Given the protocol is shooting for standard track it cant reference that doc as authoritative and we would have to cutnpaste the statements made in RFC 3746 into the security section of the protocol. I dont think this is a show-stopper for the telechat inclusion; however, if indeed the above is needed we will make a new release probably after your telechat which doesnt change really the semantics of the doc (rather just adds content which was previously being referenced). cheers, jamal _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Nov 3 08:22:21 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44F83A69B5; Mon, 3 Nov 2008 08:22:21 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44CBC28C180 for ; Mon, 3 Nov 2008 06:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ5K9ddi95to for ; Mon, 3 Nov 2008 06:55:29 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 61F0B28C1BC for ; Mon, 3 Nov 2008 06:55:29 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA3EtR9x011683 for ; Mon, 3 Nov 2008 09:55:27 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA3EtKB4011670 for ; Mon, 3 Nov 2008 09:55:20 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id mA3EtDlW024571 for ; Mon, 3 Nov 2008 09:55:13 -0500 (EST) Received: from mailhub.znyx.com (mailhub.znyx.com [208.2.156.141]) by mit.edu (Spam Firewall) with ESMTP id 75F5A13862B3; Mon, 3 Nov 2008 09:54:52 -0500 (EST) Received: from localhost (jeep.znyx.com [208.2.156.20]) by mailhub.znyx.com (8.12.9/8.12.8) with ESMTP id mA3EX3PR003519; Mon, 3 Nov 2008 06:33:04 -0800 (PST) (envelope-from hadi@znyx.com) From: Jamal Hadi Salim To: Ross Callon In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C05013B2E@emailwf1.jnpr.net> References: <4C5E6457CD7911469A07260381288C280A171EAF@orsmsx502.amr.corp.intel.com> <1222602418.5157.77.camel@localhost> <1223842467.4934.84.camel@localhost> <1224531850.4755.5.camel@localhost> <1225286967.4692.12.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013095@emailwf1.jnpr.net> <1225374490.4684.21.camel@localhost> <6FB661FFA3244D41A23FFC862AB6A23A@morannon> <1225677420.4692.22.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013B2E@emailwf1.jnpr.net> Organization: ZNYX Networks Date: Mon, 03 Nov 2008 09:51:19 -0500 Message-Id: <1225723879.4692.33.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Mon, 03 Nov 2008 08:22:20 -0800 Cc: Weiming Wang , secdir@mit.edu, Avri Doria , "Khosravi, Hormuzd M" , iesg@ietf.org, Patrick Droz , Robert Haas Subject: Re: [secdir] Review of draft-ietf-forces-protocol-16 (now -18) X-BeenThere: secdir@ietf.org Reply-To: hadi@znyx.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Ross, So the choice is either repeating the last call or copying the content? Since we missed the IESG agenda and we have at least 2 weeks, I dont mind just adding cutnpasting that content (then we can avoid the downref altogether). Thoughts? cheers, jamal On Sun, 2008-02-11 at 21:42 -0500, Ross Callon wrote: > Standards track documents can have normative references to informational > documents. However, this needs to be explicitly called out in the IETF > last call. Thus to do this would requiring repeating the last call (it > also requires listing the downref in a registry, but I can take care of > that when putting the document onto an IESG agenda). > > I didn't get this onto the agenda for this week's telechat (My > apologies, I didn't get to it until Friday night, which is too late). > Thus it will need to go onto a telechat very soon after the Minneapolis > IETF. Thus repeating the IETF last call won't slow it down by much. > > Thanks, Ross _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Nov 3 12:09:54 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E403A6C49; Mon, 3 Nov 2008 12:09:54 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38C028C265 for ; Mon, 3 Nov 2008 12:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk--aO0vfEV7 for ; Mon, 3 Nov 2008 12:09:51 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1564B28C2A4 for ; Mon, 3 Nov 2008 12:07:07 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA3K74K6021993 for ; Mon, 3 Nov 2008 15:07:04 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA3K6tGg021917 for ; Mon, 3 Nov 2008 15:06:57 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mA3K6l0Z004915 for ; Mon, 3 Nov 2008 15:06:47 -0500 (EST) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id CE599C02A84; Mon, 3 Nov 2008 15:06:26 -0500 (EST) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Mon, 03 Nov 2008 12:06:46 PST Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 12:05:21 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 12:05:21 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Nov 2008 15:05:16 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05013E27@emailwf1.jnpr.net> In-Reply-To: <1225723879.4692.33.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-forces-protocol-16 (now -18) Thread-Index: Ack9xBrA/NOgR9YFTFGSMG1G1jhncwAKxtrA References: <4C5E6457CD7911469A07260381288C280A171EAF@orsmsx502.amr.corp.intel.com> <1222602418.5157.77.camel@localhost> <1223842467.4934.84.camel@localhost> <1224531850.4755.5.camel@localhost> <1225286967.4692.12.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013095@emailwf1.jnpr.net> <1225374490.4684.21.camel@localhost> <6FB661FFA3244D41A23FFC862AB6A23A@morannon> <1225677420.4692.22.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013B2E@emailwf1.jnpr.net> <1225723879.4692.33.camel@localhost> From: "Ross Callon" To: X-OriginalArrivalTime: 03 Nov 2008 20:05:21.0363 (UTC) FILETIME=[802C3A30:01C93DEF] X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id mA3K6tGg021917 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Weiming Wang , secdir@mit.edu, Avri Doria , "Khosravi, Hormuzd M" , iesg@ietf.org, Patrick Droz , Robert Haas Subject: Re: [secdir] Review of draft-ietf-forces-protocol-16 (now -18) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org In general the problem with copying text is that if you want to update the text, then you need to update both documents (and you need to be careful to keep them aligned). In this particular case, it seems to me that the two documents are very closely linked, so that it would be necessary to keep them aligned in any case. Ross -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] Sent: 03 November 2008 09:51 To: Ross Callon Cc: uri@MIT.EDU; Avri Doria; Khosravi, Hormuzd M; Robert Haas; Weiming Wang; Patrick Droz; secdir@MIT.EDU; iesg@ietf.org Subject: RE: Review of draft-ietf-forces-protocol-16 (now -18) Ross, So the choice is either repeating the last call or copying the content? Since we missed the IESG agenda and we have at least 2 weeks, I dont mind just adding cutnpasting that content (then we can avoid the downref altogether). Thoughts? cheers, jamal On Sun, 2008-02-11 at 21:42 -0500, Ross Callon wrote: > Standards track documents can have normative references to informational > documents. However, this needs to be explicitly called out in the IETF > last call. Thus to do this would requiring repeating the last call (it > also requires listing the downref in a registry, but I can take care of > that when putting the document onto an IESG agenda). > > I didn't get this onto the agenda for this week's telechat (My > apologies, I didn't get to it until Friday night, which is too late). > Thus it will need to go onto a telechat very soon after the Minneapolis > IETF. Thus repeating the IETF last call won't slow it down by much. > > Thanks, Ross _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 4 05:28:21 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126993A69B7; Tue, 4 Nov 2008 05:28:21 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752173A69A4; Tue, 4 Nov 2008 05:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U4TwJl5uC58; Tue, 4 Nov 2008 05:28:19 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 373AE3A692D; Tue, 4 Nov 2008 05:28:19 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 9EABA198774; Tue, 4 Nov 2008 15:28:16 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5876719871F; Tue, 4 Nov 2008 15:28:16 +0200 (EET) Message-ID: <49104E4D.7050400@piuha.net> Date: Tue, 04 Nov 2008 15:29:49 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Yaron Sheffer References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CD002@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CD002@il-ex01.ad.checkpoint.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "hesham@elevatemobile.com" , "tsirtsis@googlemail.com" , "secdir@ietf.org" , "pete.mccann@motorola.com" , "iesg@ietf.org" , "vpark@qualcomm.com" , Henrik Levkowetz Subject: Re: [secdir] Secdir review of draft-ietf-mip4-dsmipv4-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Yaron, Thanks for your review. I agree with the security comments. I placed the = following RFC Editor note. Everyone happy? The authors should of course = take these notes into a new version, if it is needed for other reasons. > Please add change in Section 4.3: mechanisma -> mechanisms > > Please change in Section 6: > OLD: > Similar to the procedures specified for Mobile IPv4 [RFC3344] number > spaces, future allocations from this number space require expert > review [RFC5226]. > NEW: > Similar to the procedures specified for Mobile IPv4 [RFC3344] number > spaces, future allocations from the two new number spaces require > expert review [RFC5226]. > > Please add a paragraph to the end of Section 5: > > Interactions with Mobile IPv4 and IPsec have been covered elsewhere, > for instance in [RFC5265] and [RFC5266]. > > Please add two informative references for RFC5265 and RC5266. Jari Yaron Sheffer wrote: > > I have reviewed this document as part of the security directorate's = > ongoing effort to review all IETF documents being processed by the = > IESG. These comments were written primarily for the benefit of the = > security area directors. Document editors and WG chairs should treat = > these comments just like any other last call comments. > > I found this document very well written. I did not find additional = > security issues beyond those documented in the Security = > Considerations, other than the establishment of yet another tunneling = > method. Such methods are often abused in order to bypass security = > middleboxes. However it does make sense to discuss interactions with = > the existing documents on MIP4 and MIP6 security, see below. > > Security comments: > > - There are two recent RFCs on the interaction between Mobile IP and = > IPsec, RFC 5265 and 5266. I would expect the current document to refer = > to the interaction between IPsec and DSMIP. IPsec for this traffic = > will be affected by two factors: (1) protecting MIP4 traffic does not = > protect *all* traffic, in the case of tunneling to the CoA, and (2) as = > always with nested tunnels, access control policy will not be enforced = > correctly, because only the IP-in-IP header will be used to authorize = > the traffic. > > - This document establishes TWO new ways to tunnel IPv6 traffic, one = > inside of MIP4 tunneling and another =93in parallel=94 to MIP4 traffic. = > Security devices will have to learn how to detect and secure this = > traffic. I would expect an informative reference to = > draft-ietf-v6ops-tunnel-security-concerns. > > Other comments: > > - IMHO, the document would be easier to read through if Sec. 3 = > (formats) were moved *after* Sec. 4 (processing rules). > > - In the IANA considerations, it is unclear if the last paragraph = > (expert review) refers to the preceding paragraph, or to both of the = > new number spaces. > > - 4.3: spelling: mechanisma -> mechanisms > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 4 05:30:57 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305853A684C; Tue, 4 Nov 2008 05:30:57 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B173A684C for ; Tue, 4 Nov 2008 05:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.114 X-Spam-Level: X-Spam-Status: No, score=-4.114 tagged_above=-999 required=5 tests=[AWL=2.486, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbFoQG0yxeSP for ; Tue, 4 Nov 2008 05:30:55 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 50BD13A6358 for ; Tue, 4 Nov 2008 05:30:55 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA4DUWPO015902 for ; Tue, 4 Nov 2008 08:30:34 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA4DUPXq015859 for ; Tue, 4 Nov 2008 08:30:25 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id mA4DUI37017300 for ; Tue, 4 Nov 2008 08:30:18 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id C42A510F3011 for ; Tue, 4 Nov 2008 08:29:57 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E2515CC96F; Tue, 4 Nov 2008 08:29:47 -0500 (EST) From: Sam Hartman To: Brian E Carpenter References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> Date: Tue, 04 Nov 2008 08:29:47 -0500 In-Reply-To: <48FF8AEC.9060708@gmail.com> (Brian E. Carpenter's message of "Thu, 23 Oct 2008 09:19:56 +1300") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Christian Huitema , Nathan Ward , Dave Thaler , Tim Polk , "secdir@mit.edu" , Suresh Krishnan , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >>>>> "Brian" == Brian E Carpenter writes: >> Operating a Teredo server on site does not help unfortunately. >> >> It helps an administrator filter outbound packets when sent to >> an IPv6 address outside 2001::/32. It does not help an >> administrator filter inbound packets, or packets to/from other >> Teredo hosts. Brian> As far as I can see, there's a general problem in Brian> attempting to detect and block Teredo packets (I mean Brian> UDP/IPv4 packets in Teredo format). But it seems to me that Brian> by running an internal Teredo server, a site is much better Brian> placed to track and trace Teredo users. This is important Brian> as Teredo users really need to be running an IPv6-savvy Brian> host firewall. Only if you can convince the users to use that teredo server rather than say the teredo server that is configured by default in their OS. Unfortunately, by the time you've already reconfigured the computer you are probably in a position to either disable Teredo if you don't like it or install a reasonable firewall. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 4 05:37:37 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F333A69A4; Tue, 4 Nov 2008 05:37:37 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C3A3A6358; Tue, 4 Nov 2008 05:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcn+CM8xiiiQ; Tue, 4 Nov 2008 05:37:31 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id EF8A43A69A4; Tue, 4 Nov 2008 05:37:30 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KxM5t-0006Sy-Gq; Wed, 05 Nov 2008 00:37:17 +1100 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Wed, 05 Nov 2008 00:37:09 +1100 From: Hesham Soliman To: Jari Arkko , Yaron Sheffer Message-ID: Thread-Topic: Secdir review of draft-ietf-mip4-dsmipv4-07 Thread-Index: Ack+gm9BH3bPWZTnWUmbhbpB5ep/Pg== In-Reply-To: <49104E4D.7050400@piuha.net> Mime-version: 1.0 Cc: "secdir@ietf.org" , "tsirtsis@googlemail.com" , "pete.mccann@motorola.com" , "iesg@ietf.org" , "vpark@qualcomm.com" , Henrik Levkowetz Subject: Re: [secdir] Secdir review of draft-ietf-mip4-dsmipv4-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Looks good to me. Thanks Jari and Yaron for the reivew. Hesham On 5/11/08 12:29 AM, "Jari Arkko" wrote: > Yaron, > = > Thanks for your review. I agree with the security comments. I placed the > following RFC Editor note. Everyone happy? The authors should of course > take these notes into a new version, if it is needed for other reasons. > = >> Please add change in Section 4.3: mechanisma -> mechanisms >> = >> Please change in Section 6: >> OLD: >> Similar to the procedures specified for Mobile IPv4 [RFC3344] number >> spaces, future allocations from this number space require expert >> review [RFC5226]. >> NEW: >> Similar to the procedures specified for Mobile IPv4 [RFC3344] number >> spaces, future allocations from the two new number spaces require >> expert review [RFC5226]. >> = >> Please add a paragraph to the end of Section 5: >> = >> Interactions with Mobile IPv4 and IPsec have been covered elsewhere, >> for instance in [RFC5265] and [RFC5266]. >> = >> Please add two informative references for RFC5265 and RC5266. > = > Jari > = > Yaron Sheffer wrote: >> = >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> = >> I found this document very well written. I did not find additional >> security issues beyond those documented in the Security >> Considerations, other than the establishment of yet another tunneling >> method. Such methods are often abused in order to bypass security >> middleboxes. However it does make sense to discuss interactions with >> the existing documents on MIP4 and MIP6 security, see below. >> = >> Security comments: >> = > = >> - There are two recent RFCs on the interaction between Mobile IP and >> IPsec, RFC 5265 and 5266. I would expect the current document to refer >> to the interaction between IPsec and DSMIP. IPsec for this traffic >> will be affected by two factors: (1) protecting MIP4 traffic does not >> protect *all* traffic, in the case of tunneling to the CoA, and (2) as >> always with nested tunnels, access control policy will not be enforced >> correctly, because only the IP-in-IP header will be used to authorize >> the traffic. >> = >> - This document establishes TWO new ways to tunnel IPv6 traffic, one >> inside of MIP4 tunneling and another =B3in parallel=B2 to MIP4 traffic. >> Security devices will have to learn how to detect and secure this >> traffic. I would expect an informative reference to >> draft-ietf-v6ops-tunnel-security-concerns. >> = >> Other comments: >> = >> - IMHO, the document would be easier to read through if Sec. 3 >> (formats) were moved *after* Sec. 4 (processing rules). >> = >> - In the IANA considerations, it is unclear if the last paragraph >> (expert review) refers to the preceding paragraph, or to both of the >> new number spaces. >> = >> - 4.3: spelling: mechanisma -> mechanisms >> = > = _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 4 07:00:28 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182603A69C3; Tue, 4 Nov 2008 07:00:28 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133683A68AC; Tue, 4 Nov 2008 07:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAKQMuk1pXGb; Tue, 4 Nov 2008 07:00:26 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 704553A69C3; Tue, 4 Nov 2008 07:00:25 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 35AC9294005; Tue, 4 Nov 2008 17:00:17 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 06F17294003; Tue, 4 Nov 2008 17:00:16 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mA4F0EQC022248; Tue, 4 Nov 2008 17:00:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 4 Nov 2008 17:00:14 +0200 From: Yaron Sheffer To: Jari Arkko Date: Tue, 4 Nov 2008 17:00:12 +0200 Thread-Topic: Secdir review of draft-ietf-mip4-dsmipv4-07 Thread-Index: Ack+gTn5Gbwugl+/Q4yBg+Y7jvXT6gADCEpw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A78114B3@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CD002@il-ex01.ad.checkpoint.com> <49104E4D.7050400@piuha.net> In-Reply-To: <49104E4D.7050400@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "hesham@elevatemobile.com" , "tsirtsis@googlemail.com" , "secdir@ietf.org" , "pete.mccann@motorola.com" , "iesg@ietf.org" , "vpark@qualcomm.com" , Henrik Levkowetz Subject: Re: [secdir] Secdir review of draft-ietf-mip4-dsmipv4-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1780098807==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============1780098807== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_013E_01C93E9E.CD04F9A0" ------=_NextPart_000_013E_01C93E9E.CD04F9A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jari, I'm not sure I'm happy... As far as I understand this protocol, it includes a facility (tunneling to CoA) of using MIP4 signaling (presumably protected by IPsec/MOBIKE) to establish a completely separate, out of band and unprotected, IPv6 flow. This is a completely new animal, and that seems to make the proposed resolution (just add a reference to RFC 5265 and 5266) insufficient. In fact, these two RFCs may need to be extended to cover this new option. Is there anything major that I'm missing? Thanks, Yaron -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Tuesday, November 04, 2008 15:30 To: Yaron Sheffer Cc: iesg@ietf.org; secdir@ietf.org; tsirtsis@googlemail.com; vpark@qualcomm.com; hesham@elevatemobile.com; Henrik Levkowetz; pete.mccann@motorola.com Subject: Re: Secdir review of draft-ietf-mip4-dsmipv4-07 Yaron, Thanks for your review. I agree with the security comments. I placed the following RFC Editor note. Everyone happy? The authors should of course take these notes into a new version, if it is needed for other reasons. > Please add change in Section 4.3: mechanisma -> mechanisms > > Please change in Section 6: > OLD: > Similar to the procedures specified for Mobile IPv4 [RFC3344] number > spaces, future allocations from this number space require expert > review [RFC5226]. > NEW: > Similar to the procedures specified for Mobile IPv4 [RFC3344] number > spaces, future allocations from the two new number spaces require > expert review [RFC5226]. > > Please add a paragraph to the end of Section 5: > > Interactions with Mobile IPv4 and IPsec have been covered elsewhere, > for instance in [RFC5265] and [RFC5266]. > > Please add two informative references for RFC5265 and RC5266. Jari Yaron Sheffer wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I found this document very well written. I did not find additional > security issues beyond those documented in the Security > Considerations, other than the establishment of yet another tunneling > method. Such methods are often abused in order to bypass security > middleboxes. However it does make sense to discuss interactions with > the existing documents on MIP4 and MIP6 security, see below. > > Security comments: > > - There are two recent RFCs on the interaction between Mobile IP and > IPsec, RFC 5265 and 5266. I would expect the current document to refer > to the interaction between IPsec and DSMIP. IPsec for this traffic > will be affected by two factors: (1) protecting MIP4 traffic does not > protect *all* traffic, in the case of tunneling to the CoA, and (2) as > always with nested tunnels, access control policy will not be enforced > correctly, because only the IP-in-IP header will be used to authorize > the traffic. > > - This document establishes TWO new ways to tunnel IPv6 traffic, one > inside of MIP4 tunneling and another "in parallel" to MIP4 traffic. > Security devices will have to learn how to detect and secure this > traffic. I would expect an informative reference to > draft-ietf-v6ops-tunnel-security-concerns. > > Other comments: > > - IMHO, the document would be easier to read through if Sec. 3 > (formats) were moved *after* Sec. 4 (processing rules). > > - In the IANA considerations, it is unclear if the last paragraph > (expert review) refers to the preceding paragraph, or to both of the > new number spaces. > > - 4.3: spelling: mechanisma -> mechanisms > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_013E_01C93E9E.CD04F9A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTEwNDE1MDAxMlowIwYJKoZIhvcNAQkEMRYEFAKploXruueg 8SKANGV34o4S5rFcMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA A0asjHj9Mg/fVUGYsKrmXyEQWrmNyMhv8F/LuRS0oXlOfQdxol/W9FVdF6Z0dPa9rpbsuN4/LS7A XkvV+J86JkSvDgZcrkStJGo1NEWt92xsDMVPzg0bVaD2j+UpGglwxn4whhMqsAzOPk0FP3U716ZV NjAt2VP5CCAFsoil5LZXpP1GXTlf20NDxu6p6fyTzz1hwfKqAzOWNwkWiWOmdgWIY/WMuOlyLIlk dXSJDSdDOiLB2ZJ2gzP9Muh5mpb+cyuGa6s4Xm97//KGvY6NfXSh6d3tFiDKtXvRH3mfP5Rjh8XJ xEru+hr/FiSgMa8tczAiNCCx+u1Mnxex+exE8QAAAAAAAA== ------=_NextPart_000_013E_01C93E9E.CD04F9A0-- --===============1780098807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============1780098807==-- From secdir-bounces@ietf.org Tue Nov 4 08:41:12 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F27B3A6A60; Tue, 4 Nov 2008 08:41:12 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A885D3A692E for ; Tue, 4 Nov 2008 08:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJfaL1q1yML6 for ; Tue, 4 Nov 2008 08:41:06 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9BB413A6A7D for ; Tue, 4 Nov 2008 08:41:05 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3A5A7294005; Tue, 4 Nov 2008 18:40:43 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6752B29C001; Tue, 4 Nov 2008 18:40:41 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mA4GeeQC028345; Tue, 4 Nov 2008 18:40:40 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 4 Nov 2008 18:40:40 +0200 From: Yaron Sheffer To: George Tsirtsis Date: Tue, 4 Nov 2008 18:40:45 +0200 Thread-Topic: Secdir review of draft-ietf-mip4-dsmipv4-07 Thread-Index: Ack+mSHryaG/tY6TTWCWo/7jgA9MsAAAhs/g Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A78114DE@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CD002@il-ex01.ad.checkpoint.com> <49104E4D.7050400@piuha.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A78114B3@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "hesham@elevatemobile.com" , "Pasi Eronen \(Pasi.Eronen@nokia.com\)" , "secdir@ietf.org" , "pete.mccann@motorola.com" , Jari Arkko , "vpark@qualcomm.com" , Henrik Levkowetz Subject: Re: [secdir] Secdir review of draft-ietf-mip4-dsmipv4-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1620092486==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============1620092486== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0160_01C93EAC.D8CF4890" ------=_NextPart_000_0160_01C93EAC.D8CF4890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi George, Thanks for the clarification. Yes, this does make sense. The whole thing makes access control within the IPsec tunnel (the SPD) sort of useless in these scenarios. But this milk was already spilled in RFC 5265. Best, Yaron -----Original Message----- From: George Tsirtsis [mailto:tsirtsis@googlemail.com] Sent: Tuesday, November 04, 2008 18:19 To: Yaron Sheffer Cc: Jari Arkko; iesg@ietf.org; secdir@ietf.org; vpark@qualcomm.com; hesham@elevatemobile.com; Henrik Levkowetz; pete.mccann@motorola.com Subject: Re: Secdir review of draft-ietf-mip4-dsmipv4-07 Hi Yaron, MIPv4 sets up a tunnel between the HA and the MN's CoA. Over this tunnel the HA forwards IPv4 traffic between the corresponding nodes (CNs) IP Address and the MN's home address (HoA). DS-MIPv4 extends MIPv4 so that in addition to IPv4 traffic the HA can forward IPv6 traffic over the same HA-CoA tunnel. So, when the HA forwards packets to the MN it uses one of the following: Packets with destination address the MN's IPv4 HoA are forwarded over the HA-CoA tunnel Packets with destination address the MN's IPv6 (home registered prefixes) are also forwarded over the HA-CoA tunnel. The specification also allows for a double encapsulation. This results to: Packets with destination address the MN's IPv6 (home registered prefixes) are forwarded to a tunnel between the HA's IPv4 address and MN's IPv4 HoA, which are then forwarded over the HA-CoA tunnel. In that sense DSMIPv4 always tunnels packets to the MN's CoA (as RFC3344 MIPv4) either directly or via the use of double encapsulation (i.e., it never creates a "parallel tunnel". So, the IPSEC interactions described in RFC5265/5266 should apply here too. The only thing we should possibly add is that security devices should look for this potential double encapsulation over which IPv6 traffic is some times sent. Would that make sense? George On Tue, Nov 4, 2008 at 3:00 PM, Yaron Sheffer wrote: > Hi Jari, > > I'm not sure I'm happy... As far as I understand this protocol, it includes > a facility (tunneling to CoA) of using MIP4 signaling (presumably protected > by IPsec/MOBIKE) to establish a completely separate, out of band and > unprotected, IPv6 flow. This is a completely new animal, and that seems to > make the proposed resolution (just add a reference to RFC 5265 and 5266) > insufficient. In fact, these two RFCs may need to be extended to cover this > new option. > > Is there anything major that I'm missing? > > Thanks, > Yaron > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, November 04, 2008 15:30 > To: Yaron Sheffer > Cc: iesg@ietf.org; secdir@ietf.org; tsirtsis@googlemail.com; > vpark@qualcomm.com; hesham@elevatemobile.com; Henrik Levkowetz; > pete.mccann@motorola.com > Subject: Re: Secdir review of draft-ietf-mip4-dsmipv4-07 > > Yaron, > > Thanks for your review. I agree with the security comments. I placed the > following RFC Editor note. Everyone happy? The authors should of course > take these notes into a new version, if it is needed for other reasons. > >> Please add change in Section 4.3: mechanisma -> mechanisms >> >> Please change in Section 6: >> OLD: >> Similar to the procedures specified for Mobile IPv4 [RFC3344] number >> spaces, future allocations from this number space require expert >> review [RFC5226]. >> NEW: >> Similar to the procedures specified for Mobile IPv4 [RFC3344] number >> spaces, future allocations from the two new number spaces require >> expert review [RFC5226]. >> >> Please add a paragraph to the end of Section 5: >> >> Interactions with Mobile IPv4 and IPsec have been covered elsewhere, >> for instance in [RFC5265] and [RFC5266]. >> >> Please add two informative references for RFC5265 and RC5266. > > Jari > > Yaron Sheffer wrote: >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> I found this document very well written. I did not find additional >> security issues beyond those documented in the Security >> Considerations, other than the establishment of yet another tunneling >> method. Such methods are often abused in order to bypass security >> middleboxes. However it does make sense to discuss interactions with >> the existing documents on MIP4 and MIP6 security, see below. >> >> Security comments: >> > >> - There are two recent RFCs on the interaction between Mobile IP and >> IPsec, RFC 5265 and 5266. I would expect the current document to refer >> to the interaction between IPsec and DSMIP. IPsec for this traffic >> will be affected by two factors: (1) protecting MIP4 traffic does not >> protect *all* traffic, in the case of tunneling to the CoA, and (2) as >> always with nested tunnels, access control policy will not be enforced >> correctly, because only the IP-in-IP header will be used to authorize >> the traffic. >> >> - This document establishes TWO new ways to tunnel IPv6 traffic, one >> inside of MIP4 tunneling and another "in parallel" to MIP4 traffic. >> Security devices will have to learn how to detect and secure this >> traffic. I would expect an informative reference to >> draft-ietf-v6ops-tunnel-security-concerns. >> >> Other comments: >> >> - IMHO, the document would be easier to read through if Sec. 3 >> (formats) were moved *after* Sec. 4 (processing rules). >> >> - In the IANA considerations, it is unclear if the last paragraph >> (expert review) refers to the preceding paragraph, or to both of the >> new number spaces. >> >> - 4.3: spelling: mechanisma -> mechanisms >> > > > Scanned by Check Point Total Security Gateway. > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0160_01C93EAC.D8CF4890 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTEwNDE2NDA0NFowIwYJKoZIhvcNAQkEMRYEFCIcwfWDZHLK nJY0L3AERQs/UWWvMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA pVBykLbiFokvdhBI/JOcy8ATEzJgjMJicDZJePgJtOeHDis4z6jIcGsD/GGxH5Rbgyn1A7EQHzGG cRKOKm703wbopDJyPVuwKyHiobddMxKoJJ0fOH4YCmljd5PJ6wFa4QIxx40M5Km/tjwWnMDsUDww Kjxu8xKjsxyIj8z1KCRR9LlHT8i0getwLdh2XKvLR7wBL8bKtmJSSEcdM+lIjMuQhLcqmE7S3hkp ToPHUEpnp2ccH8EpktoVSDQjSZe9LfKM36XM7SAH8+hVw5n5wUOkCmir0bjm1NeoNONVv5EPUqp9 gNk2aXlRSQVAuqfa/W8ZBwpclrUCa+EJLb8GkQAAAAAAAA== ------=_NextPart_000_0160_01C93EAC.D8CF4890-- --===============1620092486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============1620092486==-- From secdir-bounces@ietf.org Tue Nov 4 10:10:24 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384EF28C1BF; Tue, 4 Nov 2008 10:10:24 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDC13A67AA; Tue, 4 Nov 2008 06:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz5SPK+kc-BD; Tue, 4 Nov 2008 06:30:21 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by core3.amsl.com (Postfix) with ESMTP id 637F33A69AA; Tue, 4 Nov 2008 06:30:20 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so157831nfh.39 for ; Tue, 04 Nov 2008 06:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=LIpVMVzBEBEG6wP0Ecr5Mb0JpuUkBgOk6DVED5Hc62c=; b=jdtsFYUyVroaPeGn3kjDnP19qNqVQQBkQNNsrc/H3jWHTAfi216ov1w1xEGs+Hkvqt qqskb3lpAVIbU3I6Coiu7CPkDm3QlfUj5AnxuZVk2cdI7Wxz8cj6LiqkhgWHuA3c47VN nQ6MzyK8aBoP1Rb/LYWDSWk2/1rh5reSmPZoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SwzYp6Dxn4emCgppydAzMqOfrN9rbakU/da4mx4oF2ZgeS7qk1FK6JBfPTikN7bYXV FNMDl0JGnc7nEnedpJZ3mrcCyqbkTvF7arfJ7CWu/+0OgS8ynxxt94d7emAWy5h94Ks2 i1u6wgMvDosjrdOi6xiM390fMTdt1qBnzHZQk= Received: by 10.103.46.12 with SMTP id y12mr708036muj.130.1225809016677; Tue, 04 Nov 2008 06:30:16 -0800 (PST) Received: by 10.103.169.13 with HTTP; Tue, 4 Nov 2008 06:30:16 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2008 14:30:16 +0000 From: "George Tsirtsis" To: "Hesham Soliman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <49104E4D.7050400@piuha.net> X-Mailman-Approved-At: Tue, 04 Nov 2008 10:10:17 -0800 Cc: "secdir@ietf.org" , "pete.mccann@motorola.com" , Jari Arkko , "iesg@ietf.org" , "vpark@qualcomm.com" , Henrik Levkowetz Subject: Re: [secdir] Secdir review of draft-ietf-mip4-dsmipv4-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org WWVzLCB0aGVzZSBsb29rIG9rIHRvIG1lLiBZYXJvbiB0aGFua3MgZm9yIHlvdXIgcmV2aWV3LgpH ZW9yZ2UKCk9uIFR1ZSwgTm92IDQsIDIwMDggYXQgMTozNyBQTSwgSGVzaGFtIFNvbGltYW4gPGhl c2hhbUBlbGV2YXRlbW9iaWxlLmNvbT4gd3JvdGU6Cj4gTG9va3MgZ29vZCB0byBtZS4gVGhhbmtz IEphcmkgYW5kIFlhcm9uIGZvciB0aGUgcmVpdmV3Lgo+Cj4gSGVzaGFtCj4KPgo+IE9uIDUvMTEv MDggMTI6MjkgQU0sICJKYXJpIEFya2tvIiA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+IHdyb3RlOgo+ Cj4+IFlhcm9uLAo+Pgo+PiBUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiBJIGFncmVlIHdpdGggdGhl IHNlY3VyaXR5IGNvbW1lbnRzLiBJIHBsYWNlZCB0aGUKPj4gZm9sbG93aW5nIFJGQyBFZGl0b3Ig bm90ZS4gRXZlcnlvbmUgaGFwcHk/IFRoZSBhdXRob3JzIHNob3VsZCBvZiBjb3Vyc2UKPj4gdGFr ZSB0aGVzZSBub3RlcyBpbnRvIGEgbmV3IHZlcnNpb24sIGlmIGl0IGlzIG5lZWRlZCBmb3Igb3Ro ZXIgcmVhc29ucy4KPj4KPj4+IFBsZWFzZSBhZGQgY2hhbmdlIGluIFNlY3Rpb24gNC4zOiBtZWNo YW5pc21hIC0+IG1lY2hhbmlzbXMKPj4+Cj4+PiBQbGVhc2UgY2hhbmdlIGluIFNlY3Rpb24gNjoK Pj4+IE9MRDoKPj4+IFNpbWlsYXIgdG8gdGhlIHByb2NlZHVyZXMgc3BlY2lmaWVkIGZvciBNb2Jp bGUgSVB2NCBbUkZDMzM0NF0gbnVtYmVyCj4+PiBzcGFjZXMsIGZ1dHVyZSBhbGxvY2F0aW9ucyBm cm9tIHRoaXMgbnVtYmVyIHNwYWNlIHJlcXVpcmUgZXhwZXJ0Cj4+PiByZXZpZXcgW1JGQzUyMjZd Lgo+Pj4gTkVXOgo+Pj4gU2ltaWxhciB0byB0aGUgcHJvY2VkdXJlcyBzcGVjaWZpZWQgZm9yIE1v YmlsZSBJUHY0IFtSRkMzMzQ0XSBudW1iZXIKPj4+IHNwYWNlcywgZnV0dXJlIGFsbG9jYXRpb25z IGZyb20gdGhlIHR3byBuZXcgbnVtYmVyIHNwYWNlcyByZXF1aXJlCj4+PiBleHBlcnQgcmV2aWV3 IFtSRkM1MjI2XS4KPj4+Cj4+PiBQbGVhc2UgYWRkIGEgcGFyYWdyYXBoIHRvIHRoZSBlbmQgb2Yg U2VjdGlvbiA1Ogo+Pj4KPj4+IEludGVyYWN0aW9ucyB3aXRoIE1vYmlsZSBJUHY0IGFuZCBJUHNl YyBoYXZlIGJlZW4gY292ZXJlZCBlbHNld2hlcmUsCj4+PiBmb3IgaW5zdGFuY2UgaW4gW1JGQzUy NjVdIGFuZCBbUkZDNTI2Nl0uCj4+Pgo+Pj4gUGxlYXNlIGFkZCB0d28gaW5mb3JtYXRpdmUgcmVm ZXJlbmNlcyBmb3IgUkZDNTI2NSBhbmQgUkM1MjY2Lgo+Pgo+PiBKYXJpCj4+Cj4+IFlhcm9uIFNo ZWZmZXIgd3JvdGU6Cj4+Pgo+Pj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncwo+Pj4gb25nb2luZyBlZmZvcnQgdG8gcmV2 aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlCj4+PiBJRVNHLiBU aGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0 aGUKPj4+IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBj aGFpcnMgc2hvdWxkIHRyZWF0Cj4+PiB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVy IGxhc3QgY2FsbCBjb21tZW50cy4KPj4+Cj4+PiBJIGZvdW5kIHRoaXMgZG9jdW1lbnQgdmVyeSB3 ZWxsIHdyaXR0ZW4uIEkgZGlkIG5vdCBmaW5kIGFkZGl0aW9uYWwKPj4+IHNlY3VyaXR5IGlzc3Vl cyBiZXlvbmQgdGhvc2UgZG9jdW1lbnRlZCBpbiB0aGUgU2VjdXJpdHkKPj4+IENvbnNpZGVyYXRp b25zLCBvdGhlciB0aGFuIHRoZSBlc3RhYmxpc2htZW50IG9mIHlldCBhbm90aGVyIHR1bm5lbGlu Zwo+Pj4gbWV0aG9kLiBTdWNoIG1ldGhvZHMgYXJlIG9mdGVuIGFidXNlZCBpbiBvcmRlciB0byBi eXBhc3Mgc2VjdXJpdHkKPj4+IG1pZGRsZWJveGVzLiBIb3dldmVyIGl0IGRvZXMgbWFrZSBzZW5z ZSB0byBkaXNjdXNzIGludGVyYWN0aW9ucyB3aXRoCj4+PiB0aGUgZXhpc3RpbmcgZG9jdW1lbnRz IG9uIE1JUDQgYW5kIE1JUDYgc2VjdXJpdHksIHNlZSBiZWxvdy4KPj4+Cj4+PiBTZWN1cml0eSBj b21tZW50czoKPj4+Cj4+Cj4+PiAtIFRoZXJlIGFyZSB0d28gcmVjZW50IFJGQ3Mgb24gdGhlIGlu dGVyYWN0aW9uIGJldHdlZW4gTW9iaWxlIElQIGFuZAo+Pj4gSVBzZWMsIFJGQyA1MjY1IGFuZCA1 MjY2LiBJIHdvdWxkIGV4cGVjdCB0aGUgY3VycmVudCBkb2N1bWVudCB0byByZWZlcgo+Pj4gdG8g dGhlIGludGVyYWN0aW9uIGJldHdlZW4gSVBzZWMgYW5kIERTTUlQLiBJUHNlYyBmb3IgdGhpcyB0 cmFmZmljCj4+PiB3aWxsIGJlIGFmZmVjdGVkIGJ5IHR3byBmYWN0b3JzOiAoMSkgcHJvdGVjdGlu ZyBNSVA0IHRyYWZmaWMgZG9lcyBub3QKPj4+IHByb3RlY3QgKmFsbCogdHJhZmZpYywgaW4gdGhl IGNhc2Ugb2YgdHVubmVsaW5nIHRvIHRoZSBDb0EsIGFuZCAoMikgYXMKPj4+IGFsd2F5cyB3aXRo IG5lc3RlZCB0dW5uZWxzLCBhY2Nlc3MgY29udHJvbCBwb2xpY3kgd2lsbCBub3QgYmUgZW5mb3Jj ZWQKPj4+IGNvcnJlY3RseSwgYmVjYXVzZSBvbmx5IHRoZSBJUC1pbi1JUCBoZWFkZXIgd2lsbCBi ZSB1c2VkIHRvIGF1dGhvcml6ZQo+Pj4gdGhlIHRyYWZmaWMuCj4+Pgo+Pj4gLSBUaGlzIGRvY3Vt ZW50IGVzdGFibGlzaGVzIFRXTyBuZXcgd2F5cyB0byB0dW5uZWwgSVB2NiB0cmFmZmljLCBvbmUK Pj4+IGluc2lkZSBvZiBNSVA0IHR1bm5lbGluZyBhbmQgYW5vdGhlciDCs2luIHBhcmFsbGVswrIg dG8gTUlQNCB0cmFmZmljLgo+Pj4gU2VjdXJpdHkgZGV2aWNlcyB3aWxsIGhhdmUgdG8gbGVhcm4g aG93IHRvIGRldGVjdCBhbmQgc2VjdXJlIHRoaXMKPj4+IHRyYWZmaWMuIEkgd291bGQgZXhwZWN0 IGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0bwo+Pj4gZHJhZnQtaWV0Zi12Nm9wcy10dW5uZWwt c2VjdXJpdHktY29uY2VybnMuCj4+Pgo+Pj4gT3RoZXIgY29tbWVudHM6Cj4+Pgo+Pj4gLSBJTUhP LCB0aGUgZG9jdW1lbnQgd291bGQgYmUgZWFzaWVyIHRvIHJlYWQgdGhyb3VnaCBpZiBTZWMuIDMK Pj4+IChmb3JtYXRzKSB3ZXJlIG1vdmVkICphZnRlciogU2VjLiA0IChwcm9jZXNzaW5nIHJ1bGVz KS4KPj4+Cj4+PiAtIEluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zLCBpdCBpcyB1bmNsZWFyIGlm IHRoZSBsYXN0IHBhcmFncmFwaAo+Pj4gKGV4cGVydCByZXZpZXcpIHJlZmVycyB0byB0aGUgcHJl Y2VkaW5nIHBhcmFncmFwaCwgb3IgdG8gYm90aCBvZiB0aGUKPj4+IG5ldyBudW1iZXIgc3BhY2Vz Lgo+Pj4KPj4+IC0gNC4zOiBzcGVsbGluZzogbWVjaGFuaXNtYSAtPiBtZWNoYW5pc21zCj4+Pgo+ Pgo+Cj4KPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpz ZWNkaXIgbWFpbGluZyBsaXN0CnNlY2RpckBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NlY2Rpcgo= From secdir-bounces@ietf.org Tue Nov 4 10:10:26 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5EB28C1E3; Tue, 4 Nov 2008 10:10:26 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D987A3A6358; Tue, 4 Nov 2008 08:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7gSriCePUdY; Tue, 4 Nov 2008 08:19:25 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 4756A3A6928; Tue, 4 Nov 2008 08:19:25 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1142579eyd.31 for ; Tue, 04 Nov 2008 08:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HWMre4XY345gnWPQlbUrHKP46bk5m51+nIBnH0owFwA=; b=p/0geom9axpy/Lqszsmb6YqrO3jb+ZgMjIpcxNxSnIeOwXAdqeaqQ7wPP8saff0XgP wlh5cYzOdCWytrWJdRWNn186Jy14CLOYe7++vE17kHGSfqbJxf9BB3MdH/Ilm47zXLVA bGTLKdAEMILa6KxdL22Su58H8RYMDXJG9/DDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HFWpT8Pfo07xdl77QR1tkh4j39Ci5qY8g2w/GZlPlqp8ztNTQJJYdq7vGt5yUnff2u GkxWyuolSshCzamr/N16vzUQKkV63AUjqDjm4SwynqUrx2iPjhD6LBNfVUu3gnlkHdsc L2ei8m9H/ZSOLV1G7QTlPsFjplB3pD3x3sG28= Received: by 10.103.247.14 with SMTP id z14mr797012mur.2.1225815561619; Tue, 04 Nov 2008 08:19:21 -0800 (PST) Received: by 10.103.169.13 with HTTP; Tue, 4 Nov 2008 08:19:21 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2008 16:19:21 +0000 From: "George Tsirtsis" To: "Yaron Sheffer" In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A78114B3@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CD002@il-ex01.ad.checkpoint.com> <49104E4D.7050400@piuha.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A78114B3@il-ex01.ad.checkpoint.com> X-Mailman-Approved-At: Tue, 04 Nov 2008 10:10:20 -0800 Cc: "hesham@elevatemobile.com" , "secdir@ietf.org" , "pete.mccann@motorola.com" , Jari Arkko , "iesg@ietf.org" , "vpark@qualcomm.com" , Henrik Levkowetz Subject: Re: [secdir] Secdir review of draft-ietf-mip4-dsmipv4-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Yaron, MIPv4 sets up a tunnel between the HA and the MN's CoA. Over this tunnel the HA forwards IPv4 traffic between the corresponding nodes (CNs) IP Address and the MN's home address (HoA). DS-MIPv4 extends MIPv4 so that in addition to IPv4 traffic the HA can forward IPv6 traffic over the same HA-CoA tunnel. So, when the HA forwards packets to the MN it uses one of the following: Packets with destination address the MN's IPv4 HoA are forwarded over the HA-CoA tunnel Packets with destination address the MN's IPv6 (home registered prefixes) are also forwarded over the HA-CoA tunnel. The specification also allows for a double encapsulation. This results to: Packets with destination address the MN's IPv6 (home registered prefixes) are forwarded to a tunnel between the HA's IPv4 address and MN's IPv4 HoA, which are then forwarded over the HA-CoA tunnel. In that sense DSMIPv4 always tunnels packets to the MN's CoA (as RFC3344 MIPv4) either directly or via the use of double encapsulation (i.e., it never creates a "parallel tunnel". So, the IPSEC interactions described in RFC5265/5266 should apply here too. The only thing we should possibly add is that security devices should look for this potential double encapsulation over which IPv6 traffic is some times sent. Would that make sense? George On Tue, Nov 4, 2008 at 3:00 PM, Yaron Sheffer wrote: > Hi Jari, > > I'm not sure I'm happy... As far as I understand this protocol, it includes > a facility (tunneling to CoA) of using MIP4 signaling (presumably protected > by IPsec/MOBIKE) to establish a completely separate, out of band and > unprotected, IPv6 flow. This is a completely new animal, and that seems to > make the proposed resolution (just add a reference to RFC 5265 and 5266) > insufficient. In fact, these two RFCs may need to be extended to cover this > new option. > > Is there anything major that I'm missing? > > Thanks, > Yaron > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, November 04, 2008 15:30 > To: Yaron Sheffer > Cc: iesg@ietf.org; secdir@ietf.org; tsirtsis@googlemail.com; > vpark@qualcomm.com; hesham@elevatemobile.com; Henrik Levkowetz; > pete.mccann@motorola.com > Subject: Re: Secdir review of draft-ietf-mip4-dsmipv4-07 > > Yaron, > > Thanks for your review. I agree with the security comments. I placed the > following RFC Editor note. Everyone happy? The authors should of course > take these notes into a new version, if it is needed for other reasons. > >> Please add change in Section 4.3: mechanisma -> mechanisms >> >> Please change in Section 6: >> OLD: >> Similar to the procedures specified for Mobile IPv4 [RFC3344] number >> spaces, future allocations from this number space require expert >> review [RFC5226]. >> NEW: >> Similar to the procedures specified for Mobile IPv4 [RFC3344] number >> spaces, future allocations from the two new number spaces require >> expert review [RFC5226]. >> >> Please add a paragraph to the end of Section 5: >> >> Interactions with Mobile IPv4 and IPsec have been covered elsewhere, >> for instance in [RFC5265] and [RFC5266]. >> >> Please add two informative references for RFC5265 and RC5266. > > Jari > > Yaron Sheffer wrote: >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> I found this document very well written. I did not find additional >> security issues beyond those documented in the Security >> Considerations, other than the establishment of yet another tunneling >> method. Such methods are often abused in order to bypass security >> middleboxes. However it does make sense to discuss interactions with >> the existing documents on MIP4 and MIP6 security, see below. >> >> Security comments: >> > >> - There are two recent RFCs on the interaction between Mobile IP and >> IPsec, RFC 5265 and 5266. I would expect the current document to refer >> to the interaction between IPsec and DSMIP. IPsec for this traffic >> will be affected by two factors: (1) protecting MIP4 traffic does not >> protect *all* traffic, in the case of tunneling to the CoA, and (2) as >> always with nested tunnels, access control policy will not be enforced >> correctly, because only the IP-in-IP header will be used to authorize >> the traffic. >> >> - This document establishes TWO new ways to tunnel IPv6 traffic, one >> inside of MIP4 tunneling and another "in parallel" to MIP4 traffic. >> Security devices will have to learn how to detect and secure this >> traffic. I would expect an informative reference to >> draft-ietf-v6ops-tunnel-security-concerns. >> >> Other comments: >> >> - IMHO, the document would be easier to read through if Sec. 3 >> (formats) were moved *after* Sec. 4 (processing rules). >> >> - In the IANA considerations, it is unclear if the last paragraph >> (expert review) refers to the preceding paragraph, or to both of the >> new number spaces. >> >> - 4.3: spelling: mechanisma -> mechanisms >> > > > Scanned by Check Point Total Security Gateway. > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 4 10:10:26 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9795128C1F5; Tue, 4 Nov 2008 10:10:26 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727833A6A82 for ; Tue, 4 Nov 2008 08:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwsAJwBgJKvH for ; Tue, 4 Nov 2008 08:52:41 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id C688F3A690B for ; Tue, 4 Nov 2008 08:52:40 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so198855nfh.39 for ; Tue, 04 Nov 2008 08:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=UAr6V65YjT3fLn3LJH+s7GDSueTXfvtK2Z8p3OBQpII=; b=e/ODOlVHag8cDXr0aZ0VFzMAL6yMwtnwRG1rKmVDnD3pcREgj7cnPc0RxQH9DrJqrh oopsKC5fQQEtUMyXWWZHtdcjSrfPKRk8fFTFSlQbc3mhg2pG9XdCHOi6NisNfDKlSL5m jDcUQ0tsqHu9cGUvBhIodhV48qRditygcs2wQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=slbftFSrI55M4pLoCRtldxvPUJSFmmgJbO+7ltzP2cPKyJZR+ojbtQ8aBHOza3XsJp cxesv9ic2CY2VPJNecZ158uybvRn/bWu769Q3OurIg3uiINlpEG2QgeXz9ObQ0swW0tP QVLmA98CDcmQuBZ/VsiHZvnIjrHIDukWhNezw= Received: by 10.103.212.2 with SMTP id o2mr786268muq.119.1225817557652; Tue, 04 Nov 2008 08:52:37 -0800 (PST) Received: by 10.103.169.13 with HTTP; Tue, 4 Nov 2008 08:52:37 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2008 16:52:37 +0000 From: "George Tsirtsis" To: "Yaron Sheffer" In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A78114DE@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CD002@il-ex01.ad.checkpoint.com> <49104E4D.7050400@piuha.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A78114B3@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A78114DE@il-ex01.ad.checkpoint.com> X-Mailman-Approved-At: Tue, 04 Nov 2008 10:10:20 -0800 Cc: "hesham@elevatemobile.com" , "Pasi Eronen \(Pasi.Eronen@nokia.com\)" , "secdir@ietf.org" , "pete.mccann@motorola.com" , Jari Arkko , "vpark@qualcomm.com" , Henrik Levkowetz Subject: Re: [secdir] Secdir review of draft-ietf-mip4-dsmipv4-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org OK, good. I will make this clearer in the draft as I incorporate the suggestions from Jari. Thanks again. George On Tue, Nov 4, 2008 at 4:40 PM, Yaron Sheffer wrote: > Hi George, > > Thanks for the clarification. Yes, this does make sense. > > The whole thing makes access control within the IPsec tunnel (the SPD) sort > of useless in these scenarios. But this milk was already spilled in RFC > 5265. > > Best, > Yaron > > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Tuesday, November 04, 2008 18:19 > To: Yaron Sheffer > Cc: Jari Arkko; iesg@ietf.org; secdir@ietf.org; vpark@qualcomm.com; > hesham@elevatemobile.com; Henrik Levkowetz; pete.mccann@motorola.com > Subject: Re: Secdir review of draft-ietf-mip4-dsmipv4-07 > > Hi Yaron, > > MIPv4 sets up a tunnel between the HA and the MN's CoA. Over this > tunnel the HA forwards IPv4 traffic between the corresponding nodes > (CNs) IP Address and the MN's home address (HoA). > > DS-MIPv4 extends MIPv4 so that in addition to IPv4 traffic the HA can > forward IPv6 traffic over the same HA-CoA tunnel. > > So, when the HA forwards packets to the MN it uses one of the following: > Packets with destination address the MN's IPv4 HoA are forwarded over > the HA-CoA tunnel > Packets with destination address the MN's IPv6 (home registered > prefixes) are also forwarded over the HA-CoA tunnel. > > The specification also allows for a double encapsulation. This results to: > Packets with destination address the MN's IPv6 (home registered > prefixes) are forwarded to a tunnel between the HA's IPv4 address and > MN's IPv4 HoA, which are then forwarded over the HA-CoA tunnel. > > In that sense DSMIPv4 always tunnels packets to the MN's CoA (as > RFC3344 MIPv4) either directly or via the use of double encapsulation > (i.e., it never creates a "parallel tunnel". So, the IPSEC > interactions described in RFC5265/5266 should apply here too. > > The only thing we should possibly add is that security devices should > look for this potential double encapsulation over which IPv6 traffic > is some times sent. > > Would that make sense? > > George > > > On Tue, Nov 4, 2008 at 3:00 PM, Yaron Sheffer wrote: >> Hi Jari, >> >> I'm not sure I'm happy... As far as I understand this protocol, it > includes >> a facility (tunneling to CoA) of using MIP4 signaling (presumably > protected >> by IPsec/MOBIKE) to establish a completely separate, out of band and >> unprotected, IPv6 flow. This is a completely new animal, and that seems to >> make the proposed resolution (just add a reference to RFC 5265 and 5266) >> insufficient. In fact, these two RFCs may need to be extended to cover > this >> new option. >> >> Is there anything major that I'm missing? >> >> Thanks, >> Yaron >> >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Tuesday, November 04, 2008 15:30 >> To: Yaron Sheffer >> Cc: iesg@ietf.org; secdir@ietf.org; tsirtsis@googlemail.com; >> vpark@qualcomm.com; hesham@elevatemobile.com; Henrik Levkowetz; >> pete.mccann@motorola.com >> Subject: Re: Secdir review of draft-ietf-mip4-dsmipv4-07 >> >> Yaron, >> >> Thanks for your review. I agree with the security comments. I placed the >> following RFC Editor note. Everyone happy? The authors should of course >> take these notes into a new version, if it is needed for other reasons. >> >>> Please add change in Section 4.3: mechanisma -> mechanisms >>> >>> Please change in Section 6: >>> OLD: >>> Similar to the procedures specified for Mobile IPv4 [RFC3344] number >>> spaces, future allocations from this number space require expert >>> review [RFC5226]. >>> NEW: >>> Similar to the procedures specified for Mobile IPv4 [RFC3344] number >>> spaces, future allocations from the two new number spaces require >>> expert review [RFC5226]. >>> >>> Please add a paragraph to the end of Section 5: >>> >>> Interactions with Mobile IPv4 and IPsec have been covered elsewhere, >>> for instance in [RFC5265] and [RFC5266]. >>> >>> Please add two informative references for RFC5265 and RC5266. >> >> Jari >> >> Yaron Sheffer wrote: >>> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >>> >>> I found this document very well written. I did not find additional >>> security issues beyond those documented in the Security >>> Considerations, other than the establishment of yet another tunneling >>> method. Such methods are often abused in order to bypass security >>> middleboxes. However it does make sense to discuss interactions with >>> the existing documents on MIP4 and MIP6 security, see below. >>> >>> Security comments: >>> >> >>> - There are two recent RFCs on the interaction between Mobile IP and >>> IPsec, RFC 5265 and 5266. I would expect the current document to refer >>> to the interaction between IPsec and DSMIP. IPsec for this traffic >>> will be affected by two factors: (1) protecting MIP4 traffic does not >>> protect *all* traffic, in the case of tunneling to the CoA, and (2) as >>> always with nested tunnels, access control policy will not be enforced >>> correctly, because only the IP-in-IP header will be used to authorize >>> the traffic. >>> >>> - This document establishes TWO new ways to tunnel IPv6 traffic, one >>> inside of MIP4 tunneling and another "in parallel" to MIP4 traffic. >>> Security devices will have to learn how to detect and secure this >>> traffic. I would expect an informative reference to >>> draft-ietf-v6ops-tunnel-security-concerns. >>> >>> Other comments: >>> >>> - IMHO, the document would be easier to read through if Sec. 3 >>> (formats) were moved *after* Sec. 4 (processing rules). >>> >>> - In the IANA considerations, it is unclear if the last paragraph >>> (expert review) refers to the preceding paragraph, or to both of the >>> new number spaces. >>> >>> - 4.3: spelling: mechanisma -> mechanisms >>> >> >> >> Scanned by Check Point Total Security Gateway. >> > > Scanned by Check Point Total Security Gateway. > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 4 11:52:07 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D8028C22D; Tue, 4 Nov 2008 11:52:07 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1394928C22D for ; Tue, 4 Nov 2008 11:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rsd3AOzcFzF4 for ; Tue, 4 Nov 2008 11:52:05 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 0B7EF3A6BEC for ; Tue, 4 Nov 2008 11:52:04 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA4JpxHl004199 for ; Tue, 4 Nov 2008 14:51:59 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA4Jpshp004178 for ; Tue, 4 Nov 2008 14:51:54 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mA4JpkYT011055 for ; Tue, 4 Nov 2008 14:51:47 -0500 (EST) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 0A8F611AD206; Tue, 4 Nov 2008 14:51:25 -0500 (EST) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Nov 2008 11:51:45 PST Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 11:50:26 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Nov 2008 14:50:20 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C050B2C53@emailwf1.jnpr.net> In-Reply-To: <1225827227.4811.6.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-forces-protocol-16 (now -18) Thread-Index: Ack+tF+6OPVjw1SsSYC6u9Yuloeq/AAAVilg References: <4C5E6457CD7911469A07260381288C280A171EAF@orsmsx502.amr.corp.intel.com> <1222602418.5157.77.camel@localhost> <1223842467.4934.84.camel@localhost> <1224531850.4755.5.camel@localhost> <1225286967.4692.12.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013095@emailwf1.jnpr.net> <1225374490.4684.21.camel@localhost> <6FB661FFA3244D41A23FFC862AB6A23A@morannon> <1225677420.4692.22.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013B2E@emailwf1.jnpr.net> <1225723879.4692.33.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013E27@emailwf1.jnpr.net> <1225827227.4811.6.camel@localhost> From: "Ross Callon" To: X-OriginalArrivalTime: 04 Nov 2008 19:50:26.0893 (UTC) FILETIME=[9570AFD0:01C93EB6] X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id mA4Jpshp004178 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Weiming Wang , secdir@mit.edu, Avri Doria , "Khosravi, Hormuzd M" , iesg@ietf.org, Patrick Droz , Robert Haas Subject: Re: [secdir] Review of draft-ietf-forces-protocol-16 (now -18) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org A down-ref requires an IETF last call, which I need to request. To me it looks like the current draft (draft-ietf-forces-protocol-18.txt) is not the right one to last call. Specifically, draft-ietf-forces-protocol-18.txt only has three normative references, one to the model (which is PS), and two to existing RFCs that are BCPs. It's reference to the Forces Framework (RFC3746) is informational. Does this mean that you will quickly do an update to the protocol that moves the reference to RFC3746 to be normative, and then I will repeat the last call? Thanks, Ross -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] Sent: 04 November 2008 14:34 To: Ross Callon Cc: uri@MIT.EDU; Avri Doria; Khosravi, Hormuzd M; Robert Haas; Weiming Wang; Patrick Droz; secdir@MIT.EDU; iesg@ietf.org Subject: RE: Review of draft-ietf-forces-protocol-16 (now -18) Ok, Ross I suppose a re-issue of the last call may be in order then. Shall the chair post the LC to the ForCES list only or is this something the IESG does at this stage? cheers, jamal On Mon, 2008-03-11 at 15:05 -0500, Ross Callon wrote: > In general the problem with copying text is that if you want to update > the text, then you need to update both documents (and you need to be > careful to keep them aligned). > > In this particular case, it seems to me that the two documents are very > closely linked, so that it would be necessary to keep them aligned in > any case. > > Ross > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: 03 November 2008 09:51 > To: Ross Callon > Cc: uri@MIT.EDU; Avri Doria; Khosravi, Hormuzd M; Robert Haas; Weiming > Wang; Patrick Droz; secdir@MIT.EDU; iesg@ietf.org > Subject: RE: Review of draft-ietf-forces-protocol-16 (now -18) > > Ross, > > So the choice is either repeating the last call or copying the content? > Since we missed the IESG agenda and we have at least 2 weeks, I dont > mind just adding cutnpasting that content (then we can avoid the downref > altogether). > Thoughts? > > cheers, > jamal > > On Sun, 2008-02-11 at 21:42 -0500, Ross Callon wrote: > > Standards track documents can have normative references to > informational > > documents. However, this needs to be explicitly called out in the IETF > > last call. Thus to do this would requiring repeating the last call (it > > also requires listing the downref in a registry, but I can take care > of > > that when putting the document onto an IESG agenda). > > > > I didn't get this onto the agenda for this week's telechat (My > > apologies, I didn't get to it until Friday night, which is too late). > > Thus it will need to go onto a telechat very soon after the > Minneapolis > > IETF. Thus repeating the IETF last call won't slow it down by much. > > > > Thanks, Ross > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 4 12:22:13 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30EB93A69CE; Tue, 4 Nov 2008 12:22:13 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F9B3A69A3 for ; Tue, 4 Nov 2008 12:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.533 X-Spam-Level: X-Spam-Status: No, score=-4.533 tagged_above=-999 required=5 tests=[AWL=2.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7futso7r2G70 for ; Tue, 4 Nov 2008 12:22:11 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 011893A6B07 for ; Tue, 4 Nov 2008 12:22:10 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA4KM65T013499 for ; Tue, 4 Nov 2008 15:22:08 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA4KM2sm013402 for ; Tue, 4 Nov 2008 15:22:02 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mA4KLstn001365 for ; Tue, 4 Nov 2008 15:21:54 -0500 (EST) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.247]) by mit.edu (Spam Firewall) with ESMTP id CD0B410F1749; Tue, 4 Nov 2008 15:21:33 -0500 (EST) Received: by rv-out-0708.google.com with SMTP id f25so4331579rvb.18 for ; Tue, 04 Nov 2008 12:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dZErejszBZHSE5lgIueURBLyq+sgR+cSzcJPup3FhbM=; b=BCAls4h2F7ziey/aFKFvHyh70kJlH1FjYPUXd491Fvzax4Onl6g89RRw4XezDVy4uC tst6px77l1oUXCt6VDHfKYIU2UUghcFrFvJ+q2fUqg9sD7nnYOhxL8TiUnRaVvXIaoUJ moB3CzBfbf3rqzhRIYrMxm0GsmLQpaEEgfNSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=NArU35mKNqxcB+zQ9mtBVRjLZL3tS0nvpr9bxjvI1qDeLc54FwGe2mX4jnn18Bv1oP ZPIwhYSxqHHTbmdPZD0SsaRZi/tgqitla5z3nVKQsj2swIMGWZYhpBqAZM0fZsKDkANv r4wAJiufMjjt6EQJFHI/eghwfU3w5QCFweq8Q= Received: by 10.140.188.19 with SMTP id l19mr9369rvf.79.1225830093082; Tue, 04 Nov 2008 12:21:33 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id f21sm4552988rvb.5.2008.11.04.12.21.30 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Nov 2008 12:21:32 -0800 (PST) Message-ID: <4910AEC8.6070505@gmail.com> Date: Wed, 05 Nov 2008 09:21:28 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Hartman References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Christian Huitema , Nathan Ward , Dave Thaler , Tim Polk , "secdir@mit.edu" , Suresh Krishnan , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On 2008-11-05 02:29, Sam Hartman wrote: >>>>>> "Brian" == Brian E Carpenter writes: > >> Operating a Teredo server on site does not help unfortunately. > >> > >> It helps an administrator filter outbound packets when sent to > >> an IPv6 address outside 2001::/32. It does not help an > >> administrator filter inbound packets, or packets to/from other > >> Teredo hosts. > > Brian> As far as I can see, there's a general problem in > Brian> attempting to detect and block Teredo packets (I mean > Brian> UDP/IPv4 packets in Teredo format). But it seems to me that > Brian> by running an internal Teredo server, a site is much better > Brian> placed to track and trace Teredo users. This is important > Brian> as Teredo users really need to be running an IPv6-savvy > Brian> host firewall. > > Only if you can convince the users to use that teredo server rather > than say the teredo server that is configured by default in their OS. Agreed, most users will not spontaneously type netsh interface ipv6 set teredo server foobar. You could inject a /32 route into the local IGP. > Unfortunately, by the time you've already reconfigured the computer > you are probably in a position to either disable Teredo if you don't > like it or install a reasonable firewall. Agreed, for sites where the management has that much control over hosts. Brian _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Nov 5 00:54:44 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333F53A6A3D; Wed, 5 Nov 2008 00:54:44 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E30B3A696E for ; Tue, 4 Nov 2008 11:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9U3++tG7sqK for ; Tue, 4 Nov 2008 11:35:23 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 416533A696F for ; Tue, 4 Nov 2008 11:35:22 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA4JZ5gw031355 for ; Tue, 4 Nov 2008 14:35:06 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA4JZ0PE031317 for ; Tue, 4 Nov 2008 14:35:00 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mA4JYr6S008756 for ; Tue, 4 Nov 2008 14:34:53 -0500 (EST) Received: from mailhub.znyx.com (mailhub.znyx.com [208.2.156.141]) by mit.edu (Spam Firewall) with ESMTP id 1575F1231660; Tue, 4 Nov 2008 14:34:31 -0500 (EST) Received: from localhost (jeep.znyx.com [208.2.156.20]) by mailhub.znyx.com (8.12.9/8.12.8) with ESMTP id mA4JFBPR015539; Tue, 4 Nov 2008 11:15:12 -0800 (PST) (envelope-from hadi@znyx.com) From: Jamal Hadi Salim To: Ross Callon In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C05013E27@emailwf1.jnpr.net> References: <4C5E6457CD7911469A07260381288C280A171EAF@orsmsx502.amr.corp.intel.com> <1222602418.5157.77.camel@localhost> <1223842467.4934.84.camel@localhost> <1224531850.4755.5.camel@localhost> <1225286967.4692.12.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013095@emailwf1.jnpr.net> <1225374490.4684.21.camel@localhost> <6FB661FFA3244D41A23FFC862AB6A23A@morannon> <1225677420.4692.22.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013B2E@emailwf1.jnpr.net> <1225723879.4692.33.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013E27@emailwf1.jnpr.net> Organization: ZNYX Networks Date: Tue, 04 Nov 2008 14:33:47 -0500 Message-Id: <1225827227.4811.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Wed, 05 Nov 2008 00:54:43 -0800 Cc: Weiming Wang , secdir@mit.edu, Avri Doria , "Khosravi, Hormuzd M" , iesg@ietf.org, Patrick Droz , Robert Haas Subject: Re: [secdir] Review of draft-ietf-forces-protocol-16 (now -18) X-BeenThere: secdir@ietf.org Reply-To: hadi@znyx.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Ok, Ross I suppose a re-issue of the last call may be in order then. Shall the chair post the LC to the ForCES list only or is this something the IESG does at this stage? cheers, jamal On Mon, 2008-03-11 at 15:05 -0500, Ross Callon wrote: > In general the problem with copying text is that if you want to update > the text, then you need to update both documents (and you need to be > careful to keep them aligned). > > In this particular case, it seems to me that the two documents are very > closely linked, so that it would be necessary to keep them aligned in > any case. > > Ross > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: 03 November 2008 09:51 > To: Ross Callon > Cc: uri@MIT.EDU; Avri Doria; Khosravi, Hormuzd M; Robert Haas; Weiming > Wang; Patrick Droz; secdir@MIT.EDU; iesg@ietf.org > Subject: RE: Review of draft-ietf-forces-protocol-16 (now -18) > > Ross, > > So the choice is either repeating the last call or copying the content? > Since we missed the IESG agenda and we have at least 2 weeks, I dont > mind just adding cutnpasting that content (then we can avoid the downref > altogether). > Thoughts? > > cheers, > jamal > > On Sun, 2008-02-11 at 21:42 -0500, Ross Callon wrote: > > Standards track documents can have normative references to > informational > > documents. However, this needs to be explicitly called out in the IETF > > last call. Thus to do this would requiring repeating the last call (it > > also requires listing the downref in a registry, but I can take care > of > > that when putting the document onto an IESG agenda). > > > > I didn't get this onto the agenda for this week's telechat (My > > apologies, I didn't get to it until Friday night, which is too late). > > Thus it will need to go onto a telechat very soon after the > Minneapolis > > IETF. Thus repeating the IETF last call won't slow it down by much. > > > > Thanks, Ross > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Nov 5 00:54:44 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527043A6AB0; Wed, 5 Nov 2008 00:54:44 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451633A6A61 for ; Tue, 4 Nov 2008 17:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=1.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO34oaNXciXX for ; Tue, 4 Nov 2008 17:17:42 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 6BEED3A6A5A for ; Tue, 4 Nov 2008 17:17:42 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA51HcRv013932 for ; Tue, 4 Nov 2008 20:17:38 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA51HXmk013926 for ; Tue, 4 Nov 2008 20:17:33 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id mA51HPOq022323 for ; Tue, 4 Nov 2008 20:17:26 -0500 (EST) Received: from mailhub.znyx.com (mailhub.znyx.com [208.2.156.141]) by mit.edu (Spam Firewall) with ESMTP id 95FD0C33A84; Tue, 4 Nov 2008 20:17:24 -0500 (EST) Received: from localhost (jeep.znyx.com [208.2.156.20]) by mailhub.znyx.com (8.12.9/8.12.8) with ESMTP id mA50wPPR037376; Tue, 4 Nov 2008 16:58:26 -0800 (PST) (envelope-from hadi@znyx.com) From: Jamal Hadi Salim To: Ross Callon In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C050B2C53@emailwf1.jnpr.net> References: <4C5E6457CD7911469A07260381288C280A171EAF@orsmsx502.amr.corp.intel.com> <1222602418.5157.77.camel@localhost> <1223842467.4934.84.camel@localhost> <1224531850.4755.5.camel@localhost> <1225286967.4692.12.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013095@emailwf1.jnpr.net> <1225374490.4684.21.camel@localhost> <6FB661FFA3244D41A23FFC862AB6A23A@morannon> <1225677420.4692.22.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013B2E@emailwf1.jnpr.net> <1225723879.4692.33.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C05013E27@emailwf1.jnpr.net> <1225827227.4811.6.camel@localhost> <3525C9833C09ED418C6FD6CD9514668C050B2C53@emailwf1.jnpr.net> Organization: ZNYX Networks Date: Tue, 04 Nov 2008 20:17:04 -0500 Message-Id: <1225847824.5029.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Wed, 05 Nov 2008 00:54:43 -0800 Cc: Weiming Wang , secdir@mit.edu, Avri Doria , "Khosravi, Hormuzd M" , iesg@ietf.org, Patrick Droz , Robert Haas Subject: Re: [secdir] Review of draft-ietf-forces-protocol-16 (now -18) X-BeenThere: secdir@ietf.org Reply-To: hadi@znyx.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Tue, 2008-04-11 at 14:50 -0500, Ross Callon wrote: > A down-ref requires an IETF last call, which I need to request. > > To me it looks like the current draft > (draft-ietf-forces-protocol-18.txt) is not the right one to last call. > Specifically, draft-ietf-forces-protocol-18.txt only has three normative > references, one to the model (which is PS), and two to existing RFCs > that are BCPs. It's reference to the Forces Framework (RFC3746) is > informational. > > Does this mean that you will quickly do an update to the protocol that > moves the reference to RFC3746 to be normative, and then I will repeat > the last call? > Sounds reasonable. I am gonna punt to Avri. Avri? cheers, jamal _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Nov 5 10:13:54 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F173A68F1; Wed, 5 Nov 2008 10:13:54 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32A43A68C1 for ; Wed, 5 Nov 2008 10:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.293 X-Spam-Level: X-Spam-Status: No, score=-4.293 tagged_above=-999 required=5 tests=[AWL=2.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64VDi1r6EtRC for ; Wed, 5 Nov 2008 10:13:53 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 037E13A6915 for ; Wed, 5 Nov 2008 10:13:52 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA5IDoYr007648 for ; Wed, 5 Nov 2008 13:13:50 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA5IDiCS007605 for ; Wed, 5 Nov 2008 13:13:45 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mA5IDYjM021633 for ; Wed, 5 Nov 2008 13:13:34 -0500 (EST) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by mit.edu (Spam Firewall) with ESMTP id 37BBB13A3882 for ; Wed, 5 Nov 2008 13:10:42 -0500 (EST) Received: from pgpdev.ihtfp.org (PGPDEV.IHTFP.ORG [204.107.200.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id E141ABD8462; Wed, 5 Nov 2008 13:10:41 -0500 (EST) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id mA5IAeFg009871; Wed, 5 Nov 2008 13:10:40 -0500 To: iesg@ietf.org, secdir@mit.edu From: Derek Atkins Date: Wed, 05 Nov 2008 13:10:39 -0500 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: kanda.masayuki@lab.ntt.co.jp, akato@po.ntts.co.jp Subject: [secdir] sec-dir review of draft-kato-ipsec-camellia-modes-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org [Sorry for the delay in getting back to this document] I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe that the updates between version 07 and 09 have corrected all the issues that I had in my previous review. I have no issues with this version of the document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Nov 5 14:51:48 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678FD3A6827; Wed, 5 Nov 2008 14:51:48 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F933A67FC for ; Wed, 5 Nov 2008 14:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3uDo-1hcNqp for ; Wed, 5 Nov 2008 14:51:46 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 01D553A6774 for ; Wed, 5 Nov 2008 14:51:45 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA5Mphln021240 for ; Wed, 5 Nov 2008 17:51:43 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA5MpfiA021230 for ; Wed, 5 Nov 2008 17:51:42 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mA5MpWrn013711 for ; Wed, 5 Nov 2008 17:51:33 -0500 (EST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id F09D01195D8E; Wed, 5 Nov 2008 17:51:11 -0500 (EST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id mA5Mogv7021227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 17:50:42 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Wed, 5 Nov 2008 17:40:45 -0500 Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.10.43]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id mA5MoRJD023237; Wed, 5 Nov 2008 17:50:29 -0500 (EST) Received: from CORPUSMX50B.corp.emc.com ([128.221.62.43]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 17:50:26 -0500 Received: from W-JNISBETTEST-1 ([10.4.131.147]) by CORPUSMX50B.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 17:50:25 -0500 Date: Wed, 5 Nov 2008 23:50:27 +0100 (W. Europe Standard Time) From: =?iso-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@mit.edu, stephen.nadas@ericsson.com, rcallon@juniper.net, dward@cisco.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-OriginalArrivalTime: 05 Nov 2008 22:50:26.0225 (UTC) FILETIME=[E4C1BA10:01C93F98] X-RSA-Inspected: yes X-RSA-Classifications: X-RSA-Action: allow X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: secdir-secretary@mit.edu Subject: [secdir] Review of draft-ietf-vrrp-unified-spec-02 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Background ---------- This document defines/describes version 3 of the Virtual Router Redundancy Protocol (VRRP), a protocol that assigns virtual routers to physical (VRRP) routers. Claimed benefits of the protocol include high availability default route (IPv4) and fast switch to backup routers (IPv6). Comments -------- Overall, this document reads well to me. I am not an expert on VRRP and so I am probably missing some context here, but it was a bit surprising to see a new version of a protocol in the routing space that does not have any security functionality built-in, especially considering efforts such as RPSEC. Also, the Security Considerations section states "VRRP ... does not currently include any type of authentication" but then goes on to say "In the context of IPv6 operation ... VRRP authentication could be usefully added ..." I guess it would have been useful to learn why this functionality (authentication of sender) was not added despite usages (there is a note on problems with the authentication method used in previous version but those problems do not seem to apply to IPv6 environments, so why was the functionality removed?). A reference to RFC 4593 may also be in place. -- Magnus _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Nov 6 07:19:07 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD64D3A697D; Thu, 6 Nov 2008 07:19:07 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDF63A68D8; Thu, 6 Nov 2008 07:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B730BdLMj5Sq; Thu, 6 Nov 2008 07:19:05 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id E07773A697D; Thu, 6 Nov 2008 07:18:58 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Thu, 06 Nov 2008 07:19:03 PST Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 07:16:18 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Nov 2008 10:16:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 10:16:16 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-rescorla-tls-suiteb-10 Thread-Index: AcjWc3RzDym/07F+Qc2QZB5YiVmx6wFFpjewGSTwmBA= From: "Stephen Hanna" To: X-OriginalArrivalTime: 06 Nov 2008 15:16:17.0321 (UTC) FILETIME=[9D8EB190:01C94022] Cc: ekr@rtfm.com, msalter@restarea.ncsc.mil, secdir@ietf.org Subject: [secdir] secdir review of draft-rescorla-tls-suiteb-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I apologize for the tardiness of these comments. This document provides a brief overview of Suite B cryptography and two profiles with specific requirements that TLS servers and clients can meet in order to satisfy the Suite B requirements while retaining some backward compatibility with older code, if desired. Before reading this document, I was not really familiar with the Suite B requirements. The document provided a clear and concise introduction to the topic with references to more information. The requirements listed in the document seem to meet the implied goal of ensuring secure interoperation between Suite B implementations while allowing for less secure interoperation with older code. I do not have any major concerns with this document. I wonder about the following text in section 4 (in the requirements on clients implementing the Suite B transitional profile): o A Suite B transitional TLS version 1.1 or earlier client MUST offer one cipher suite for each supported security level. This sounds like the client MUST offer only one cipher suite for each supported security level, presumably the cipher suites mentioned in the next two sentences. Actually, I think it is permitted for such a client to offer other cipher suites in order to achieve interoperability with non-Suite B compliant servers, as mentioned in the next bullet. Therefore, I suggest that the text quoted above be changed to something like this: o A Suite B transitional TLS version 1.1 or earlier client MUST offer at least the cipher suites described in the next two sentences for each supported security level. A client that does offer many cipher suites in order to achieve interoperability with non-Suite B compliant servers is subject to a downgrade attack. A similar vulnerability exists for servers that wish to interoperate with non-Suite B compliant clients. Although this threat is obvious to skilled practioners, I think that it should be mentioned in the Security Considerations section of this document since it is a significant vulnerability associated with the recommendations contained in this document. I did notice two minor errors in the document. In the last bullet of the introduction, "An transitional" should be "A transitional". And just before the text quoted above, the word "and" is missing from the preceding sentence. That sentence should read as follows: For a client to implement the Suite B transitional profile, it MUST implement TLS version 1.1 or earlier and the following cipher suite rules apply: To summarize, I am not an expert in Suite B cryptography but I think that this document is beneficial and should be approved. However, the shortcomings that I have pointed out should be corrected before publication. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Nov 6 08:03:26 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D123F3A6834; Thu, 6 Nov 2008 08:03:26 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4677A3A6931 for ; Thu, 6 Nov 2008 05:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2gRuN00A36k for ; Thu, 6 Nov 2008 05:25:25 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5481E3A686A for ; Thu, 6 Nov 2008 05:25:25 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA6DObGm017539 for ; Thu, 6 Nov 2008 08:24:37 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mA6DOUZB017408 for ; Thu, 6 Nov 2008 08:24:31 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mA6DOOZb020696 for ; Thu, 6 Nov 2008 08:24:24 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 48980C28FCB; Thu, 6 Nov 2008 08:24:02 -0500 (EST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id mA6DNMAb005591; Thu, 6 Nov 2008 07:23:22 -0600 Received: from eusrcmw720.eamcs.ericsson.se ([138.85.77.20]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 07:23:21 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 07:23:19 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-vrrp-unified-spec-02 Thread-Index: Ack/mSHnym26GVozSbKasrSH9nVrfQAeU79w References: From: "Stephen Nadas" To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= , , , , X-OriginalArrivalTime: 06 Nov 2008 13:23:21.0567 (UTC) FILETIME=[D6E4AEF0:01C94012] X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id mA6DOUZB017408 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Thu, 06 Nov 2008 08:03:26 -0800 Cc: secdir-secretary@mit.edu, vrrp@ietf.org Subject: Re: [secdir] Review of draft-ietf-vrrp-unified-spec-02 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Magnus, = Thank you for your comments. I am copying vrrp list for their feedback. = Regards, Steve = > -----Original Message----- > From: Magnus Nystr=F6m [mailto:magnus@rsa.com] = > Sent: Wednesday, November 05, 2008 17:50 > To: iesg@ietf.org; secdir@mit.edu; Stephen Nadas; = > rcallon@juniper.net; dward@cisco.com > Cc: secdir-secretary@mit.edu > Subject: Review of draft-ietf-vrrp-unified-spec-02 > = > I have reviewed this document as part of the security = > directorate's ongoing effort to review all IETF documents = > being processed by the IESG. = > These comments were written primarily for the benefit of the = > security area directors. Document editors and WG chairs = > should treat these comments just like any other last call comments. > = > Background > ---------- > = > This document defines/describes version 3 of the Virtual = > Router Redundancy Protocol (VRRP), a protocol that assigns = > virtual routers to physical > (VRRP) routers. Claimed benefits of the protocol include high = > availability default route (IPv4) and fast switch to backup = > routers (IPv6). > = > Comments > -------- > = > Overall, this document reads well to me. I am not an expert = > on VRRP and so I am probably missing some context here, but = > it was a bit surprising to see a new version of a protocol in = > the routing space that does not have any security = > functionality built-in, especially considering efforts such as RPSEC. > = > Also, the Security Considerations section states "VRRP ... = > does not currently include any type of authentication" but = > then goes on to say "In the context of IPv6 operation ... = > VRRP authentication could be usefully added ..." I guess it = > would have been useful to learn why this functionality = > (authentication of sender) was not added despite usages = > (there is a note on problems with the authentication method = > used in previous version but those problems do not seem to = > apply to IPv6 environments, so why was the functionality removed?). > = > A reference to RFC 4593 may also be in place. > = > -- Magnus > = > = _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Nov 7 06:52:34 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F603A6972; Fri, 7 Nov 2008 06:52:34 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFCD3A6972; Fri, 7 Nov 2008 06:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcuwAblF5pDa; Fri, 7 Nov 2008 06:52:32 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EB0A13A694C; Fri, 7 Nov 2008 06:52:31 -0800 (PST) Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id mA7EqFhR022673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Nov 2008 08:52:16 -0600 Message-Id: <867F105F-6735-4E95-BEA7-9F89B4A54D07@softarmor.com> From: Dean Willis To: "Fries, Steffen" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 7 Nov 2008 08:52:01 -0600 References: <200810291237.m9TCbFow003149@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: draft-ietf-sip-media-security-requirements-07@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, sip-chairs@tools.ietf.org Subject: Re: [secdir] Review of draft-ietf-sip-media-security-requirements-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Steffen, can you please respond more directly to the points? Perhaps you could point to specific sections of the document and explain what it said before the change and what it says after the change? Thanks! -- Dean On Nov 7, 2008, at 8:44 AM, Fries, Steffen wrote: > Hi Tero, > > thnk you for the review, in version 08 we addressed the points you > raised, except the numbering of the requirements. Nevertheless, we > have > included references in section 3 that show, were the requirements are > explained (section 5). > > Reagards > Steffen > >> -----Original Message----- >> From: Tero Kivinen [mailto:kivinen@iki.fi] >> Sent: Wednesday, October 29, 2008 1:37 PM >> To: >> draft-ietf-sip-media-security-requirements-07@tools.ietf.org; >> sip-chairs@tools.ietf.org >> Cc: secdir@ietf.org; iesg@ietf.org >> Subject: Review of draft-ietf-sip-media-security-requirements-07.txt >> Importance: High >> >> I have reviewed this document as part of the security >> directorate's ongoing effort to review all IETF documents >> being processed by the IESG. These comments were written >> primarily for the benefit of the security area directors. >> Document editors and WG chairs should treat these comments >> just like any other last call comments. >> >> This draft talks about security requirements of the SIP >> media. As such the whole document talks about security. I do >> not have any security comments for it, but I have some other >> comments and notes about it. >> >> The biggest problem I had when I was reading the document, >> was that section 3, suddenly starts listing different >> requirements like R-PASS-MEDIA, R-PASS-SIG etc, and there is >> no indication where those are described. I tried to look for >> them in the table of contents, but couldn't find them listed there. >> >> Reading forward I finally found those in the section 5, but >> as they are not as separate sections there, they were not >> listed in the table of contents. It would be better to move >> each of those requirement to separate subsection, i.e. make >> "5.1.1 R-FORK-RETARGET" and so on, so those references >> earlier could point to section 5.1.1 and those would also be >> listed in the table of contents. >> >> There is also unexpanded acronym of UAC in section 4.2, and I >> do not what it means and it is not expanded or described in >> any way. There seemed to be also quite a lot of other >> acronyms, so it would be useful to check out if those are >> really described (or expanded) somewhere in the document. >> >> Also it would be useful to expand HERFP also in the section >> 5.1 when describing R-HERFP, not only section 4.2. Now the >> description of R-HERFP does not tell that much: "The media >> security key management protocol MUST function securely even >> in the presence of HERFP behavior." especially if reader >> doesn't remember what HERFP stands for... >> >> The description of R-RTP-VALID seems bit odd. It says that >> "...key negotiation packets MUST NOT pass the RTP validity >> check...". That seems bit odd considering that the name is >> R-RTP-VALID and it says MUST NOT pass validity check. Is that >> description really correct? >> >> Some nits: >> >> Section 8. Acknowledgements has Richard Barnes twice. >> >> Section A.4.3. SSRC and ROC has typo in word binding: >> "Another, used by Security Descriptions, is to use "late >> bindng" -- ... >> -- >> kivinen@safenet-inc.com >> > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Nov 7 07:53:30 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9138D28C11E; Fri, 7 Nov 2008 07:53:30 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFC13A6A49; Fri, 7 Nov 2008 06:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.273 X-Spam-Level: X-Spam-Status: No, score=-5.273 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjMMavbVB+ps; Fri, 7 Nov 2008 06:46:16 -0800 (PST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id A20163A694C; Fri, 7 Nov 2008 06:46:14 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id mA7Ek8Zr010311; Fri, 7 Nov 2008 15:46:09 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id mA7Ejx5q020299; Fri, 7 Nov 2008 15:46:06 +0100 Received: from MCHP7IEA.ww902.siemens.net ([139.25.131.156]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 15:44:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Nov 2008 15:44:22 +0100 Message-ID: In-Reply-To: <200810291237.m9TCbFow003149@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-sip-media-security-requirements-07.txt Thread-Index: Ack5wxqBGLrvTnWMTXmZIfmDQtKkVQHJANlQ References: <200810291237.m9TCbFow003149@fireball.kivinen.iki.fi> From: "Fries, Steffen" To: "Tero Kivinen" , , X-OriginalArrivalTime: 07 Nov 2008 14:44:38.0211 (UTC) FILETIME=[5C034130:01C940E7] X-Mailman-Approved-At: Fri, 07 Nov 2008 07:53:29 -0800 Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-sip-media-security-requirements-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Tero, thnk you for the review, in version 08 we addressed the points you raised, except the numbering of the requirements. Nevertheless, we have included references in section 3 that show, were the requirements are explained (section 5). Reagards Steffen > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Wednesday, October 29, 2008 1:37 PM > To: > draft-ietf-sip-media-security-requirements-07@tools.ietf.org; > sip-chairs@tools.ietf.org > Cc: secdir@ietf.org; iesg@ietf.org > Subject: Review of draft-ietf-sip-media-security-requirements-07.txt > Importance: High > > I have reviewed this document as part of the security > directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written > primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments > just like any other last call comments. > > This draft talks about security requirements of the SIP > media. As such the whole document talks about security. I do > not have any security comments for it, but I have some other > comments and notes about it. > > The biggest problem I had when I was reading the document, > was that section 3, suddenly starts listing different > requirements like R-PASS-MEDIA, R-PASS-SIG etc, and there is > no indication where those are described. I tried to look for > them in the table of contents, but couldn't find them listed there. > > Reading forward I finally found those in the section 5, but > as they are not as separate sections there, they were not > listed in the table of contents. It would be better to move > each of those requirement to separate subsection, i.e. make > "5.1.1 R-FORK-RETARGET" and so on, so those references > earlier could point to section 5.1.1 and those would also be > listed in the table of contents. > > There is also unexpanded acronym of UAC in section 4.2, and I > do not what it means and it is not expanded or described in > any way. There seemed to be also quite a lot of other > acronyms, so it would be useful to check out if those are > really described (or expanded) somewhere in the document. > > Also it would be useful to expand HERFP also in the section > 5.1 when describing R-HERFP, not only section 4.2. Now the > description of R-HERFP does not tell that much: "The media > security key management protocol MUST function securely even > in the presence of HERFP behavior." especially if reader > doesn't remember what HERFP stands for... > > The description of R-RTP-VALID seems bit odd. It says that > "...key negotiation packets MUST NOT pass the RTP validity > check...". That seems bit odd considering that the name is > R-RTP-VALID and it says MUST NOT pass validity check. Is that > description really correct? > > Some nits: > > Section 8. Acknowledgements has Richard Barnes twice. > > Section A.4.3. SSRC and ROC has typo in word binding: > "Another, used by Security Descriptions, is to use "late > bindng" -- ... > -- > kivinen@safenet-inc.com > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Nov 7 07:53:30 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C23928C130; Fri, 7 Nov 2008 07:53:30 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B103A69DE; Fri, 7 Nov 2008 07:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.517 X-Spam-Level: X-Spam-Status: No, score=-5.517 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaPtYz0hAu1B; Fri, 7 Nov 2008 07:43:11 -0800 (PST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id E08B93A690A; Fri, 7 Nov 2008 07:43:10 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id mA7FRQ6U005329; Fri, 7 Nov 2008 16:27:26 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id mA7FROCG000915; Fri, 7 Nov 2008 16:27:26 +0100 Received: from MCHP7IEA.ww902.siemens.net ([139.25.131.156]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 16:25:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Nov 2008 16:25:58 +0100 Message-ID: In-Reply-To: <867F105F-6735-4E95-BEA7-9F89B4A54D07@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-sip-media-security-requirements-07.txt Thread-Index: AclA7GaPZipav/LTRjaxxUDyKtGv9AAAGysw References: <200810291237.m9TCbFow003149@fireball.kivinen.iki.fi> <867F105F-6735-4E95-BEA7-9F89B4A54D07@softarmor.com> From: "Fries, Steffen" To: "Dean Willis" X-OriginalArrivalTime: 07 Nov 2008 15:25:59.0608 (UTC) FILETIME=[230A6380:01C940ED] X-Mailman-Approved-At: Fri, 07 Nov 2008 07:53:29 -0800 Cc: draft-ietf-sip-media-security-requirements-07@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, sip-chairs@tools.ietf.org Subject: Re: [secdir] Review of draft-ietf-sip-media-security-requirements-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi, please find the changes I made in the 08 version addressing the comments from Tero Kivinen. I put the changes inline with Tero's comments. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Wednesday, October 29, 2008 1:37 PM > To: > draft-ietf-sip-media-security-requirements-07@tools.ietf.org; > sip-chairs@tools.ietf.org > Cc: secdir@ietf.org; iesg@ietf.org > Subject: Review of draft-ietf-sip-media-security-requirements-07.txt > Importance: High > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. > Document editors and WG chairs should treat these comments just like > any other last call comments. > > This draft talks about security requirements of the SIP media. As such > the whole document talks about security. I do not have any security > comments for it, but I have some other comments and notes about it. > > The biggest problem I had when I was reading the document, was that > section 3, suddenly starts listing different requirements like > R-PASS-MEDIA, R-PASS-SIG etc, and there is no indication where those > are described. I tried to look for them in the table of contents, but > couldn't find them listed there. [stf] I added a sentence at the beginning of section 4, which start using the requirement abbreviations. Throughout the subsections requirements are stated by using the nomenclature R- to state an explicit requirement. All of the stated requirements are explanied in detail in section 5. The requirements in section 5 are listed according their association to the key management protocol, to attack scenarios, and requirements which can be met inside the key management protocol or outside of the key management protocol. > Reading forward I finally found those in the section 5, but as they > are not as separate sections there, they were not listed in the table > of contents. It would be better to move each of those requirement to > separate subsection, i.e. make > "5.1.1 R-FORK-RETARGET" and so on, so those references earlier could > point to section 5.1.1 and those would also be listed in the table of > contents. [stf] I think it is sufficient to include the above sentence instead of numbering the requirements in sections. > There is also unexpanded acronym of UAC in section 4.2, and I > do not what it means and it is not expanded or described in > any way. There seemed to be also quite a lot of other > acronyms, so it would be useful to check out if those are > really described (or expanded) somewhere in the document. [stf] I included the following statement at the beginning of the terminology section: Furthermore, the terminology described in SIP () regarding functions and components are used throughout the document > Also it would be useful to expand HERFP also in the section > 5.1 when describing R-HERFP, not only section 4.2. Now the > description of R-HERFP does not tell that much: "The media > security key management protocol MUST function securely even > in the presence of HERFP behavior." especially if reader > doesn't remember what HERFP stands for... [stf] I added the following subsentence to the R-HERFP: i.e., the rejection of key information does not reach the sender. > The description of R-RTP-VALID seems bit odd. It says that > "...key negotiation packets MUST NOT pass the RTP validity > check...". That seems bit odd considering that the name is > R-RTP-VALID and it says MUST NOT pass validity check. Is that > description really correct? [stf] I did nothing here, as the stated requirements is correct. > Some nits: > > Section 8. Acknowledgements has Richard Barnes twice. [stf] removed the double Richard and myself from the acknowledgement list > Section A.4.3. SSRC and ROC has typo in word binding: > "Another, used by Security Descriptions, is to use "late > bindng" -- ... [stf] changed to Another, used by Security Descriptions, is to apply "late bindng ... Ciao Steffen > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, November 07, 2008 3:52 PM > To: Fries, Steffen > Cc: Tero Kivinen; > draft-ietf-sip-media-security-requirements-07@tools.ietf.org; > sip-chairs@tools.ietf.org; secdir@ietf.org; iesg@ietf.org > Subject: Re: Review of > draft-ietf-sip-media-security-requirements-07.txt > > Steffen, can you please respond more directly to the points? > Perhaps you could point to specific sections of the document > and explain what it said before the change and what it says > after the change? > > Thanks! > > -- > Dean > > > On Nov 7, 2008, at 8:44 AM, Fries, Steffen wrote: > > > Hi Tero, > > > > thnk you for the review, in version 08 we addressed the points you > > raised, except the numbering of the requirements. Nevertheless, we > > have included references in section 3 that show, were the > requirements > > are explained (section 5). > > > > Reagards > > Steffen > > > >> -----Original Message----- > >> From: Tero Kivinen [mailto:kivinen@iki.fi] > >> Sent: Wednesday, October 29, 2008 1:37 PM > >> To: > >> draft-ietf-sip-media-security-requirements-07@tools.ietf.org; > >> sip-chairs@tools.ietf.org > >> Cc: secdir@ietf.org; iesg@ietf.org > >> Subject: Review of > draft-ietf-sip-media-security-requirements-07.txt > >> Importance: High > >> > >> I have reviewed this document as part of the security > directorate's > >> ongoing effort to review all IETF documents being processed by the > >> IESG. These comments were written primarily for the benefit of the > >> security area directors. > >> Document editors and WG chairs should treat these comments > just like > >> any other last call comments. > >> > >> This draft talks about security requirements of the SIP media. As > >> such the whole document talks about security. I do not have any > >> security comments for it, but I have some other comments and notes > >> about it. > >> > >> The biggest problem I had when I was reading the document, > was that > >> section 3, suddenly starts listing different requirements like > >> R-PASS-MEDIA, R-PASS-SIG etc, and there is no indication > where those > >> are described. I tried to look for them in the table of > contents, but > >> couldn't find them listed there. > >> > >> Reading forward I finally found those in the section 5, > but as they > >> are not as separate sections there, they were not listed > in the table > >> of contents. It would be better to move each of those > requirement to > >> separate subsection, i.e. make > >> "5.1.1 R-FORK-RETARGET" and so on, so those references > earlier could > >> point to section 5.1.1 and those would also be listed in > the table of > >> contents. > >> > >> There is also unexpanded acronym of UAC in section 4.2, > and I do not > >> what it means and it is not expanded or described in any > way. There > >> seemed to be also quite a lot of other acronyms, so it would be > >> useful to check out if those are really described (or expanded) > >> somewhere in the document. > >> > >> Also it would be useful to expand HERFP also in the section > >> 5.1 when describing R-HERFP, not only section 4.2. Now the > >> description of R-HERFP does not tell that much: "The media > security > >> key management protocol MUST function securely even in the > presence > >> of HERFP behavior." especially if reader doesn't remember > what HERFP > >> stands for... > >> > >> The description of R-RTP-VALID seems bit odd. It says that "...key > >> negotiation packets MUST NOT pass the RTP validity check...". That > >> seems bit odd considering that the name is R-RTP-VALID and it says > >> MUST NOT pass validity check. Is that description really correct? > >> > >> Some nits: > >> > >> Section 8. Acknowledgements has Richard Barnes twice. > >> > >> Section A.4.3. SSRC and ROC has typo in word binding: > >> "Another, used by Security Descriptions, is to use "late > bindng" -- > >> ... > >> -- > >> kivinen@safenet-inc.com > >> > > > > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Nov 10 07:56:55 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1C0B3A6A5C; Mon, 10 Nov 2008 07:56:55 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9973A6A49; Mon, 10 Nov 2008 07:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-S2vHhLi9Yu; Mon, 10 Nov 2008 07:56:53 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id D55AE3A683E; Mon, 10 Nov 2008 07:56:38 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mAAFuUrr003999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 17:56:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAAFuSCZ010090; Mon, 10 Nov 2008 17:56:28 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18712.22956.515766.864818@fireball.kivinen.iki.fi> Date: Mon, 10 Nov 2008 17:56:28 +0200 From: Tero Kivinen To: "Fries, Steffen" In-Reply-To: References: <200810291237.m9TCbFow003149@fireball.kivinen.iki.fi> <867F105F-6735-4E95-BEA7-9F89B4A54D07@softarmor.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 14 min X-Total-Time: 13 min Cc: sip-chairs@tools.ietf.org, draft-ietf-sip-media-security-requirements@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, Dean Willis Subject: Re: [secdir] Review of draft-ietf-sip-media-security-requirements-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Fries, Steffen writes: > > The biggest problem I had when I was reading the document, was that > > section 3, suddenly starts listing different requirements like > > R-PASS-MEDIA, R-PASS-SIG etc, and there is no indication where those > > are described. I tried to look for them in the table of contents, but > > couldn't find them listed there. > [stf] I added a sentence at the beginning of section 4, which start > using the requirement abbreviations. > Throughout the subsections requirements are stated by using the > nomenclature R- to state an explicit requirement. All of the > stated > requirements are explanied in detail in section 5. The > requirements > in section 5 are listed according their association to the key > management protocol, to attack scenarios, and requirements > which can be met inside the key management protocol or outside > of the > key management protocol. As section 3 already refers to those R-* requirements, I think it would be better to move the paragarph to section 2. Terminology or at least also in the beginning of section 3. > > Reading forward I finally found those in the section 5, but as they > > are not as separate sections there, they were not listed in the table > > of contents. It would be better to move each of those requirement to > > separate subsection, i.e. make > > "5.1.1 R-FORK-RETARGET" and so on, so those references earlier could > > point to section 5.1.1 and those would also be listed in the table of > > contents. > [stf] I think it is sufficient to include the above sentence instead of > numbering the requirements in sections. It would be nice to be able to find the requirements from the document by simply looking at the table contents. Requirements section is now 5 pages long, so bit more specific pointers would be useful in the table of contents. > > There is also unexpanded acronym of UAC in section 4.2, and I > > do not what it means and it is not expanded or described in > > any way. There seemed to be also quite a lot of other > > acronyms, so it would be useful to check out if those are > > really described (or expanded) somewhere in the document. > [stf] I included the following statement at the beginning of the > terminology section: > Furthermore, the terminology described in SIP > () regarding functions and > components > are used throughout the document Unfortunately at least I didn't want to read 269 pages to just get all the terminology about SIP when reading this document. I would still suggest replacing it with "User agent client (UAC)" in that one place where it is used in this document. > > The description of R-RTP-VALID seems bit odd. It says that > > "...key negotiation packets MUST NOT pass the RTP validity > > check...". That seems bit odd considering that the name is > > R-RTP-VALID and it says MUST NOT pass validity check. Is that > > description really correct? > [stf] I did nothing here, as the stated requirements is correct. Why is there requirement that key negotiation packets MUST fail the validity check? Or is this trying to say that they are not processed at all by the validity check operations, i.e. they bypass them. This requirement sound really wierd, and I do not really have any idea why it is here and what it is trying to say, but as I do not know that much about SIP, it might be that I just do not understand something. > > Section A.4.3. SSRC and ROC has typo in word binding: > > "Another, used by Security Descriptions, is to use "late > > bindng" -- ... > [stf] changed to > Another, used by Security Descriptions, is to apply "late > bindng ... But it is still saying "late bindng" there, and "late binding" in other places. I would guess the "bindng" should be "binding" here too. -- kivinen@iki.fi _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 11 06:53:13 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5121528C12E; Tue, 11 Nov 2008 06:53:13 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6F428C12E; Tue, 11 Nov 2008 06:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.109 X-Spam-Level: X-Spam-Status: No, score=-9.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RE3J72lmUkj; Tue, 11 Nov 2008 06:53:12 -0800 (PST) Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by core3.amsl.com (Postfix) with ESMTP id 8D61528C11A; Tue, 11 Nov 2008 06:53:11 -0800 (PST) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 11 Nov 2008 14:53:05 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.102]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 11 Nov 2008 14:53:05 +0000 From: Stefan Santesson To: "iesg@ietf.org" , "secdir@ietf.org" , Chris Newman , Glenn Parsons , Eric Burger Date: Tue, 11 Nov 2008 14:53:03 +0000 Thread-Topic: SECDIR Review: draft-ietf-lemonade-architecture-04 Thread-Index: AclEDTKngSMek7vxTkqPWVLq0pWqgQ== Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB079AB93@EA-EXMSG-C332.europe.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [secdir] SECDIR Review: draft-ietf-lemonade-architecture-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0896783450==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============0896783450== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB079AB93EAEXMSGC332eu_" --_000_9F11911AED01D24BAA1C2355723C3D321AB079AB93EAEXMSGC332eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document specifies the architecture for mobile email, as described by = the Open Mobile Alliance (OMA), using Internet Mail protocols. This archit= ecture was an important consideration for much of the work of the LEMONADE = (Enhancements to Internet email to Support Diverse Service Environments) wo= rk group in the IETF. This document also describes how the LEMONADE archit= ecture meets the OMA's requirements for their Mobile Email (MEM) service. General comments: I have not reviewed the presented architecture as such. The Security consideration of this document is very short and does not prov= ide me with the basic information I would like to find. This security consideration lists a number of security areas that may apply= to the architecture and the protocols where these security issues are deal= t with. What I would find more useful would be an informative text telling me if th= e architecture specified in THIS document introduce any new security issues= and whether resolutions of those issues are within or outside the scope of= this specification. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_9F11911AED01D24BAA1C2355723C3D321AB079AB93EAEXMSGC332eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as pa= rt of the security directorate's ongoing effort to review all IETF documents bein= g processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chair= s should treat these comments just like any other last call comments.

 

This document specifies the archite= cture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols.  This architecture was an important considera= tion for much of the work of the LEMONADE (Enhancements to Internet email to Sup= port Diverse Service Environments) work group in the IETF.  This document a= lso describes how the LEMONADE architecture meets the OMA's requirements for th= eir Mobile Email (MEM) service.

 

General comments:=

I have not reviewed the presented a= rchitecture as such.

The Security consideration of this = document is very short and does not provide me with the basic information I would li= ke to find.

This security consideration lists a= number of security areas that may apply to the architecture and the protocols wher= e these security issues are dealt with.

What I would find more useful would= be an informative text telling me if the architecture specified in THIS document = introduce any new security issues and whether resolutions of those issues are within = or outside the scope of this specification.

 

 

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 

--_000_9F11911AED01D24BAA1C2355723C3D321AB079AB93EAEXMSGC332eu_-- --===============0896783450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============0896783450==-- From secdir-bounces@ietf.org Tue Nov 11 08:52:43 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D52A3A6A09; Tue, 11 Nov 2008 08:52:43 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3FAF3A69DD for ; Tue, 11 Nov 2008 08:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b65abx5BWD5m for ; Tue, 11 Nov 2008 08:52:40 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 92B083A69BD for ; Tue, 11 Nov 2008 08:52:40 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id mABGqeM7065229 for ; Tue, 11 Nov 2008 11:52:40 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id mABGqevA065225 for ; Tue, 11 Nov 2008 11:52:40 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 11 Nov 2008 11:52:40 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Tue, 11 Nov 2008 11:52:40 -0500 (EST) Subject: [secdir] Assignments for Nov 25th (post-IETF) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org We have ~30 new documents this week with some already scheduled for the December 4th (post-meeting) telechat. Several of the documents on last week's telechat were never reviewed -- if you were holding the token for one of those, you may note that it's no longer assigned. Given the physical meeting next week, I've set the official due date on these two weeks out. That said, some of these documents have been in IETF last call for two weeks already, so reviews sooner than two weeks would, of course, be appreciated. Catherine Meadows is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview And I expect to be in Minneapolis next week; feel free to ask any questions in person. -- Sam For telechat, December 4th Derek Atkins T draft-ietf-6man-reserved-iids-01 Charles Clancy T draft-ietf-l1vpn-ospfv3-auto-discovery-02 Lakshminath Dondeti T draft-ietf-monami6-multiplecoa-10 Donald Eastlake T draft-ietf-mpls-ldp-igp-sync-03 Tobias Gondrom T draft-ietf-pim-rpf-vector-06 Tero Kivinen T draft-igoe-secsh-aes-gcm-00 Marcus Leech T draft-housley-internet-draft-sig-file-06 Vidya Narayanan T draft-ietf-lemonade-imap-notify-07 Susan Thomson T draft-ietf-nfsv4-minorversion1-dot-x-09 Hannes Tschofenig T draft-ietf-nfsv4-pnfs-block-09 Sean Turner T draft-ietf-nfsv4-pnfs-obj-09 Sam Weiler T draft-housley-iesg-rfc3932bis-05 Nico Williams T draft-ietf-nfsv4-minorversion1-26 Larry Zhu T draft-arkko-arp-iana-rules-01 Last calls and special requests: Rob Austein draft-ietf-dime-qos-parameters-07 Richard Barnes draft-ietf-calsify-rfc2445bis-09 Pat Cain draft-ietf-geopriv-pdif-lo-profile-13 Ran Canetti draft-ietf-kitten-gssapi-channel-bindings-05 Alan DeKok draft-ietf-mext-nemo-v4traversal-06 Shawn Emery draft-ietf-nfsv4-rfc1831bis-10 Stephen Farrell draft-ietf-ospf-lls-05 Phillip Hallam-Baker draft-ietf-radext-design-05 Steve Hanna draft-ietf-radext-management-authorization-06 David Harrington draft-ietf-sip-saml-05 Sam Hartman draft-ietf-smime-3850bis-08 Paul Hoffman draft-ietf-smime-3851bis-08 Love Hornquist-Astrand draft-ietf-tcpm-rfc4138bis-04 Jeffrey Hutzelman draft-ietf-tcpm-tcp-uto-09 Charlie Kaufman draft-ietf-tls-des-idea-02 Scott Kelly draft-ietf-tsvwg-rsvp-proxy-approaches-06 Stephen Kent draft-ietf-tsvwg-rsvp-proxy-proto-07 Julien Laganier draft-ietf-softwire-mesh-framework-05 Julien Laganier draft-ietf-softwire-encaps-ipsec-01 Julien Laganier draft-irtf-asrg-dnsbl-07 Marcus Leech draft-ietf-dnsext-forgery-resilience-07 Barry Leiba draft-jerichow-msec-mikey-genext-oma-00 Chris Lonvick draft-kucherawy-sender-auth-header-17 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Alexey Melnikov draft-ietf-pce-pcep-xro-06 Sandy Murphy draft-ietf-mpls-mpls-and-gmpls-security-framework-04 Eric Rescorla draft-wing-sipping-srtp-key-04 Stefan Santesson draft-ietf-lemonade-architecture-04 Carl Wallace draft-ietf-isis-hmac-sha-06 Sam Weiler draft-chown-v6ops-rogue-ra-02 Brian Weis draft-ietf-isis-wg-extlsp-03 Nico Williams draft-ietf-v6ops-ra-guard-01 Kurt Zeilenga R draft-daboo-imap-annotatemore-15 Kurt Zeilenga draft-cheshire-dnsext-dns-sd-05 Larry Zhu draft-thaler-v6ops-teredo-extensions-02 Glen Zorn draft-hoffman-dac-vbr-04 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 11 10:23:23 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048EF28C172; Tue, 11 Nov 2008 10:23:23 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3410E3A6922; Tue, 11 Nov 2008 10:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzxne8QTT0cg; Tue, 11 Nov 2008 10:23:20 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 63FAC3A6A5A; Tue, 11 Nov 2008 10:23:20 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mABIMSST016553; Tue, 11 Nov 2008 11:22:28 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mABIN7C5083310; Tue, 11 Nov 2008 11:23:07 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mABIN7QF021470; Tue, 11 Nov 2008 11:23:07 -0700 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mABIN6Q6021327; Tue, 11 Nov 2008 11:23:06 -0700 Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1226427794.2110; Tue, 11 Nov 2008 13:23:14 -0400 Date: Tue, 11 Nov 2008 13:23:04 -0500 From: Barry Leiba To: iesg@ietf.org, secdir@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: draft-jerichow-msec-mikey-genext-oma@tools.ietf.org, hannes.tschofenig@nsn.com Subject: [secdir] secdir review of draft-jerichow-msec-mikey-genext-oma-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. --- This document defines how to use an extension field to contain extended message data. The Security Considerations section is complete, and I don't see any security concerns here. No problem with this document. Barry -- Barry Leiba, Senior Technical Staff (leiba@watson.ibm.com) Internet Messaging Technology, IBM Research http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Nov 11 23:30:17 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413323A67B3; Tue, 11 Nov 2008 23:30:17 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10CF3A6ABB; Tue, 11 Nov 2008 07:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDmAWBAtibYh; Tue, 11 Nov 2008 07:23:29 -0800 (PST) Received: from smtp12.bis.na.blackberry.com (smtp12.bis.na.blackberry.com [216.9.248.26]) by core3.amsl.com (Postfix) with ESMTP id 711F33A6B2C; Tue, 11 Nov 2008 07:23:27 -0800 (PST) Received: from bda381.bisx.prod.on.blackberry (bda381.bisx.prod.on.blackberry [172.20.234.81]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id mABFNQvW030840; Tue, 11 Nov 2008 15:23:26 GMT Received: from bda381.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda381.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id mABFNNLm017168; Tue, 11 Nov 2008 15:23:23 GMT X-rim-org-msg-ref-id: 415106647 Message-ID: <415106647-1226417003-cardhu_decombobulator_blackberry.rim.net-1120935944-@bxe155.bisx.prod.on.blackberry> X-Priority: Normal References: <9F11911AED01D24BAA1C2355723C3D321AB079AB93@EA-EXMSG-C332.europe.corp.microsoft.com> In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB079AB93@EA-EXMSG-C332.europe.corp.microsoft.com> Sensitivity: Normal Importance: Normal To: "Stefan Santesson" , "iesg@ietf.org" , "secdir@ietf.org" , "Chris Newman" , "Glenn Parsons" From: "eburger" Date: Tue, 11 Nov 2008 15:23:29 +0000 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 11 Nov 2008 23:30:15 -0800 Subject: Re: [secdir] SECDIR Review: draft-ietf-lemonade-architecture-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@standardstrack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1624713798==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============1624713798== Content-Type: multipart/alternative; boundary="part58502-boundary-1655942078-585788940" --part58502-boundary-1655942078-585788940 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" WW91IGFyZSBjb3JyZWN0OiB0aGlzIGRvY3VtZW50IGhhcyBubyBzZWN1cml0eSBpc3N1ZXMgaW4g aXRzZWxmOyB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyByZWFsbHkgYSBy b2FkIG1hcCBmb3IgdGhlIHJlc3Qgb2YgdGhlIGxlbW9uYWRlIHdvcmsgKGFsbW9zdCBjb21wbGV0 ZWQpLiANCg0KQ2FuIHdlIGxlYXZlIHRoZSBkb2N1bWVudCBhcyBpcywgb3Igc2hvdWxkIHdlIGp1 c3Qgc2F5LCAidGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGluIGl0c2VsZi4gU2VlIHRoZSBwcm90b2NvbCBkb2N1bWVudHMgdGhlbXNl bHZlcyBmb3IgYW55IHNlY3VyaXR5IGlzc3Vlcy4iPyBPdXIgcHJlZmVyZW5jZSBpcyB0byBsZXQg aXQgbGllLCBidXQgd2UgYXJlIG9wZW4gdG8gc3VnZ2VzdGlvbnMuIA0KDQpUaGFua3MgZm9yIHlv dXIgcmV2aWV3LiANCg0KLS0NCkVyaWMgQnVyZ2VyDQoNClNlbnQgZnJvbSBteSBtb2JpbGUgZGV2 aWNlOyBzb3JyeSBpZiB0ZXJzZS4gQWxsIG1vYmlsZSB1c2VycyBuZWVkIGxlbW9uYWRlLiAgU2Vl IDxodHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlPiBmb3IgbW9yZSBp bmZvcm1hdGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZWZhbiBT YW50ZXNzb24gPHN0ZWZhbnNAbWljcm9zb2Z0LmNvbT4NCg0KRGF0ZTogVHVlLCAxMSBOb3YgMjAw OCAxNDo1MzowMyANClRvOiBpZXNnQGlldGYub3JnPGllc2dAaWV0Zi5vcmc+OyBzZWNkaXJAaWV0 Zi5vcmc8c2VjZGlyQGlldGYub3JnPjsgQ2hyaXMgTmV3bWFuPGNocmlzLm5ld21hbkBzdW4uY29t PjsgR2xlbm4gUGFyc29uczxncGFyc29uc0Bub3J0ZWwuY29tPjsgRXJpYyBCdXJnZXI8ZWJ1cmdl ckBzdGFuZGFyZHN0cmFjay5jb20+DQpTdWJqZWN0OiBTRUNESVIgUmV2aWV3OiBkcmFmdC1pZXRm LWxlbW9uYWRlLWFyY2hpdGVjdHVyZS0wNA0KDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3Vt ZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQg dG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cu ICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBv ZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBj aGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFz dCBjYWxsIGNvbW1lbnRzLg0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgYXJjaGl0ZWN0 dXJlIGZvciBtb2JpbGUgZW1haWwsIGFzIGRlc2NyaWJlZCBieSB0aGUgT3BlbiBNb2JpbGUgQWxs aWFuY2UgKE9NQSksIHVzaW5nIEludGVybmV0IE1haWwgcHJvdG9jb2xzLiAgVGhpcyBhcmNoaXRl Y3R1cmUgd2FzIGFuIGltcG9ydGFudCBjb25zaWRlcmF0aW9uIGZvciBtdWNoIG9mIHRoZSB3b3Jr IG9mIHRoZSBMRU1PTkFERSAoRW5oYW5jZW1lbnRzIHRvIEludGVybmV0IGVtYWlsIHRvIFN1cHBv cnQgRGl2ZXJzZSBTZXJ2aWNlIEVudmlyb25tZW50cykgd29yayBncm91cCBpbiB0aGUgSUVURi4g IFRoaXMgZG9jdW1lbnQgYWxzbyBkZXNjcmliZXMgaG93IHRoZSBMRU1PTkFERSBhcmNoaXRlY3R1 cmUgbWVldHMgdGhlIE9NQSdzIHJlcXVpcmVtZW50cyBmb3IgdGhlaXIgTW9iaWxlIEVtYWlsIChN RU0pIHNlcnZpY2UuDQoNCkdlbmVyYWwgY29tbWVudHM6DQpJIGhhdmUgbm90IHJldmlld2VkIHRo ZSBwcmVzZW50ZWQgYXJjaGl0ZWN0dXJlIGFzIHN1Y2guDQpUaGUgU2VjdXJpdHkgY29uc2lkZXJh dGlvbiBvZiB0aGlzIGRvY3VtZW50IGlzIHZlcnkgc2hvcnQgYW5kIGRvZXMgbm90IHByb3ZpZGUg bWUgd2l0aCB0aGUgYmFzaWMgaW5mb3JtYXRpb24gSSB3b3VsZCBsaWtlIHRvIGZpbmQuDQpUaGlz IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gbGlzdHMgYSBudW1iZXIgb2Ygc2VjdXJpdHkgYXJlYXMg dGhhdCBtYXkgYXBwbHkgdG8gdGhlIGFyY2hpdGVjdHVyZSBhbmQgdGhlIHByb3RvY29scyB3aGVy ZSB0aGVzZSBzZWN1cml0eSBpc3N1ZXMgYXJlIGRlYWx0IHdpdGguDQpXaGF0IEkgd291bGQgZmlu ZCBtb3JlIHVzZWZ1bCB3b3VsZCBiZSBhbiBpbmZvcm1hdGl2ZSB0ZXh0IHRlbGxpbmcgbWUgaWYg dGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpZWQgaW4gVEhJUyBkb2N1bWVudCBpbnRyb2R1Y2UgYW55 IG5ldyBzZWN1cml0eSBpc3N1ZXMgYW5kIHdoZXRoZXIgcmVzb2x1dGlvbnMgb2YgdGhvc2UgaXNz dWVzIGFyZSB3aXRoaW4gb3Igb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9u Lg0KDQoNClN0ZWZhbiBTYW50ZXNzb24NClNlbmlvciBQcm9ncmFtIE1hbmFnZXINCldpbmRvd3Mg U2VjdXJpdHksIFN0YW5kYXJkcw0KDQoNCg== --part58502-boundary-1655942078-585788940 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpEPSJE QVY6IiB4bWxuczp4Mj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvZXhjZWwv MjAwMy94bWwiIHhtbG5zOm9pcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvc29hcC9kaXJlY3RvcnkvIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAw MC8wOS94bWxkc2lnIyIgeG1sbnM6ZHNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvZHNwIiB4bWxuczp1ZGM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0 YS91ZGMiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5z OnN1Yj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8x L2FsZXJ0cy8iIHhtbG5zOmVjPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyMiIHht bG5zOnNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvIiB4bWxuczpz cHM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6 eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeG1sbnM6dWRj eGY9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91ZGMveG1sZmlsZSIgeG1sbnM6 d2Y9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL3dvcmtmbG93 LyIgeG1sbnM6bXZlcj0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL21hcmt1cC1j b21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v b2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM6bXJlbHM9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxm b3JtYXRzLm9yZy9wYWNrYWdlLzIwMDYvcmVsYXRpb25zaGlwcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1s bnM6ZXgxMm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMv MjAwNi9tZXNzYWdlcyIgeG1sbnM6Wj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbToiIHhtbG5z OnN0PSImIzE7IiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+IDxoZWFk PjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD11dGYtOCI+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIg KGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tICAvKiBGb250IERlZmluaXRpb25zICovICBA Zm9udC1mYWNlIAl7Zm9udC1mYW1pbHk6U2ltU3VuOyAJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9IEBmb250LWZhY2UgCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsgCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fSBAZm9udC1mYWNlIAl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsg CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30gQGZvbnQtZmFjZSAJe2ZvbnQtZmFtaWx5 OiJcQFNpbVN1biI7IAlwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30gIC8qIFN0eWxlIERl ZmluaXRpb25zICovICBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsIAl7 bWFyZ2luOjBjbTsgCW1hcmdpbi1ib3R0b206LjAwMDFwdDsgCWZvbnQtc2l6ZToxMS4wcHQ7IAlm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30gYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluayAJe21zby1zdHlsZS1wcmlvcml0eTo5OTsgCWNvbG9yOmJsdWU7IAl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30gYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkIAl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5OyAJY29sb3I6cHVycGxlOyAJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9IHNwYW4uRW1haWxTdHlsZTE3IAl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsgCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IAljb2xvcjp3aW5kb3d0ZXh0 O30gLk1zb0NocERlZmF1bHQgCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9IEBwYWdlIFNl Y3Rpb24xIAl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7IAltYXJnaW46NzAuODVwdCA3MC44NXB0IDcw Ljg1cHQgNzAuODVwdDt9IGRpdi5TZWN0aW9uMSAJe3BhZ2U6U2VjdGlvbjE7fSAtLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPiAgPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz48L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4gIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4gICA8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4gIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+IDxi b2R5IGxhbmc9U1YgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT5Zb3UgYXJlIGNvcnJlY3Q6IHRoaXMg ZG9jdW1lbnQgaGFzIG5vIHNlY3VyaXR5IGlzc3VlcyBpbiBpdHNlbGY7IHRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHJlYWxseSBhIHJvYWQgbWFwIGZvciB0aGUgcmVzdCBv ZiB0aGUgbGVtb25hZGUgd29yayAoYWxtb3N0IGNvbXBsZXRlZCkuIDxici8+PGJyLz5DYW4gd2Ug bGVhdmUgdGhlIGRvY3VtZW50IGFzIGlzLCBvciBzaG91bGQgd2UganVzdCBzYXksICJ0aGlzIGRv Y3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBhbnkgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4g aXRzZWxmLiBTZWUgdGhlIHByb3RvY29sIGRvY3VtZW50cyB0aGVtc2VsdmVzIGZvciBhbnkgc2Vj dXJpdHkgaXNzdWVzLiI/IE91ciBwcmVmZXJlbmNlIGlzIHRvIGxldCBpdCBsaWUsIGJ1dCB3ZSBh cmUgb3BlbiB0byBzdWdnZXN0aW9ucy4gPGJyLz48YnIvPlRoYW5rcyBmb3IgeW91ciByZXZpZXcu IDxici8+PHA+LS08YnIvPkVyaWMgQnVyZ2VyPGJyLz48YnIvPlNlbnQgZnJvbSBteSBtb2JpbGUg ZGV2aWNlOyBzb3JyeSBpZiB0ZXJzZS4gQWxsIG1vYmlsZSB1c2VycyBuZWVkIGxlbW9uYWRlLiAg U2VlICZsdDtodHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlJmd0OyBm b3IgbW9yZSBpbmZvcm1hdGlvbi48L3A+PHA+PGhyIHNpemU9MiB3aWR0aD0xMDAlIGFsaWduPWNl bnRlciB0YWJpbmRleD0tMT48Yj5Gcm9tPC9iPjogIFN0ZWZhbiBTYW50ZXNzb24gJmx0O3N0ZWZh bnNAbWljcm9zb2Z0LmNvbSZndDs8YnI+PGI+RGF0ZTwvYj46IFR1ZSwgMTEgTm92IDIwMDggMTQ6 NTM6MDMgKzAwMDA8YnI+PGI+VG88L2I+OiBpZXNnQGlldGYub3JnJmx0O2llc2dAaWV0Zi5vcmcm Z3Q7OyBzZWNkaXJAaWV0Zi5vcmcmbHQ7c2VjZGlyQGlldGYub3JnJmd0OzsgQ2hyaXMgTmV3bWFu Jmx0O2NocmlzLm5ld21hbkBzdW4uY29tJmd0OzsgR2xlbm4gUGFyc29ucyZsdDtncGFyc29uc0Bu b3J0ZWwuY29tJmd0OzsgRXJpYyBCdXJnZXImbHQ7ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20m Z3Q7PGJyPjxiPlN1YmplY3Q8L2I+OiBTRUNESVIgUmV2aWV3OiBkcmFmdC1pZXRmLWxlbW9uYWRl LWFyY2hpdGVjdHVyZS0wNDxicj48L2ZvbnQ+PC9wPiA8ZGl2IGNsYXNzPVNlY3Rpb24xPiA8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1 bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0 IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNH LiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVu ZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuJm5ic3A7IERvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFu eSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPiA8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ IDxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPlRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIHRoZSBhcmNoaXRlY3R1cmUgZm9yIG1vYmlsZSBlbWFpbCwgYXMgZGVzY3JpYmVkIGJ5IHRo ZSBPcGVuIE1vYmlsZSBBbGxpYW5jZSAoT01BKSwgdXNpbmcgSW50ZXJuZXQgTWFpbCBwcm90b2Nv bHMuJm5ic3A7IFRoaXMgYXJjaGl0ZWN0dXJlIHdhcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlv biBmb3IgbXVjaCBvZiB0aGUgd29yayBvZiB0aGUgTEVNT05BREUgKEVuaGFuY2VtZW50cyB0byBJ bnRlcm5ldCBlbWFpbCB0byBTdXBwb3J0IERpdmVyc2UgU2VydmljZSBFbnZpcm9ubWVudHMpIHdv cmsgZ3JvdXAgaW4gdGhlIElFVEYuJm5ic3A7IFRoaXMgZG9jdW1lbnQgYWxzbyBkZXNjcmliZXMg aG93IHRoZSBMRU1PTkFERSBhcmNoaXRlY3R1cmUgbWVldHMgdGhlIE9NQSdzIHJlcXVpcmVtZW50 cyBmb3IgdGhlaXIgTW9iaWxlIEVtYWlsIChNRU0pIHNlcnZpY2UuPG86cD48L286cD48L3NwYW4+ PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+IDxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPkdlbmVyYWwg Y29tbWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUz5JIGhhdmUgbm90IHJldmlld2VkIHRoZSBwcmVzZW50ZWQgYXJjaGl0ZWN0dXJl IGFzIHN1Y2guPG86cD48L286cD48L3NwYW4+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUz5UaGUgU2VjdXJpdHkgY29uc2lkZXJhdGlvbiBvZiB0aGlzIGRvY3VtZW50IGlz IHZlcnkgc2hvcnQgYW5kIGRvZXMgbm90IHByb3ZpZGUgbWUgd2l0aCB0aGUgYmFzaWMgaW5mb3Jt YXRpb24gSSB3b3VsZCBsaWtlIHRvIGZpbmQuPG86cD48L286cD48L3NwYW4+PC9wPiA8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5UaGlzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24g bGlzdHMgYSBudW1iZXIgb2Ygc2VjdXJpdHkgYXJlYXMgdGhhdCBtYXkgYXBwbHkgdG8gdGhlIGFy Y2hpdGVjdHVyZSBhbmQgdGhlIHByb3RvY29scyB3aGVyZSB0aGVzZSBzZWN1cml0eSBpc3N1ZXMg YXJlIGRlYWx0IHdpdGguPG86cD48L286cD48L3NwYW4+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUz5XaGF0IEkgd291bGQgZmluZCBtb3JlIHVzZWZ1bCB3b3VsZCBiZSBh biBpbmZvcm1hdGl2ZSB0ZXh0IHRlbGxpbmcgbWUgaWYgdGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZp ZWQgaW4gVEhJUyBkb2N1bWVudCBpbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0eSBpc3N1ZXMgYW5k IHdoZXRoZXIgcmVzb2x1dGlvbnMgb2YgdGhvc2UgaXNzdWVzIGFyZSB3aXRoaW4gb3Igb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4g PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+IDxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiAiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjptYXJvb24nPlN0ZWZhbiBTYW50ZXNzb248L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+IDxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiOyBjb2xvcjojNDAwMDQwJz5TZW5pb3IgUHJvZ3JhbSBNYW5h Z2VyPC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTogMTIuMHB0O2ZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7Y29sb3I6bmF2eSc+PG86cD48L286cD48 L3NwYW4+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTogIkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzQwMDA0MCc+V2luZG93cyBTZWN1cml0eSwgU3RhbmRhcmRzPC9zcGFuPjwvYj48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+IDxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4gPC9kaXY+IDwvYm9keT4gPC9odG1sPiAg --part58502-boundary-1655942078-585788940-- --===============1624713798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============1624713798==-- From secdir-bounces@ietf.org Wed Nov 12 01:03:05 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2203A6894; Wed, 12 Nov 2008 01:03:05 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D813A6894; Wed, 12 Nov 2008 01:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQJFsoAKS2Ii; Wed, 12 Nov 2008 01:03:02 -0800 (PST) Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by core3.amsl.com (Postfix) with ESMTP id 88F873A682B; Wed, 12 Nov 2008 01:03:01 -0800 (PST) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 12 Nov 2008 09:03:01 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.102]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 12 Nov 2008 09:03:00 +0000 From: Stefan Santesson To: "eburger@standardstrack.com" , "iesg@ietf.org" , "secdir@ietf.org" , Chris Newman , Glenn Parsons Date: Wed, 12 Nov 2008 09:02:58 +0000 Thread-Topic: SECDIR Review: draft-ietf-lemonade-architecture-04 Thread-Index: AclEEYBxHO/PV57TQlSzWVH+3w7cPwAkirHw Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB079AEC4@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D321AB079AB93@EA-EXMSG-C332.europe.corp.microsoft.com> <415106647-1226417003-cardhu_decombobulator_blackberry.rim.net-1120935944-@bxe155.bisx.prod.on.blackberry> In-Reply-To: <415106647-1226417003-cardhu_decombobulator_blackberry.rim.net-1120935944-@bxe155.bisx.prod.on.blackberry> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [secdir] SECDIR Review: draft-ietf-lemonade-architecture-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1253541546==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============1253541546== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB079AEC4EAEXMSGC332eu_" --_000_9F11911AED01D24BAA1C2355723C3D321AB079AEC4EAEXMSGC332eu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KWW91IGNvdWxkIGFsc28gbGVhdmUgdGhlIGN1cnJlbnQgdGV4dCBhcyBpdCBp cyBidXQgYWRkIHRoZSBzZW50ZW5jZSB5b3UgcHJvcG9zZWQg4oCcdGhpcyBkb2N1bWVudCBkb2Vz IG5vdCBpbnRyb2R1Y2UgYW55IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIGl0c2VsZuKAnSB0 byBjbGFyaWZ5Lg0KUGVyc29uYWxseSBJIHRoaW5rIGl0IHdvdWxkIG1ha2UgeW91ciBkb2N1bWVu dCBiZXR0ZXIsIGJ1dCB3aGV0aGVyIHRoaXMgaXMgbmVjZXNzYXJ5IGlzIHRvdGFsbHkgdXAgdG8g eW91IGFuZCB0aGUgSUVTRy4NCg0KDQpTdGVmYW4gU2FudGVzc29uDQpTZW5pb3IgUHJvZ3JhbSBN YW5hZ2VyDQpXaW5kb3dzIFNlY3VyaXR5LCBTdGFuZGFyZHMNCg0KRnJvbTogZWJ1cmdlciBbbWFp bHRvOmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tXQ0KU2VudDogZGVuIDExIG5vdmVtYmVyIDIw MDggMTY6MjMNClRvOiBTdGVmYW4gU2FudGVzc29uOyBpZXNnQGlldGYub3JnOyBzZWNkaXJAaWV0 Zi5vcmc7IENocmlzIE5ld21hbjsgR2xlbm4gUGFyc29ucw0KU3ViamVjdDogUmU6IFNFQ0RJUiBS ZXZpZXc6IGRyYWZ0LWlldGYtbGVtb25hZGUtYXJjaGl0ZWN0dXJlLTA0DQoNCllvdSBhcmUgY29y cmVjdDogdGhpcyBkb2N1bWVudCBoYXMgbm8gc2VjdXJpdHkgaXNzdWVzIGluIGl0c2VsZjsgdGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMgcmVhbGx5IGEgcm9hZCBtYXAgZm9y IHRoZSByZXN0IG9mIHRoZSBsZW1vbmFkZSB3b3JrIChhbG1vc3QgY29tcGxldGVkKS4NCg0KQ2Fu IHdlIGxlYXZlIHRoZSBkb2N1bWVudCBhcyBpcywgb3Igc2hvdWxkIHdlIGp1c3Qgc2F5LCAidGhp cyBkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IGluIGl0c2VsZi4gU2VlIHRoZSBwcm90b2NvbCBkb2N1bWVudHMgdGhlbXNlbHZlcyBmb3IgYW55 IHNlY3VyaXR5IGlzc3Vlcy4iPyBPdXIgcHJlZmVyZW5jZSBpcyB0byBsZXQgaXQgbGllLCBidXQg d2UgYXJlIG9wZW4gdG8gc3VnZ2VzdGlvbnMuDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuDQoN Ci0tDQpFcmljIEJ1cmdlcg0KDQpTZW50IGZyb20gbXkgbW9iaWxlIGRldmljZTsgc29ycnkgaWYg dGVyc2UuIEFsbCBtb2JpbGUgdXNlcnMgbmVlZCBsZW1vbmFkZS4gU2VlIDxodHRwOi8vd3d3LnN0 YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlPiBmb3IgbW9yZSBpbmZvcm1hdGlvbi4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFN0ZWZhbiBTYW50ZXNzb24g PHN0ZWZhbnNAbWljcm9zb2Z0LmNvbT4NCkRhdGU6IFR1ZSwgMTEgTm92IDIwMDggMTQ6NTM6MDMg KzAwMDANClRvOiBpZXNnQGlldGYub3JnPGllc2dAaWV0Zi5vcmc+OyBzZWNkaXJAaWV0Zi5vcmc8 c2VjZGlyQGlldGYub3JnPjsgQ2hyaXMgTmV3bWFuPGNocmlzLm5ld21hbkBzdW4uY29tPjsgR2xl bm4gUGFyc29uczxncGFyc29uc0Bub3J0ZWwuY29tPjsgRXJpYyBCdXJnZXI8ZWJ1cmdlckBzdGFu ZGFyZHN0cmFjay5jb20+DQpTdWJqZWN0OiBTRUNESVIgUmV2aWV3OiBkcmFmdC1pZXRmLWxlbW9u YWRlLWFyY2hpdGVjdHVyZS0wNA0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNv bW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1 cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91 bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29t bWVudHMuDQoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBhcmNoaXRlY3R1cmUgZm9yIG1v YmlsZSBlbWFpbCwgYXMgZGVzY3JpYmVkIGJ5IHRoZSBPcGVuIE1vYmlsZSBBbGxpYW5jZSAoT01B KSwgdXNpbmcgSW50ZXJuZXQgTWFpbCBwcm90b2NvbHMuICBUaGlzIGFyY2hpdGVjdHVyZSB3YXMg YW4gaW1wb3J0YW50IGNvbnNpZGVyYXRpb24gZm9yIG11Y2ggb2YgdGhlIHdvcmsgb2YgdGhlIExF TU9OQURFIChFbmhhbmNlbWVudHMgdG8gSW50ZXJuZXQgZW1haWwgdG8gU3VwcG9ydCBEaXZlcnNl IFNlcnZpY2UgRW52aXJvbm1lbnRzKSB3b3JrIGdyb3VwIGluIHRoZSBJRVRGLiAgVGhpcyBkb2N1 bWVudCBhbHNvIGRlc2NyaWJlcyBob3cgdGhlIExFTU9OQURFIGFyY2hpdGVjdHVyZSBtZWV0cyB0 aGUgT01BJ3MgcmVxdWlyZW1lbnRzIGZvciB0aGVpciBNb2JpbGUgRW1haWwgKE1FTSkgc2Vydmlj ZS4NCg0KR2VuZXJhbCBjb21tZW50czoNCkkgaGF2ZSBub3QgcmV2aWV3ZWQgdGhlIHByZXNlbnRl ZCBhcmNoaXRlY3R1cmUgYXMgc3VjaC4NClRoZSBTZWN1cml0eSBjb25zaWRlcmF0aW9uIG9mIHRo aXMgZG9jdW1lbnQgaXMgdmVyeSBzaG9ydCBhbmQgZG9lcyBub3QgcHJvdmlkZSBtZSB3aXRoIHRo ZSBiYXNpYyBpbmZvcm1hdGlvbiBJIHdvdWxkIGxpa2UgdG8gZmluZC4NClRoaXMgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbiBsaXN0cyBhIG51bWJlciBvZiBzZWN1cml0eSBhcmVhcyB0aGF0IG1heSBh cHBseSB0byB0aGUgYXJjaGl0ZWN0dXJlIGFuZCB0aGUgcHJvdG9jb2xzIHdoZXJlIHRoZXNlIHNl Y3VyaXR5IGlzc3VlcyBhcmUgZGVhbHQgd2l0aC4NCldoYXQgSSB3b3VsZCBmaW5kIG1vcmUgdXNl ZnVsIHdvdWxkIGJlIGFuIGluZm9ybWF0aXZlIHRleHQgdGVsbGluZyBtZSBpZiB0aGUgYXJjaGl0 ZWN0dXJlIHNwZWNpZmllZCBpbiBUSElTIGRvY3VtZW50IGludHJvZHVjZSBhbnkgbmV3IHNlY3Vy aXR5IGlzc3VlcyBhbmQgd2hldGhlciByZXNvbHV0aW9ucyBvZiB0aG9zZSBpc3N1ZXMgYXJlIHdp dGhpbiBvciBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNCg0KU3Rl ZmFuIFNhbnRlc3Nvbg0KU2VuaW9yIFByb2dyYW0gTWFuYWdlcg0KV2luZG93cyBTZWN1cml0eSwg U3RhbmRhcmRzDQoNCg== --_000_9F11911AED01D24BAA1C2355723C3D321AB079AEC4EAEXMSGC332eu_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpEPSJE QVY6IiB4bWxuczp4Mj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvZXhjZWwv MjAwMy94bWwiIHhtbG5zOm9pcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvc29hcC9kaXJlY3RvcnkvIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAw MC8wOS94bWxkc2lnIyIgeG1sbnM6ZHNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvZHNwIiB4bWxuczp1ZGM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0 YS91ZGMiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5z OnN1Yj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8x L2FsZXJ0cy8iIHhtbG5zOmVjPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyMiIHht bG5zOnNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvIiB4bWxuczpz cHM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6 eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeG1sbnM6dWRj eGY9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91ZGMveG1sZmlsZSIgeG1sbnM6 d2Y9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL3dvcmtmbG93 LyIgeG1sbnM6bXZlcj0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL21hcmt1cC1j b21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v b2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM6bXJlbHM9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxm b3JtYXRzLm9yZy9wYWNrYWdlLzIwMDYvcmVsYXRpb25zaGlwcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1s bnM6ZXgxMm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMv MjAwNi9tZXNzYWdlcyIgeG1sbnM6Wj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbToiIHhtbG5z OnN0PSImIzE7IiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxo ZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBj aGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBX b3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+DQo8c3R5bGU+DQp2XDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4NCjxzdHls ZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcw Ljg1cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0K PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KDQo8Ym9keSBsYW5nPVNWIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xh c3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5IaQ0KRXJpYyw8bzpwPjwvbzpwPjwvc3Bh bj48L2E+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPllvdSBjb3VsZCBhbHNvIGxlYXZl DQp0aGUgY3VycmVudCB0ZXh0IGFzIGl0IGlzIGJ1dCBhZGQgdGhlIHNlbnRlbmNlIHlvdSBwcm9w b3NlZCDigJw8L3NwYW4+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIic+dGhpcw0KZG9jdW1lbnQgZG9l cyBub3QgaW50cm9kdWNlIGFueSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBpdHNlbGY8L3Nw YW4+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPuKAnSB0byBjbGFyaWZ5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlBlcnNvbmFsbHkgSSB0aGluayBpdA0Kd291bGQg bWFrZSB5b3VyIGRvY3VtZW50IGJldHRlciwgYnV0IHdoZXRoZXIgdGhpcyBpcyBuZWNlc3Nhcnkg aXMgdG90YWxseSB1cCB0bw0KeW91IGFuZCB0aGUgSUVTRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6bWFyb29uJz5TdGVmYW4gU2FudGVzc29uPC9zcGFuPjwvYj48c3BhbiBsYW5n PUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojNDAwMDQwJz5TZW5pb3Ig UHJvZ3JhbSBNYW5hZ2VyPC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToN CjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2NvbG9yOm5hdnkn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojNDAwMDQwJz5XaW5kb3dzIFNlY3VyaXR5LCBTdGFuZGFyZHM8L3Nw YW4+PC9iPjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSc+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGVidXJnZXIgW21haWx0bzplYnVyZ2Vy QHN0YW5kYXJkc3RyYWNrLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMTEgbm92ZW1iZXIg MjAwOCAxNjoyMzxicj4NCjxiPlRvOjwvYj4gU3RlZmFuIFNhbnRlc3NvbjsgaWVzZ0BpZXRmLm9y Zzsgc2VjZGlyQGlldGYub3JnOyBDaHJpcyBOZXdtYW47DQpHbGVubiBQYXJzb25zPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBTRUNESVIgUmV2aWV3OiBkcmFmdC1pZXRmLWxlbW9uYWRlLWFyY2hp dGVjdHVyZS0wNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiJz5Zb3UNCmFyZSBjb3JyZWN0OiB0aGlzIGRvY3VtZW50IGhhcyBubyBz ZWN1cml0eSBpc3N1ZXMgaW4gaXRzZWxmOyB0aGUgU2VjdXJpdHkNCkNvbnNpZGVyYXRpb25zIHNl Y3Rpb24gaXMgcmVhbGx5IGEgcm9hZCBtYXAgZm9yIHRoZSByZXN0IG9mIHRoZSBsZW1vbmFkZSB3 b3JrDQooYWxtb3N0IGNvbXBsZXRlZCkuIDxicj4NCjxicj4NCkNhbiB3ZSBsZWF2ZSB0aGUgZG9j dW1lbnQgYXMgaXMsIG9yIHNob3VsZCB3ZSBqdXN0IHNheSwgJnF1b3Q7dGhpcyBkb2N1bWVudA0K ZG9lcyBub3QgaW50cm9kdWNlIGFueSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBpdHNlbGYu IFNlZSB0aGUgcHJvdG9jb2wNCmRvY3VtZW50cyB0aGVtc2VsdmVzIGZvciBhbnkgc2VjdXJpdHkg aXNzdWVzLiZxdW90Oz8gT3VyIHByZWZlcmVuY2UgaXMgdG8gbGV0DQppdCBsaWUsIGJ1dCB3ZSBh cmUgb3BlbiB0byBzdWdnZXN0aW9ucy4gPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5b3VyIHJldmll dy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD4tLTxicj4NCkVyaWMgQnVyZ2VyPGJyPg0K PGJyPg0KU2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2U7IHNvcnJ5IGlmIHRlcnNlLiBBbGwgbW9i aWxlIHVzZXJzIG5lZWQgbGVtb25hZGUuIFNlZQ0KJmx0O2h0dHA6Ly93d3cuc3RhbmRhcmRzdHJh Y2suY29tL2lldGYvbGVtb25hZGUmZ3Q7IGZvciBtb3JlIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+ PC9wPg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxp Z246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIic+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWdu PWNlbnRlcj4NCg0KPC9zcGFuPjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIic+RnJvbTwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPjogU3RlZmFuDQpTYW50ZXNzb24gJmx0 O3N0ZWZhbnNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5EYXRlPC9iPjogVHVlLCAxMSBOb3Yg MjAwOCAxNDo1MzowMyArMDAwMDxicj4NCjxiPlRvPC9iPjogaWVzZ0BpZXRmLm9yZyZsdDtpZXNn QGlldGYub3JnJmd0OzsNCnNlY2RpckBpZXRmLm9yZyZsdDtzZWNkaXJAaWV0Zi5vcmcmZ3Q7OyBD aHJpcyBOZXdtYW4mbHQ7Y2hyaXMubmV3bWFuQHN1bi5jb20mZ3Q7Ow0KR2xlbm4gUGFyc29ucyZs dDtncGFyc29uc0Bub3J0ZWwuY29tJmd0OzsgRXJpYw0KQnVyZ2VyJmx0O2VidXJnZXJAc3RhbmRh cmRzdHJhY2suY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q8L2I+OiBTRUNESVIgUmV2aWV3OiBkcmFm dC1pZXRmLWxlbW9uYWRlLWFyY2hpdGVjdHVyZS0wNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+SSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZg0KdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBl ZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZw0KcHJvY2Vzc2VkIGJ5IHRo ZSBJRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0 aGUNCmJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMNCnNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+VGhpcyBk b2N1bWVudCBzcGVjaWZpZXMgdGhlIGFyY2hpdGVjdHVyZSBmb3INCm1vYmlsZSBlbWFpbCwgYXMg ZGVzY3JpYmVkIGJ5IHRoZSBPcGVuIE1vYmlsZSBBbGxpYW5jZSAoT01BKSwgdXNpbmcgSW50ZXJu ZXQNCk1haWwgcHJvdG9jb2xzLiZuYnNwOyBUaGlzIGFyY2hpdGVjdHVyZSB3YXMgYW4gaW1wb3J0 YW50IGNvbnNpZGVyYXRpb24gZm9yIG11Y2gNCm9mIHRoZSB3b3JrIG9mIHRoZSBMRU1PTkFERSAo RW5oYW5jZW1lbnRzIHRvIEludGVybmV0IGVtYWlsIHRvIFN1cHBvcnQgRGl2ZXJzZQ0KU2Vydmlj ZSBFbnZpcm9ubWVudHMpIHdvcmsgZ3JvdXAgaW4gdGhlIElFVEYuJm5ic3A7IFRoaXMgZG9jdW1l bnQgYWxzbw0KZGVzY3JpYmVzIGhvdyB0aGUgTEVNT05BREUgYXJjaGl0ZWN0dXJlIG1lZXRzIHRo ZSBPTUEncyByZXF1aXJlbWVudHMgZm9yIHRoZWlyDQpNb2JpbGUgRW1haWwgKE1FTSkgc2Vydmlj ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tVVM+R2VuZXJhbCBjb21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPkkgaGF2ZSBub3QgcmV2aWV3 ZWQgdGhlIHByZXNlbnRlZA0KYXJjaGl0ZWN0dXJlIGFzIHN1Y2guPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5UaGUgU2VjdXJpdHkg Y29uc2lkZXJhdGlvbiBvZiB0aGlzIGRvY3VtZW50DQppcyB2ZXJ5IHNob3J0IGFuZCBkb2VzIG5v dCBwcm92aWRlIG1lIHdpdGggdGhlIGJhc2ljIGluZm9ybWF0aW9uIEkgd291bGQgbGlrZQ0KdG8g ZmluZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTPlRoaXMgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBsaXN0cyBhIG51bWJlcg0Kb2Yg c2VjdXJpdHkgYXJlYXMgdGhhdCBtYXkgYXBwbHkgdG8gdGhlIGFyY2hpdGVjdHVyZSBhbmQgdGhl IHByb3RvY29scyB3aGVyZQ0KdGhlc2Ugc2VjdXJpdHkgaXNzdWVzIGFyZSBkZWFsdCB3aXRoLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVM+V2hhdCBJIHdvdWxkIGZpbmQgbW9yZSB1c2VmdWwgd291bGQgYmUgYW4NCmluZm9ybWF0aXZl IHRleHQgdGVsbGluZyBtZSBpZiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmllZCBpbiBUSElTIGRv Y3VtZW50DQppbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0eSBpc3N1ZXMgYW5kIHdoZXRoZXIgcmVz b2x1dGlvbnMgb2YgdGhvc2UgaXNzdWVzIGFyZQ0Kd2l0aGluIG9yIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1HQiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOm1hcm9vbic+U3RlZmFuIFNhbnRlc3Nvbjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1HQg0K c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzQwMDA0MCc+U2VuaW9yIFByb2dyYW0g TWFuYWdlcjwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQ7 Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjtjb2xvcjpuYXZ5Jz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzQwMDA0MCc+V2luZG93cyBTZWN1cml0eSwgU3RhbmRhcmRzPC9zcGFuPjwvYj48 c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+ DQo= --_000_9F11911AED01D24BAA1C2355723C3D321AB079AEC4EAEXMSGC332eu_-- --===============1253541546== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============1253541546==-- From secdir-bounces@ietf.org Wed Nov 12 03:48:49 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AAF63A68B2; Wed, 12 Nov 2008 03:48:49 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515443A68B2 for ; Wed, 12 Nov 2008 03:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+njP91NVXvq for ; Wed, 12 Nov 2008 03:48:47 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4E5783A6784 for ; Wed, 12 Nov 2008 03:48:47 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mACBmfPh022304 for ; Wed, 12 Nov 2008 13:48:45 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 13:48:35 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 13:48:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Nov 2008 13:48:35 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720243537F@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SecDir lunch on Tuesday Thread-Index: AclEvJhYQn0pNuZvQG6UukE0hEkNRQ== From: To: X-OriginalArrivalTime: 12 Nov 2008 11:48:35.0831 (UTC) FILETIME=[9868B870:01C944BC] X-Nokia-AV: Clean Subject: [secdir] SecDir lunch on Tuesday X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org We'll have the Security Directorate lunch on Tuesday as before; the room is Symphony III. As usual, bring your own lunch and we will discuss what's going on in the area and around the IETF. Best regards, Pasi & Tim _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Nov 12 23:03:01 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E870B3A692D; Wed, 12 Nov 2008 23:03:01 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC633A692D; Wed, 12 Nov 2008 23:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU6R4opnDS8a; Wed, 12 Nov 2008 23:02:58 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id E3E883A6879; Wed, 12 Nov 2008 23:02:57 -0800 (PST) Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.54.46.185) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 12 Nov 2008 23:02:58 -0800 Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.110.53]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.54.46.185]) with mapi; Wed, 12 Nov 2008 23:02:57 -0800 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "pasi.eronen@nokia.com" , Eric Rescorla , "jsalowey@cisco.com" , "mankin@psg.com" Date: Wed, 12 Nov 2008 23:02:53 -0800 Thread-Topic: Secdir review of draft-ietf-tls-des-idea-02.txt Thread-Index: AclFXdlkvzkuBYuLTwCMM+GX6n8j8Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-tls-des-idea-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2034624974==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============2034624974== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_F009AC6CE159924ABD1E8B51049B9B5C710EF4759CNAEXMSGC103re_" --_000_F009AC6CE159924ABD1E8B51049B9B5C710EF4759CNAEXMSGC103re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any= other last call comments. Feel free to forward to any appropriate forum. This document is a pro forma document written so that obsolete cryptographi= c suites could be removed from the new TLS 1.2 RFC (RFC 5246) while remaini= ng defined in the IANA registry for interoperability with existing systems.= It is proposed as informational, but might be eligible for a new category = of RFC: WCP (Worst Current Practice). All of the specified algorithms are l= isted as SHOULD NOT be implemented. I couldn't think of any improvements to suggest, even in a lame attempt at = humor. --Charlie --_000_F009AC6CE159924ABD1E8B51049B9B5C710EF4759CNAEXMSGC103re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I am reviewing this document as part of the security directorate's ongoing effor= t to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. = ; Document editors and WG chairs should treat these comments just like any ot= her last call comments. Feel free to forward to any appropriate forum.

 

This document is a pro forma document written so that obsolete cryptographic suites could be removed from the new TLS 1.2 RFC (RF= C 5246) while remaining defined in the IANA registry for interoperability wit= h existing systems. It is proposed as informational, but might be eligible fo= r a new category of RFC: WCP (Worst Current Practice). All of the specified algorithms are listed as SHOULD NOT be implemented.

 

I couldn’t think of any improvements to suggest,= even in a lame attempt at humor.

 

         =        --Charlie

--_000_F009AC6CE159924ABD1E8B51049B9B5C710EF4759CNAEXMSGC103re_-- --===============2034624974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============2034624974==-- From secdir-bounces@ietf.org Thu Nov 13 04:46:55 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E0B3A6920; Thu, 13 Nov 2008 04:46:55 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451983A6807 for ; Thu, 13 Nov 2008 01:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=3.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQAQvEyHidmt for ; Thu, 13 Nov 2008 01:43:04 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 29CD63A6872 for ; Thu, 13 Nov 2008 01:43:03 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAD9h4U4005054 for ; Thu, 13 Nov 2008 04:43:04 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAD9gxZD005051 for ; Thu, 13 Nov 2008 04:42:59 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id mAD9gpmo000404 for ; Thu, 13 Nov 2008 04:42:51 -0500 (EST) Received: from ms6.sony.co.jp (ms6.Sony.CO.JP [211.125.136.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 0D29CC2C92A for ; Thu, 13 Nov 2008 04:42:29 -0500 (EST) Received: from mta5.sony.co.jp (mta5.Sony.CO.JP [137.153.71.6]) by ms6.sony.co.jp (R8/Sony) with ESMTP id mAD9gQDG020804 for ; Thu, 13 Nov 2008 18:42:26 +0900 (JST) Received: from mta5.sony.co.jp (localhost [127.0.0.1]) by mta5.sony.co.jp (R8/Sony) with ESMTP id mAD9gQFq012814 for ; Thu, 13 Nov 2008 18:42:26 +0900 (JST) Received: from jptkyxim02.jp.sony.com (jptkyxim02.jp.sony.com [43.15.17.88]) by mta5.sony.co.jp (R8/Sony) with ESMTP id mAD9gQkD012811 for ; Thu, 13 Nov 2008 18:42:26 +0900 (JST) Received: from jptkyxwa03.jp.sony.com ([43.15.31.3]) by jptkyxim02.jp.sony.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 13 Nov 2008 18:42:26 +0900 Received: from [43.4.150.113] ([43.4.150.113]) by jptkyxwa03.jp.sony.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 13 Nov 2008 18:42:26 +0900 Message-ID: <491BF681.3060505@jp.sony.com> Date: Thu, 13 Nov 2008 18:42:25 +0900 From: actech User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alan DeKok References: <48D8F5C4.9020005@deployingradius.com> In-Reply-To: <48D8F5C4.9020005@deployingradius.com> X-OriginalArrivalTime: 13 Nov 2008 09:42:26.0039 (UTC) FILETIME=[22DFE070:01C94574] X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Thu, 13 Nov 2008 04:46:54 -0800 Cc: "secdir@mit.edu" , "avt@ietf.org" , "draft-ietf-avt-rtp-atrac-family@tools.ietf.org" , IESG IESG , actech@jp.sony.com, "avt-chairs@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-avt-rtp-atrac-family-18 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Discus: Alan, Thank you for comments and advise. > It may be useful to define a security profile whereby all data is > encrypted. Simple traffic analyis on the headers may be sufficient to > negate much of the benefits of encrypting only the data portion. Regarding on security consideration, necessary and sufficient guideline for ATRAC streaming are fully described in published RFC(3550, 3551). So we think it is better to simply put the reference to above RFCs, instead of describing complex information of security profile, confidentiality and authentication. All of your comments and advise other than above issue are acceptable for us, and we are now make the modification on our draft according to your comments. We will submit revised version in soon, if there are no problem. Regards, > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document defines a packet format to encapsulate ATRAC-formatted > audio data in RTP frames. > > Overall, the document is clear and unambiguous. The only security > review comments I have are for text in the "Security Considerations" > section. The discussion appears to worry more about audio quality than > packet decoding errors, or malicious insertion of incorrect audio. > > > Certain security precautions may be desired to protect > copyrighted material. > > I suggest deleting this sentence. The Security considerations is not > intended to discuss dissemination controls on data. > > ... Encryption of the payload header, > however, is not as neccessary, and in fact may not be preferable if > the information could be useful to some third party application. > > It may be useful to define a security profile whereby all data is > encrypted. Simple traffic analyis on the headers may be sufficient to > negate much of the benefits of encrypting only the data portion. > > ... As multi- > channel transmissions are contained in single encoded audio frames, > there is no concern for encryption will affect interleaving data. > > I am not sure what this means. "concern for encryption.." ? > > ... Transmitted data may be tampered or altered due to malicious > attempts, such as man-in-the-middle attacks. Such attacks may result > in depacketization and/or decoding errors that could decimate audio > quality. > > Concerns about audio quality are misplaced in a "Security > Considerations" section. MITM attacks may lead to *incorrect* audio > that never the less sounds "correct". > > As this payload format does not include its own means for sender > authentication and integrity protection, an external mechanism MUST > be used. > > Are there security profiles that can be defined? > > However, the chosen mechanism SHOULD protect more than just > the audio data bits. For example, to protect against > a man-in-the-middle attack, the payload header and RTP header SHOULD > be protected. > > This text likely belongs in the first paragraph of Section 9 (see above) > > ... Verification of the received encoded audio packets SHOULD be > performed so as to ensure a minimal level of audio quality. > > This text does not belong in a security considerations section. Audio > quality is irrelevant if protocol errors have causes buffer overflows > that allow an attacker to control either end of the connection. Correct > decoding of the packets is MORE important than audio quality. I suggest > moving this text to the body of the document, and creating requirements > that received packets MUST be verified, and improperly formatted packets > MUST be discarded. > > ... As a > most primitive implementation, if the receiver calculates a packet > size differing from the payload length based on data in the payload > header fields, the receiver SHOULD discard the packet. > > This suggestion may be too restrictive. If the UDP packet length is > longer than the RTP packet length, the packet can be accepted, but the > extra bytes MUST be ignored. Also, improperly encoded packets MUST be > discarded. > > Alan DeKok. > > > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Nov 13 08:28:50 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C929328C1C7; Thu, 13 Nov 2008 08:28:50 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024F028C1BE; Thu, 13 Nov 2008 08:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejqznJLaHffV; Thu, 13 Nov 2008 08:28:48 -0800 (PST) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by core3.amsl.com (Postfix) with ESMTP id 050D828C1BD; Thu, 13 Nov 2008 08:28:47 -0800 (PST) Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id mADGSLQo021911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Nov 2008 16:28:35 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: From: Kurt Zeilenga To: Cyrus Daboo , Chris Newman , Alexey Melnikov Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 08:28:21 -0800 X-Mailer: Apple Mail (2.929.2) Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] re-review of draft-daboo-imap-annotatemore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have re-reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I have no concerns with the latest revision. All of my prior concerns (with regard to earlier revisions) have been adequately addressed. -- Kurt _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Nov 13 17:31:57 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D8C3A67DF; Thu, 13 Nov 2008 17:31:57 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10523A6818 for ; Thu, 13 Nov 2008 17:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7IbehXX1XyU for ; Thu, 13 Nov 2008 17:31:56 -0800 (PST) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 182263A6781 for ; Thu, 13 Nov 2008 17:31:55 -0800 (PST) Received: from pgpdev.ihtfp.org (c-76-109-66-143.hsd1.fl.comcast.net [76.109.66.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 2D2D2BD8464; Thu, 13 Nov 2008 20:31:56 -0500 (EST) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id mAE1VsYs011395; Thu, 13 Nov 2008 20:31:54 -0500 To: secdir@ietf.org From: Derek Atkins User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Date: Thu, 13 Nov 2008 20:31:54 -0500 Message-ID: MIME-Version: 1.0 Cc: Bruce Schneier Subject: [secdir] Dinner with Bruce Schneier in MPLS on Sunday X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hey all, Bruce Schneier lives in Minneapolis. I was talking with him about a security area dinner, and we've settled on Sunday Evening. He can make reservations at a local restaurant and we can all meet up and talk and exchange ideas. If you'd like to join our merry gang please let us know so that we can get an accurate count. The plan is to meet at the IETF Registration Desk after the Welcome Reception (1900 Sunday) and then head to dinner from there. See you all Sunday, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Nov 13 17:57:10 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14AAC3A6808; Thu, 13 Nov 2008 17:57:10 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139EB3A6781; Thu, 13 Nov 2008 17:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK3xrLFObK-L; Thu, 13 Nov 2008 17:57:07 -0800 (PST) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by core3.amsl.com (Postfix) with ESMTP id 1FF023A657C; Thu, 13 Nov 2008 17:57:03 -0800 (PST) Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id mAE1v0nT061694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Nov 2008 01:57:01 GMT (envelope-from kurt.zeilenga@isode.com) Message-Id: From: Kurt Zeilenga To: cheshire@apple.com, marc@apple.com, townsley@cisco.com Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 17:56:59 -0800 X-Mailer: Apple Mail (2.929.2) Cc: IETF discussion list , secdir@ietf.org Subject: [secdir] secdir review of draft-cheshire-dnsext-dns-sd X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1685765362==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============1685765362== Content-Type: multipart/alternative; boundary=Apple-Mail-27--787483041 --Apple-Mail-27--787483041 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The security consideration section of this document is (in its entirety): > 18. Security Considerations > DNSSEC [RFC 2535] should be used where the authenticity of > information is important. Since DNS-SD is just a naming and usage > convention for records in the existing DNS system, it has no > specific additional security requirements over and above those that > already apply to DNS queries and DNS updates. I find this inadequate. With regard to 'authenticity of information', the section doesn't discussion when authenticity of information might be important, nor does it discuss risks of relying on information in which the authenticity is not assured. While it may well be true that this use of DNS has 'no specific additional security requirements', there are likely many DNS security issues which apply here and should be discussed here (possibly with reference to DNS specifications providing more general discussion of the security issues). In particular, this document recommends additional RRs be generated (section 13) but fails to discussion security implications and concerns with such generation. There likely should be some discussion of considerations as when this very public discovery mechanism should be used, as opposed to a discovery mechanism which only provides discovery to authorized entities. I think that portions of this document could be viewed as inappropriately supplanting per-protocol specifications of DNS SRV handling, and possibly RFC 2782 itself. I think the IANA registration would be better specified on the standard track, or in a BCP. I also think some of the market drivel (Section 21) should be removed. I would much prefer this to be reworked as a update or replacement of RFC 2782. I've read a number of reviews posted on the IETF list. I have general concerns similar to those posted by Dave Cridland and Ben Campbell. In short, this document seems to need more work. -- Kurt --Apple-Mail-27--787483041 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have reviewed this document = as part of the security directorate's ongoing effort to review all IETF = documents being processed by the IESG.  These comments were written = primarily for the benefit of the security area directors.  Document = editors and WG chairs should treat these comments just like any other = last call comments.

The security consideration = section of this document is (in its = entirety):
18. Security =
Considerations

I've =
read a number of reviews posted on the IETF list.  I have general =
concerns similar to those posted by Dave Cridland and Ben Campbell. =
 In short, this document seems to need more =
work.

-- =
Kurt
=

--Apple-Mail-27--787483041--

--===============1685765362==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir

--===============1685765362==--


From secdir-bounces@ietf.org  Thu Nov 13 21:49:08 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C6E103A6900;
	Thu, 13 Nov 2008 21:49:08 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7F9583A6901
	for ; Thu, 13 Nov 2008 21:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 6px3XHW36ThP for ;
	Thu, 13 Nov 2008 21:49:06 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41])
	by core3.amsl.com (Postfix) with ESMTP id 4E82A3A68DA
	for ; Thu, 13 Nov 2008 21:49:05 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1])
	by fledge.watson.org (8.14.3/8.14.2) with ESMTP id mAE5n5u0081762
	for ; Fri, 14 Nov 2008 00:49:05 -0500 (EST)
	(envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost)
	by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id
	mAE5n38q081757
	for ; Fri, 14 Nov 2008 00:49:04 -0500 (EST)
	(envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 14 Nov 2008 00:49:03 -0500 (EST)
From: Samuel Weiler 
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: 
User-Agent: Alpine 1.10 (BSF 962 2008-03-14)
MIME-Version: 1.0
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0
	(fledge.watson.org [127.0.0.1]);
	Fri, 14 Nov 2008 00:49:05 -0500 (EST)
Subject: [secdir] More assignments for Nov 25th (post-IETF)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

A few more assignments since my note on Tuesday (to Meadows, Melnikov, 
Murphy, Narayanan, and Cain).

Magnus Nystrom is next in the rotation.

Review instructions and related resources are at:
    http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam

For telechat, December 4th

Derek Atkins                   T  draft-ietf-6man-reserved-iids-01
Charles Clancy                 T  draft-ietf-l1vpn-ospfv3-auto-discovery-02
Lakshminath Dondeti            T  draft-ietf-monami6-multiplecoa-10
Donald Eastlake                T  draft-ietf-mpls-ldp-igp-sync-03
Tobias Gondrom                 T  draft-ietf-pim-rpf-vector-06
Tero Kivinen                   T  draft-igoe-secsh-aes-gcm-00
Marcus Leech                   T  draft-housley-internet-draft-sig-file-06
Vidya Narayanan                T  draft-ietf-lemonade-imap-notify-07
Susan Thomson                  T  draft-ietf-nfsv4-minorversion1-dot-x-09
Hannes Tschofenig              T  draft-ietf-nfsv4-pnfs-block-09
Sean Turner                    T  draft-ietf-nfsv4-pnfs-obj-09
Sam Weiler                     T  draft-housley-iesg-rfc3932bis-05
Nico Williams                  T  draft-ietf-nfsv4-minorversion1-26
Larry Zhu                      T  draft-arkko-arp-iana-rules-01

Last calls and special requests:

Rob Austein                       draft-ietf-dime-qos-parameters-07
Richard Barnes                    draft-ietf-calsify-rfc2445bis-09
Pat Cain                        R draft-ietf-ipdvb-sec-req-09
Pat Cain                          draft-ietf-geopriv-pdif-lo-profile-13
Ran Canetti                       draft-ietf-kitten-gssapi-channel-bindings-05
Alan DeKok                        draft-ietf-mext-nemo-v4traversal-06
Shawn Emery                       draft-ietf-nfsv4-rfc1831bis-10
Stephen Farrell                   draft-ietf-ospf-lls-05
Phillip Hallam-Baker              draft-ietf-radext-design-05
Steve Hanna                       draft-ietf-radext-management-authorization-06
David Harrington                  draft-ietf-sip-saml-05
Sam Hartman                       draft-ietf-smime-3850bis-08
Paul Hoffman                      draft-ietf-smime-3851bis-08
Love Hornquist-Astrand            draft-ietf-tcpm-rfc4138bis-04
Jeffrey Hutzelman                 draft-ietf-tcpm-tcp-uto-09
Scott Kelly                       draft-ietf-tsvwg-rsvp-proxy-approaches-06
Stephen Kent                      draft-ietf-tsvwg-rsvp-proxy-proto-07
Julien Laganier                   draft-ietf-softwire-mesh-framework-05
Julien Laganier                   draft-ietf-softwire-encaps-ipsec-01
Julien Laganier                   draft-irtf-asrg-dnsbl-07
Marcus Leech                      draft-ietf-dnsext-forgery-resilience-07
Chris Lonvick                     draft-kucherawy-sender-auth-header-17
Catherine Meadows                 draft-ietf-speechsc-mrcpv2-17
Catherine Meadows                 draft-ietf-l2tpext-tdm-06
Alexey Melnikov                   draft-ietf-pce-pcep-xro-06
Alexey Melnikov                   draft-ietf-tsvwg-admitted-realtime-dscp-05
Sandy Murphy                      draft-ietf-mpls-mpls-and-gmpls-security-framework-04
Sandy Murphy                      draft-ietf-roll-urban-routing-reqs-02
Vidya Narayanan                   draft-ietf-sip-saml-05 
Eric Rescorla                     draft-wing-sipping-srtp-key-04
Carl Wallace                      draft-ietf-isis-hmac-sha-06
Sam Weiler                        draft-chown-v6ops-rogue-ra-02
Brian Weis                        draft-ietf-isis-wg-extlsp-03
Nico Williams                     draft-ietf-v6ops-ra-guard-01
Larry Zhu                         draft-thaler-v6ops-teredo-extensions-02
Glen Zorn                         draft-hoffman-dac-vbr-04
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Fri Nov 14 16:29:40 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0341328C15A;
	Fri, 14 Nov 2008 16:29:40 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2B4543A68D4
	for ; Fri, 14 Nov 2008 06:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id MwJfNQRNnsWf for ;
	Fri, 14 Nov 2008 06:29:18 -0800 (PST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
	by core3.amsl.com (Postfix) with ESMTP id 1AA453A67E9
	for ; Fri, 14 Nov 2008 06:29:17 -0800 (PST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAEETH0h013071
	for ; Fri, 14 Nov 2008 09:29:17 -0500
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAEET8cs013065
	for ; Fri, 14 Nov 2008 09:29:12 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	mAEET1xQ013958
	for ; Fri, 14 Nov 2008 09:29:03 -0500 (EST)
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87])
	by mit.edu (Spam Firewall) with ESMTP id 19876124871E
	for ; Fri, 14 Nov 2008 09:27:57 -0500 (EST)
Received: from 68-27-237-112.pools.spcsdns.net (localhost [127.0.0.1])
	by mail.serendipity.cx (Postfix) with ESMTP id C553F1F9E;
	Fri, 14 Nov 2008 06:28:55 -0800 (PST)
Message-Id: 
From: Aaron Stone 
To: Carl Wallace 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 14 Nov 2008 06:27:11 -0800
References: 
X-Mailer: Apple Mail (2.929.2)
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
X-Mailman-Approved-At: Fri, 14 Nov 2008 16:29:38 -0800
Cc: aaron@serendipity.palo-alto.ca.us, secdir@mit.edu, sieve3@matthew.elvey.com,
	iesg@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-sieve-refuse-reject-07
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

My apologies for the extremely delayed reply to this review. I've at  
long last cleared enough time to get into the grist of the comments on  
this draft and prepare revision -08.

On Aug 14, 2008, at 5:51 AM, Carl Wallace wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the  
> IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> The draft refines the specification of the "reject" action and defines
> the new "ereject" action.  The "reject" action was originally  
> defined in
> RFC3028 but was omitted from its successor, RFC 5228.  Comments,
> questions and nits are below.
>
> - Section 2.1 references "return-path verification".  This is not
> defined in this specification (nor in any of the references that I
> checked).  Given that discard is a consequence, this should be defined
> or re-worded.  Is this the only reason why the message should be
> discarded?  It's a bit strange that the first and third items in the
> list are described more fully in subsections but the second item is  
> not.
>

I've searched for a definition of return-path verification, and cannot  
find one either. It is a well-known technique (or set of techniques,  
really) and that's probably why this hasn't stuck out among readers in  
the email community.

On the basis of being well-known, I think that we can leave this  
without a strong definition. I would be happy to add a weak definition  
that suggests a couple of techniques that might be employed for return- 
path verification.

>
> - The first sentence of Section 2.1.1 states "implementations that are
> able to reject messages at the SMTP/LMTP level MUST do so and SHOULD  
> use
> the 550 response code".  This doesn't allow for cases where protocol
> level rejection cannot be performed.  This MUST should be a SHOULD  
> or be
> followed by a list of exceptional cases.  As a MUST, it is  
> inconsistent
> with the SHOULD in section 2 that covers the list of preferred  
> actions.
>

I believe that the rest of the text in that paragraph makes it clear  
that the meaning of "able" in this context is both "has code to do  
protocol level rejection" and "is not in a situation where protocol  
rejection isn't possible" (such as SMTP with multiple recipients.

We might be splitting hairs on the semantics of "able" vs. "can",  
wondering who shall slay whom ;-)

I think the text is ok as-is, but if there's disagreement I can  
clarify it.

>
> - The first paragraph of section 2.3 is confusing.  Why is a user
> interface allowed to silently upgrade from reject to ereject but other
> implementations are not?  Are silent downgrades OK, i.e., for cases
> where ereject is not supported?
>

The idea is that a UI might have a check box labeled "Reject the  
message" and then will translate that check box into a sieve script.  
That translation might be to 'reject' in version X, but in version Y  
might be 'ereject'. We want to allow and encourage such a transition.

I don't see a problem with silent downgrade and would be comfortable  
adding text for it.

>
> - Reason text uses UTF-8 to align an SMTP language extension spec.   
> The
> reason text value may be inappropriate even if the client and server
> negotiate the use of an SMTP extension (i.e., a different language may
> be used by the client/server).  Should UTF-8 be used here without a
> normative reference to support it?
>

The language was constructed to work with whatever standard ends up  
being used for UTF-8 in SMTP, and also to permit vendor specific  
extensions to qualify. A vendor might have their Sieve implementation  
on an LMTP server that receives connections from their own SMTP  
server. If they build a UTF-8 extension so that the message can at  
least be pushed from the LMTP server to the SMTP server in clear  
UTF-8, we want that to be allowed and encouraged.

I see your point, though, that the language in the document allows a  
situation where a non-ASCII non-UTF-8 extension has been negotiation.  
Under such a circumstance, the transmission of the UTF-8 text is  
permitted, even though the channel may be ill suited to it. I believe  
that it is sufficiently obvious that UTF-8 over a non-ASCII non-UTF-8  
channel is not ok.


> - There are some unexpanded acronyms, minimally MUA and MTA.

MUA and MTA are on the RFC editor's list of WKA (Well Known Acronyms)  
for email documents, so it's safe to leave them unexpanded.


Many thanks,
Aaron
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Sun Nov 16 12:30:58 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4E1333A694F;
	Sun, 16 Nov 2008 12:30:58 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 40F163A694F
	for ; Sun, 16 Nov 2008 12:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 
	RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id U9cLdb0a6XYs for ;
	Sun, 16 Nov 2008 12:30:56 -0800 (PST)
Received: from kilo.rtfm.com (unknown [130.129.95.170])
	by core3.amsl.com (Postfix) with ESMTP id 6DD3E3A6358
	for ; Sun, 16 Nov 2008 12:30:56 -0800 (PST)
Received: from kilo-2.local (localhost [127.0.0.1])
	by kilo.rtfm.com (Postfix) with ESMTP id 0832675768E;
	Sat, 15 Nov 2008 13:40:31 -0800 (PST)
Date: Sat, 15 Nov 2008 13:40:19 -0800
From: Eric Rescorla 
To: Derek Atkins 
In-Reply-To: 
References: 
	
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20081115214031.0832675768E@kilo.rtfm.com>
Cc: secdir@ietf.org
Subject: Re: [secdir] Dinner with Bruce Schneier in MPLS on Sunday
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

At Sat, 15 Nov 2008 13:39:12 -0800,
Eric Rescorla wrote:
> At Thu, 13 Nov 2008 20:31:54 -0500,
> Derek Atkins wrote:
> > Bruce Schneier lives in Minneapolis.  I was talking with him about
> > a security area dinner, and we've settled on Sunday Evening.  He
> > can make reservations at a local restaurant and we can all meet
> > up and talk and exchange ideas.
> > 
> > If you'd like to join our merry gang please let us know so that
> > we can get an accurate count.  The plan is to meet at the IETF
> > Registration Desk after the Welcome Reception (1900 Sunday) and
> > then head to dinner from there.
> 
> I'm interested. Lisa not.

Also, a moron who doesn't know how to trim Cc: lines.

-Ekr
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Sun Nov 16 12:37:08 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2F7983A697B;
	Sun, 16 Nov 2008 12:37:08 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 744F73A697B
	for ; Sun, 16 Nov 2008 12:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.33
X-Spam-Level: 
X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.165, 
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 
	RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id pdPpr1Ic1l33 for ;
	Sun, 16 Nov 2008 12:37:06 -0800 (PST)
Received: from kilo.rtfm.com (unknown [130.129.95.170])
	by core3.amsl.com (Postfix) with ESMTP id B66B63A694F
	for ; Sun, 16 Nov 2008 12:37:06 -0800 (PST)
Received: from kilo-2.local (localhost [127.0.0.1])
	by kilo.rtfm.com (Postfix) with ESMTP id 9A0A2757664;
	Sat, 15 Nov 2008 13:39:22 -0800 (PST)
Date: Sat, 15 Nov 2008 13:39:12 -0800
From: Eric Rescorla 
To: Derek Atkins 
In-Reply-To: 
References: 
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20081115213922.9A0A2757664@kilo.rtfm.com>
Cc: Bruce Schneier , secdir@ietf.org
Subject: Re: [secdir] Dinner with Bruce Schneier in MPLS on Sunday
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

At Thu, 13 Nov 2008 20:31:54 -0500,
Derek Atkins wrote:
> Bruce Schneier lives in Minneapolis.  I was talking with him about
> a security area dinner, and we've settled on Sunday Evening.  He
> can make reservations at a local restaurant and we can all meet
> up and talk and exchange ideas.
> 
> If you'd like to join our merry gang please let us know so that
> we can get an accurate count.  The plan is to meet at the IETF
> Registration Desk after the Welcome Reception (1900 Sunday) and
> then head to dinner from there.

I'm interested. Lisa not.

-Ekr
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Sun Nov 16 14:05:27 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B319D3A69D1;
	Sun, 16 Nov 2008 14:05:27 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 542E43A6983
	for ; Sun, 16 Nov 2008 14:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id RJA8Mrw1V0hp for ;
	Sun, 16 Nov 2008 14:05:25 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152])
	by core3.amsl.com (Postfix) with SMTP id 445C33A69A6
	for ; Sun, 16 Nov 2008 14:05:25 -0800 (PST)
Received: (qmail 28452 invoked by uid 0); 16 Nov 2008 22:05:17 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (130.129.31.166)
	by woodstock.binhost.com with SMTP; 16 Nov 2008 22:05:17 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 16 Nov 2008 17:05:19 -0500
To: "Stephen Hanna" 
From: Russ Housley 
In-Reply-To: 
References: 
Mime-Version: 1.0
Message-Id: <20081116220525.445C33A69A6@core3.amsl.com>
Cc: ekr@rtfm.com, msalter@restarea.ncsc.mil, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-rescorla-tls-suiteb-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Steve:

Thanks for the review.

>I have reviewed this document as part of the security directorate's
>ongoing effort to review all IETF documents being processed by the
>IESG.  These comments were written primarily for the benefit of the
>security area directors.  Document editors and WG chairs should treat
>these comments just like any other last call comments. I apologize
>for the tardiness of these comments.
>
>This document provides a brief overview of Suite B cryptography
>and two profiles with specific requirements that TLS servers and
>clients can meet in order to satisfy the Suite B requirements
>while retaining some backward compatibility with older code,
>if desired.
>
>Before reading this document, I was not really familiar with the
>Suite B requirements. The document provided a clear and concise
>introduction to the topic with references to more information.
>
>The requirements listed in the document seem to meet the implied goal
>of ensuring secure interoperation between Suite B implementations
>while allowing for less secure interoperation with older code.
>
>I do not have any major concerns with this document. I wonder
>about the following text in section 4 (in the requirements on
>clients implementing the Suite B transitional profile):
>
>    o  A Suite B transitional TLS version 1.1 or earlier client MUST
>       offer one cipher suite for each supported security level.
>
>This sounds like the client MUST offer only one cipher suite
>for each supported security level, presumably the cipher suites
>mentioned in the next two sentences. Actually, I think it is
>permitted for such a client to offer other cipher suites in
>order to achieve interoperability with non-Suite B compliant
>servers, as mentioned in the next bullet. Therefore, I suggest
>that the text quoted above be changed to something like this:
>
>    o  A Suite B transitional TLS version 1.1 or earlier client MUST
>       offer at least the cipher suites described in the next two
>       sentences for each supported security level.

I suggest:

    A Suite B transitional TLS version 1.1 or earlier client MUST offer
    the cipher suite for the 128 bit security level, the cipher suite for
    the 192 bit security level, or both.   For the 128 bit security level,
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MUST be offered in the
    ClientHello message.  For the 192 bit security level,
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MUST be offered in the
    ClientHello message.  One of these cipher suites MUST be the first
    (most preferred) cipher suite in the ClientHello message.

>A client that does offer many cipher suites in order to achieve
>interoperability with non-Suite B compliant servers is subject
>to a downgrade attack. A similar vulnerability exists for servers
>that wish to interoperate with non-Suite B compliant clients.
>Although this threat is obvious to skilled practioners, I think
>that it should be mentioned in the Security Considerations
>section of this document since it is a significant vulnerability
>associated with the recommendations contained in this document.

Due to the hash that is computed over the entire handshake, a 
man-in-the-middle cannot remove cipher suites from the offer without 
being detected.  However, if a TLS client offers many cipher suites 
in order to achieve
interoperability with non-Suite B compliant servers, then the client 
is subject to a TLS server selecting the least secure that is 
offered.  The TLS server gets to do the picking from the list offered 
by the TLS client, so I am do not see the "similar vulnerability."

>I did notice two minor errors in the document. In the last bullet
>of the introduction, "An transitional" should be "A transitional".
>And just before the text quoted above, the word "and" is missing
>from the preceding sentence. That sentence should read as follows:
>
>    For a client to implement the Suite B transitional profile, it MUST
>    implement TLS version 1.1 or earlier and the following cipher suite
>    rules apply:

I fixed these editorial problems.

>To summarize, I am not an expert in Suite B cryptography but
>I think that this document is beneficial and should be approved.
>However, the shortcomings that I have pointed out should be
>corrected before publication.

Thanks.

Russ 

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Mon Nov 17 08:39:16 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 51D1828C19D;
	Mon, 17 Nov 2008 08:39:16 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B882B28C19D;
	Mon, 17 Nov 2008 08:39:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vpTQu4XhoShV; Mon, 17 Nov 2008 08:39:13 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1])
	by core3.amsl.com (Postfix) with ESMTP id 71E0C28C19C;
	Mon, 17 Nov 2008 08:39:13 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1])
	by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mAHGd95l020163
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Nov 2008 18:39:09 +0200 (EET)
Received: (from kivinen@localhost)
	by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAHGd9AC022647;
	Mon, 17 Nov 2008 18:39:09 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen@iki.fi using -f
MIME-Version: 1.0
Message-ID: <18721.40493.335603.386542@fireball.kivinen.iki.fi>
Date: Mon, 17 Nov 2008 18:39:09 +0200
From: Tero Kivinen 
To: draft-igoe-secsh-aes-gcm@tools.ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 7 min
X-Total-Time: 6 min
Cc: ietf-ssh@netbsd.org, iesg@ietf.org, secdir@ietf.org
Subject: [secdir] Review of draft-igoe-secsh-aes-gcm-00.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document describes how to use combined mode aes-gcm ciphers in the
secure shell. I think this document have several problems:


1) The draft does not define how the per encryption IV is defined. I
   assume it is some kind of counter with most likely initial value
   and fixed part taken from the appropriate IV generated by the secsh
   key derivation part, but also things like byte order of the counter
   etc needs to be defined. RFC 5116 provides just generic
   instructions for the nonce generation (generation of distinct
   nonces for each operation for given key) in section 3.1 and then
   provides recommended format for the nonce in section 3.2, and then
   there is another format for the nonce in section 3.2.1, but nothing
   in this document says which format is used.

2) This is first combined mode cipher for the secsh, so it should also
   provide information required to support combined mode ciphers in
   secsh. For example it should say that combined mode encryption is
   run only once and what key it is using (most likely the encryption
   key from section 7.2 from RFC 4253 etc). It also needs to say that
   mac generation DOES NOT follow section 6.4 of RFC 4253 (i.e. no
   MAC(key, sequence_number || unencrypted_packet)).

3) I am not sure if there is need adding sequence_number to the
   authenticated data of the combined mode. That sequence_number is
   added to the mac of the normal secsh modes, but as I think the
   aes-gcm mode will provide same protection by using the IV in a
   format of counter, but I am not sure if that is enough. At least it
   should be mentioned why it is not needed.

4) Section 7 says that it is "SHOULD" to use same aead-aes-*-gcm-ssh
   for both confidentiality and data integrity mechanism. That implies
   that it would be valid to use for example 3des as encryption
   algorithm and aead-aes-128-gcm-ssh as integrity algorithm. This
   causes few problems, as both of those algorithms require IV, thus
   the draft needs to defined how the Initial IV of the section 7.2
   RFC 4253 needs to be splitted between 3des IV and
   aead-aes-128-gcm-ssh IV. Another example would be that if someone
   decides to use aead-aes-256-gcm-ssh as encryption algorithm and
   aead-aes-128-gcm-ssh for the integrity then the aes-gcm needs to be
   run twice, and now the key for the aead-aes-256-gcm-ssh is taken
   from encryption key and the key for the aead-aes-128-gcm-ssh is
   taken from the integrity key (and the separate IV for both needs to
   be taken from Initial IV field). I would suggest way mandate that
   same aead-aes-*-gcm-ssh algorithm MUST be selected for encryption
   and integrity algorithms (perhaps with only one exception when
   using none encryption and aead-aes-*-gcm-ssh as integrity
   algorithm).

5) Next question then if encryption and integrity algorithms happen to
   be same combined mode ciphers (in case we keep "SHOULD" in point 4,
   and allow mixing different combined mode ciphers for both
   encryption and integrity alrogithms), does that still mean that we
   need to run the aes-gcm twice with different IVs and keys
   (encryption key and integrity key)? My guess is that you do NOT
   want to run it twice, but you only want to run it once using the
   encryption key and one Initial IV and use output of that for both
   encryption and mac.

6) This should have reference to the RFC 4253, as that is the actual
   document using the algorithms, and this really actually modifies
   that documents at least from mac generation part. Also the question
   is that as this extends standard track document with informational
   document, that does not just define new ciphers, but also changes
   the base document, should this document be on the standard track
   also? 

In general I think this document requires still quite a lot of more
text to describe how to use combined mode ciphers in the secsh. Bit
like we needed to have much more description in the RFC 5282 when the
AEAD modes where defined to be used in the IKEv2 SAs (I do not think
secsh needs that much text as RFC5282 as secsh case is simplier, but
it still needs something).
-- 
kivinen@iki.fi
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Tue Nov 18 09:11:37 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B543828C22A;
	Tue, 18 Nov 2008 09:11:37 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id F04B128C24B
	for ; Tue, 18 Nov 2008 09:11:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level: 
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id bCq63+ysFeEd for ;
	Tue, 18 Nov 2008 09:11:36 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134])
	by core3.amsl.com (Postfix) with ESMTP id 16DA428C22A
	for ; Tue, 18 Nov 2008 09:10:50 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com
	[10.160.244.31])
	by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
	mAIHAJFM009151 for ; Tue, 18 Nov 2008 11:10:47 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Tue, 18 Nov 2008 19:10:43 +0200
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Tue, 18 Nov 2008 19:10:43 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 18 Nov 2008 19:10:18 +0200
Message-ID: <1696498986EFEC4D9153717DA325CB72025141A0@vaebe104.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SecDir lunch on Tuesday
Thread-Index: AclEvJhYQn0pNuZvQG6UukE0hEkNRQE4tGNg
From: 
To: 
X-OriginalArrivalTime: 18 Nov 2008 17:10:43.0670 (UTC)
	FILETIME=[972D6760:01C949A0]
X-Nokia-AV: Clean
Subject: Re: [secdir] SecDir lunch on Tuesday
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

A reminder about our lunch: the Symphony III room is on the 
2nd floor, end of corridor past the terminal room. 

The lobby coffee shop might sell something useful; there are also 
several places that sell sandwiches (etc.) on the skyway (towards
International Centre/AT&T Building).

Best regards,
Pasi 

> -----Original Message-----
> From: Eronen Pasi (Nokia-NRC/Helsinki) 
> Sent: 12 November, 2008 13:49
> To: 'secdir@ietf.org'
> Subject: SecDir lunch on Tuesday
> 
> 
> We'll have the Security Directorate lunch on Tuesday as before;
> the room is Symphony III.
> 
> As usual, bring your own lunch and we will discuss what's
> going on in the area and around the IETF.
> 
> Best regards,
> Pasi & Tim
> 
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Tue Nov 18 10:23:57 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D3CFE3A682E;
	Tue, 18 Nov 2008 10:23:57 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B92D23A682E
	for ; Tue, 18 Nov 2008 10:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.227
X-Spam-Level: 
X-Spam-Status: No, score=-4.227 tagged_above=-999 required=5 tests=[AWL=2.372, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id P8BY0d-Rf6wQ for ;
	Tue, 18 Nov 2008 10:23:56 -0800 (PST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
	by core3.amsl.com (Postfix) with ESMTP id DE9473A6808
	for ; Tue, 18 Nov 2008 10:23:55 -0800 (PST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAIINsHF027799
	for ; Tue, 18 Nov 2008 13:23:54 -0500
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAIINp8h027762
	for ; Tue, 18 Nov 2008 13:23:51 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	mAIINi3R017944
	for ; Tue, 18 Nov 2008 13:23:45 -0500 (EST)
Received: from smtp108.biz.mail.mud.yahoo.com (smtp108.biz.mail.mud.yahoo.com
	[68.142.201.177])
	by mit.edu (Spam Firewall) with SMTP id 30C051251DC9
	for ; Tue, 18 Nov 2008 13:23:23 -0500 (EST)
Received: (qmail 91752 invoked from network); 18 Nov 2008 18:23:23 -0000
Received: from unknown (HELO Wylie) (turners@130.129.29.26 with login)
	by smtp108.biz.mail.mud.yahoo.com with SMTP; 18 Nov 2008 18:23:22 -0000
X-YMail-OSG: AmSFeBkVM1n9FPecTe6NumtMKXLkunT013Bwlo6BPYSKOpIcGWerrrDC936gUXbnyqDuKa.RInSHmh8DVXUT9j.uhFyObXeL4yAERlMNTmFu8iRpEy5S95vQstJ1cVkHRZXRovmzAyO2XCofGdEngS_Odl.Dw2t5sgMi46fd
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." 
To: "secdir" , , ,
	, , , 
	
Date: Tue, 18 Nov 2008 12:22:58 -0600
Organization: IECA, Inc.
Message-ID: 
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AclJqq7v8mzupu+oSOSZHi7CcnBRMg==
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Subject: [secdir]  review of draft-ietf-nfsv4-pnfs-obj-09.txt
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

I premise this review with the following: a) I'm not an NFS expert and I
don't play one on TV or on YouTube b) I did actually skim the 605-page base
document to try to get a little smarter on NFS (but I'm not sure how much
smarter).

I think the document is well written and the security considerations section
addresses the questions/concerns I thought of.

Editorial nits:

Section 2.1.2: r/Pnfs_osd_version/pnfs_osd_version4
Ref [5]/[7]: Authors instead of companies?

spt

_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Wed Nov 19 11:17:57 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BEC603A69B5;
	Wed, 19 Nov 2008 11:17:57 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0405A28C0CE
	for ; Wed, 19 Nov 2008 10:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id q4poMFnlJqNI for ;
	Wed, 19 Nov 2008 10:57:11 -0800 (PST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
	by core3.amsl.com (Postfix) with ESMTP id 168E83A6BB6
	for ; Wed, 19 Nov 2008 10:57:10 -0800 (PST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAJIv9Om021973
	for ; Wed, 19 Nov 2008 13:57:09 -0500
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAJIv5wR021970
	for ; Wed, 19 Nov 2008 13:57:06 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	mAJIv0HP015040
	for ; Wed, 19 Nov 2008 13:57:00 -0500 (EST)
Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162])
	by mit.edu (Spam Firewall) with ESMTP id D9C5D124869E
	for ; Wed, 19 Nov 2008 13:56:39 -0500 (EST)
Received: from daytona.int.panasas.com ([172.17.28.41]) by
	laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Wed, 19 Nov 2008 10:55:15 -0800
Received: from fs1.bhalevy.com ([172.17.28.113]) by daytona.int.panasas.com
	with Microsoft SMTPSVC(6.0.3790.3959); 
	Wed, 19 Nov 2008 13:55:13 -0500
Message-ID: <49246163.90707@panasas.com>
Date: Wed, 19 Nov 2008 20:56:35 +0200
From: Benny Halevy 
User-Agent: Thunderbird 3.0a1 (X11/2008050714)
MIME-Version: 1.0
To: "Turner, Sean P." , lars.eggert@nokia.com
References: 
In-Reply-To: 
X-OriginalArrivalTime: 19 Nov 2008 18:55:13.0997 (UTC)
	FILETIME=[5AFF1FD0:01C94A78]
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
X-Mailman-Approved-At: Wed, 19 Nov 2008 11:17:56 -0800
Cc: magnus.westerlund@ericsson.com, secdir , welch@panasas.com,
	jimz@panasas.com, iesg@ietf.org, Benny Halevy 
Subject: Re: [secdir] review of draft-ietf-nfsv4-pnfs-obj-09.txt
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Sean, many thanks for your review and comments.
I agree with both comments and corrected them locally.

Sean/Lars, should I just submit an updated draft now,
or should I wait to see if there are any more comments
from the upcoming discussion planned for 2008-12-06?

Benny

On Nov. 18, 2008, 20:22 +0200, "Turner, Sean P."  wrote:
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> I premise this review with the following: a) I'm not an NFS expert and I
> don't play one on TV or on YouTube b) I did actually skim the 605-page base
> document to try to get a little smarter on NFS (but I'm not sure how much
> smarter).
> 
> I think the document is well written and the security considerations section
> addresses the questions/concerns I thought of.
> 
> Editorial nits:
> 
> Section 2.1.2: r/Pnfs_osd_version/pnfs_osd_version4
> Ref [5]/[7]: Authors instead of companies?
> 
> spt
> 
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Wed Nov 19 11:58:09 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CD16F28C1D0;
	Wed, 19 Nov 2008 11:58:09 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C64943A6B87
	for ; Wed, 19 Nov 2008 11:58:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id a3GMLSmnI6dk for ;
	Wed, 19 Nov 2008 11:58:07 -0800 (PST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
	by core3.amsl.com (Postfix) with ESMTP id C9D393A6782
	for ; Wed, 19 Nov 2008 11:58:07 -0800 (PST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAJJw6Ka031257
	for ; Wed, 19 Nov 2008 14:58:06 -0500
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAJJw584031254
	for ; Wed, 19 Nov 2008 14:58:06 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	mAJJw0qb020868
	for ; Wed, 19 Nov 2008 14:58:00 -0500 (EST)
Received: from smtp106.biz.mail.mud.yahoo.com (smtp106.biz.mail.mud.yahoo.com
	[68.142.200.254])
	by mit.edu (Spam Firewall) with SMTP id A080D11F56C5
	for ; Wed, 19 Nov 2008 14:57:38 -0500 (EST)
Received: (qmail 71661 invoked from network); 19 Nov 2008 19:57:38 -0000
Received: from unknown (HELO Wylie) (turners@130.129.78.78 with login)
	by smtp106.biz.mail.mud.yahoo.com with SMTP; 19 Nov 2008 19:57:37 -0000
X-YMail-OSG: qKd2hbMVM1luqrlTdrVVGe77TDuCJ_L6dFLxcdD8.Xtq6VYSo49iyVww5tkZZ699y1n.F.kULUaHec9beJXIMiFx10d4OCxkP6WW4hFbtIB7XHQuvr6gpQkN0haTmakVNsevGkeWdgVPpFxO8rsVw0tAMNgy5eJQB_eLKZe7Oe0E_7DwBJ3sXC7vVYaN
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." 
To: "'Benny Halevy'" , 
References: 
	<49246163.90707@panasas.com>
Date: Wed, 19 Nov 2008 13:57:13 -0600
Organization: IECA, Inc.
Message-ID: <749ECDC2264A4D08A4002A7F6453BBF6@Wylie>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <49246163.90707@panasas.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AclKeJCk6L3G7cv9QqO2v58pnp5GFgACEU4A
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Cc: magnus.westerlund@ericsson.com, 'secdir' ,
	welch@panasas.com, jimz@panasas.com, iesg@ietf.org
Subject: Re: [secdir] review of draft-ietf-nfsv4-pnfs-obj-09.txt
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I don't think that my comments alone would require a new version to be
published (i.e., I'd wait until AUTH48).

spt

>-----Original Message-----
>From: Benny Halevy [mailto:bhalevy@panasas.com] 
>Sent: Wednesday, November 19, 2008 12:57 PM
>To: Turner, Sean P.; lars.eggert@nokia.com
>Cc: secdir; welch@panasas.com; jimz@panasas.com; 
>iesg@ietf.org; magnus.westerlund@ericsson.com; Benny Halevy
>Subject: Re: review of draft-ietf-nfsv4-pnfs-obj-09.txt
>
>Sean, many thanks for your review and comments.
>I agree with both comments and corrected them locally.
>
>Sean/Lars, should I just submit an updated draft now, or 
>should I wait to see if there are any more comments from the 
>upcoming discussion planned for 2008-12-06?
>
>Benny
>
>On Nov. 18, 2008, 20:22 +0200, "Turner, Sean P." 
> wrote:
>> I have reviewed this document as part of the security directorate's 
>> ongoing effort to review all IETF documents being processed by the 
>> IESG.  These comments were written primarily for the benefit of the 
>> security area directors.  Document editors and WG chairs 
>should treat 
>> these comments just like any other last call comments.
>> 
>> I premise this review with the following: a) I'm not an NFS 
>expert and 
>> I don't play one on TV or on YouTube b) I did actually skim the 
>> 605-page base document to try to get a little smarter on NFS 
>(but I'm 
>> not sure how much smarter).
>> 
>> I think the document is well written and the security considerations 
>> section addresses the questions/concerns I thought of.
>> 
>> Editorial nits:
>> 
>> Section 2.1.2: r/Pnfs_osd_version/pnfs_osd_version4
>> Ref [5]/[7]: Authors instead of companies?
>> 
>> spt
>> 

_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Thu Nov 20 05:02:36 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4A86B3A6837;
	Thu, 20 Nov 2008 05:02:36 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6EC9A3A6837
	for ; Thu, 20 Nov 2008 05:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 197Kl5Eu+id0 for ;
	Thu, 20 Nov 2008 05:02:34 -0800 (PST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
	by core3.amsl.com (Postfix) with ESMTP id A70323A6768
	for ; Thu, 20 Nov 2008 05:02:34 -0800 (PST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAKD2UCs003274
	for ; Thu, 20 Nov 2008 08:02:33 -0500
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAKD2Tv1003239
	for ; Thu, 20 Nov 2008 08:02:29 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	mAKD2Niv010077
	for ; Thu, 20 Nov 2008 08:02:23 -0500 (EST)
Received: from luminous.suchdamage.org (luminous.suchdamage.org
	[69.25.196.179])
	by mit.edu (Spam Firewall) with ESMTP id AB16111F272B
	for ; Thu, 20 Nov 2008 08:02:02 -0500 (EST)
Received: by luminous.suchdamage.org (Postfix, from userid 8042)
	id 4DC14A6C0CE; Thu, 20 Nov 2008 08:02:02 -0500 (EST)
To: secdir@mit.edu
Message-Id: <20081120130202.4DC14A6C0CE@luminous.suchdamage.org>
Date: Thu, 20 Nov 2008 08:02:02 -0500 (EST)
From: hartmans@mit.edu (Sam Hartman)
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
MIME-Version: 1.0
Subject: [secdir]  SIP today at 1300
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

--text follows this line--


Jon Peterson points out that there is about 30 minutes of discussion
of how to secure signaling for DTLS-SRTP scheduled for SIP today.


As I understand the issue, session border controller vendors are
unhappy with SIP identity because its integrity protection covers too
much.  Jon believes their proposals cover too little.

It's kind of a complicated topic, and so it is probably more of an
opportunity to listen rather than to talk that much.  However if
you're already spun up on RTPSEC and are available, I think going
would be a good idea.  If you want to spin up on this important topic,
this might also be a good time to go.

_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Thu Nov 20 11:45:17 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 019073A6BAF;
	Thu, 20 Nov 2008 11:45:17 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7209E3A6BAF
	for ; Thu, 20 Nov 2008 11:45:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5
	tests=[AWL=-1.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id F31qkzWEAfX6 for ;
	Thu, 20 Nov 2008 11:45:14 -0800 (PST)
Received: from smtp101.biz.mail.mud.yahoo.com (smtp101.biz.mail.mud.yahoo.com
	[68.142.200.236])
	by core3.amsl.com (Postfix) with SMTP id 8FCCE3A69CB
	for ; Thu, 20 Nov 2008 11:45:14 -0800 (PST)
Received: (qmail 45920 invoked from network); 20 Nov 2008 19:45:12 -0000
Received: from unknown (HELO Wylie) (turners@130.129.29.26 with login)
	by smtp101.biz.mail.mud.yahoo.com with SMTP; 20 Nov 2008 19:45:12 -0000
X-YMail-OSG: W4GEGooVM1lL2xKV2viPjF4bS.LhPbhHdlMV0z9FbGlDZcNa1_sRpJtqvewpgzglalzrqwKaZ4ZT6fS7hzzWbj7zO09ZNgTeLxIDHbvFfD.9ReGIBr7IewaLxrM5VYOJgzB_8P8DmAqTW_eXSfc1nnrNwIezFQCvMzbmt55J
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." 
To: "secdir" 
Date: Thu, 20 Nov 2008 13:44:47 -0600
Organization: IECA, Inc.
Message-ID: <6C0AE36C1E164AA5AF1A6EAAA3A08991@Wylie>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
thread-index: AclLSHHdw4pey/R4Q1SH0WsjF38iLA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc: ietf-smime@imc.org
Subject: [secdir] SMIME WG summary
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org


The SMIME WG did not meeting at IETF 73.  The SMIME WG has 9 IDs.  Here is
the status of those IDs:

In RFC Editors Queue:

- draft-ietf-smime-multisig: Pinned on draft-ietf-smime-3850bis &
                             draft-ietf-smime-3850bis IDs.
- draft-ietf-smime-ibearch: In EDIT state.
- draft-ietf-smime-bfibecms: In EDIT state.

With AD (status: Passed IETF LC)
- draft-ietf-smime-3850bis: Awaiting GEN-ART comments 
- draft-ietf-smime-3851bis: Addressed IETF LC comments. 
                            Will publish when GEN-ART comments on
                            draft-ietf-smime-3850bis are addressed.

With AD (status: In 2nd IETF LC):
- draft-ietf-smime-sha2: No comments so far.

With AD (status: Awaiting new ID from authors):
- draft-ietf-smime-rfc3278-update: Addressing WG LC comments.
                                   New version published shortly after
                                   meeting.  Expected to go to WG LC.
- draft-ietf-smime-cms-rsa-kem: A new version was posted, but another
                                is needed to address Steve Kent's
                                SECDIR comments.

With WG
- draft-ietf-smime-new-asn1: This ID updates many/most of the ASN.1
     modules in the S/MIME WG to the '02 ASN.1.  The authors want
     reviewers.  It is expected that the ID will be ready for WG LC
     in December '08.

spt

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Thu Nov 20 14:30:11 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E13733A6A3F;
	Thu, 20 Nov 2008 14:30:10 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C94F63A6A3F
	for ; Thu, 20 Nov 2008 14:30:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level: 
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=1.900, 
	BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id J+QsnYE3gRca for ;
	Thu, 20 Nov 2008 14:30:09 -0800 (PST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
	by core3.amsl.com (Postfix) with ESMTP id D4A823A6A3D
	for ; Thu, 20 Nov 2008 14:30:08 -0800 (PST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAKMU7lX030855
	for ; Thu, 20 Nov 2008 17:30:07 -0500
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAKMSIqc030691
	for ; Thu, 20 Nov 2008 17:28:19 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	mAKMSBBq004923
	for ; Thu, 20 Nov 2008 17:28:11 -0500 (EST)
Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id B521A126D999
	for ; Thu, 20 Nov 2008 17:27:50 -0500 (EST)
X-CSD-MailScanner-Watermark: 1227824863.15515@UcbfN1Dqe/O67Fra2jj77g
Received: from [130.129.27.183] ([130.129.27.183]) (authenticated bits=0)
	by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id mAKMRfuX012675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Nov 2008 17:27:42 -0500
Message-ID: <4925E45D.5060201@ltsnet.net>
Date: Thu, 20 Nov 2008 17:27:41 -0500
From: Charles Clancy 
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: draft-ietf-l1vpn-ospfv3-auto-discovery@tools.ietf.org, iesg@ietf.org
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0
	(bacon.cs.umd.edu [172.24.3.34]);
	Thu, 20 Nov 2008 17:27:42 -0500 (EST)
X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more
	information
X-MailScanner-ID: mAKMRfuX012675
X-CSD-MailScanner: Found to be clean
X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50,
	required 5, autolearn=not spam, ALL_TRUSTED -50.00)
X-CSD-MailScanner-From: clancy@ltsnet.net
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Cc: l1vpn-chairs@tools.ietf.org, secdir@mit.edu
Subject: [secdir]  secdir review of draft-ietf-l1vpn-ospfv3-auto-discovery
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
  These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

Document: draft-ietf-l1vpn-ospfv3-auto-discovery
Title: OSPFv3 Based Layer 1 VPN Auto-Discovery

Summary: The document defines a mechanism for auto-discovery of 
OSPFv3-based L1 VPNs.  It parallels the RFC 5252 mechanism for 
OSPFv2-based discovery of L1 VPNs, and includes support for IPv6.  It 
specifically only covers transmission of this information between 
provider elements, and not to any customer elements.  The document 
defines a TLV for carrying this information as an OSPFv3 Link State 
Advertisement Type.

The document reuses existing OSPF over IPv6 security mechanisms for 
protecting and authenticating the exchanged TLVs.  This protects against 
many external threats, but does not protect against insider attacks 
(e.g. compromised or misconfigured routers), which could propagate 
invalid L1 VPN information throughout the routing domain.  This is 
documented fully in the referenced supporting documents.

The reviewer finds no specific security issues with the document.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Fri Nov 21 01:02:08 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5CEB43A67F1;
	Fri, 21 Nov 2008 01:02:08 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B09653A684C
	for ; Fri, 21 Nov 2008 01:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id tI+Q+SMKKz-9 for ;
	Fri, 21 Nov 2008 01:02:05 -0800 (PST)
Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.189])
	by core3.amsl.com (Postfix) with ESMTP id 747FC3A6826
	for ; Fri, 21 Nov 2008 01:02:05 -0800 (PST)
Received: by rn-out-0910.google.com with SMTP id j77so750178rne.18
	for ; Fri, 21 Nov 2008 01:02:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to
	:subject:mime-version:content-type;
	bh=l4fumfo8w6HzCpfaXdRhiJEZlgZxZLiHXDf5pd+OjEk=;
	b=moU/VfSgHwDWDxS18mgvUOqpvvrXin0SivBFlXdV+tnkAQsJ0RVK3mEGoxQ3vfCmwr
	yglV5uz6aSvE4IQ2SI7SWXz74vfDJqPxVHcnTS5Af6vpFlzNQntXtD0ziQTk8tYt52Yx
	wvTNLgx8f55NI6Trq5LXgYKTpV6dWqf/Pr398=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:mime-version:content-type;
	b=UclatsuDurlPjG66Dqv6OxApwW5RtmLD3gr+Y2ErTXOtGPydDipfcDEaSh0DAeTgx8
	fNi4SI6fyNAjCXY89UgD2t0Z+c2Os4m5+4JShO6cmy1K7UJtE8FmYSccXpeBlqDwHkHj
	6+qFHMEFz2axHq02T8zY2VKRdD3jioS8e+u8M=
Received: by 10.100.127.18 with SMTP id z18mr143648anc.6.1227258123470;
	Fri, 21 Nov 2008 01:02:03 -0800 (PST)
Received: by 10.100.137.8 with HTTP; Fri, 21 Nov 2008 01:02:03 -0800 (PST)
Message-ID: <1028365c0811210102l6d391147t7b89e558f770d005@mail.gmail.com>
Date: Fri, 21 Nov 2008 04:02:03 -0500
From: "Donald Eastlake" 
To: iesg@ietf.org, secdir@ietf.org, "George Swallow" , 
	"Loa Andersson" , mjork@nextpointnetworks.com, 
	alia.atlas@bt.com, lufang@cisco.com
MIME-Version: 1.0
Subject: [secdir] draft-ietf-mpls-ldp-igp-sync-03.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1288548217=="
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

--===============1288548217==
Content-Type: multipart/alternative; 
	boundary="----=_Part_112879_26763690.1227258123464"

------=_Part_112879_26763690.1227258123464
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

This document suggests ways to help where MPLS and MPLS label distribution
(LDP) are intended to run over the links in a network as determined by an IP
routing protocol but, for one reason or another, either transiently or
permanently, IP routing is up on a link but MPLS is not functioning. This
results in the possibility of MPLS frames following a path found by routing
but getting black holed at the link where MPLS is not operational. The draft
also suggests applicability of its suggestions to some types of tunnels.

Security Considerations
   While, admittedly, this relatively short document is about some fairly
simple things relating to MPLS LDP and IP routing, I felt a bit shortchanged
by the Security Considerations section.
   It is my impression that this document, or at least the underlying
protocols it refers to, assume a trusted "provider" world with a secure
perimeter such that "customer" traffic from the uncontrolled outside world
has been tamed / filtered / labeled as it enters this trusted world. The
presence of such clues as "edge-to-edge" and "PE" which, while unexplained
and unexpanded in this document, I assume to be "Provider Edge", lead to
this conclusion. But it would be nice to say this and/or to give a reference
to the Security Considerations section of RFC 5306, which tends to recommend
being secure by only talking to nodes that won't say anything nasty to you.
   The possibilities of Denial of Service caused by the drafts
recommendations are discussed and do not seem particularly serious except,
as the draft says, in case of "operational error or implementation error"
however, I think the reference to "current best security practice" without
any reference or further explanation is a bit vague.

Editorial   Section 5, page 5, first line: Insert "that" after "attack".
   Section 5, page 5, fifth line: Replace "here is to prevent the link to be
used when" with "here prevents the use of the link when"

I am bothered that no author lists a telephone number in the Author's
Addresses section.

Thanks,Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com

------=_Part_112879_26763690.1227258123464
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  Document editors and WG chairs should treat these comments just like any other last call comments.



This document suggests ways to help where MPLS and MPLS label distribution (LDP) are intended to run over the links in a network as determined by an IP routing protocol but, for one reason or another, either transiently or permanently, IP routing is up on a link but MPLS is not functioning. This results in the possibility of MPLS frames following a path found by routing but getting black holed at the link where MPLS is not operational. The draft also suggests applicability of its suggestions to some types of tunnels.



Security Considerations
   While, admittedly, this relatively short document is about some fairly simple things relating to MPLS LDP and IP routing, I felt a bit shortchanged by the Security Considerations section.


   It is my impression that this document, or at least the underlying protocols it refers to, assume a trusted "provider" world with a secure perimeter such that "customer" traffic from the uncontrolled outside world has been tamed / filtered / labeled as it enters this trusted world. The presence of such clues as "edge-to-edge" and "PE" which, while unexplained and unexpanded in this document, I assume to be "Provider Edge", lead to this conclusion. But it would be nice to say this and/or to give a reference to the Security Considerations section of RFC 5306, which tends to recommend being secure by only talking to nodes that won't say anything nasty to you.


   The possibilities of Denial of Service caused by the drafts recommendations are discussed and do not seem particularly serious except, as the draft says, in case of "operational error or implementation error" however, I think the reference to "current best security practice" without any reference or further explanation is a bit vague.




Editorial
   Section 5, page 5, first line: Insert "that" after "attack".
   Section 5, page 5, fifth line: Replace "here is to prevent the link to be used when" with "here prevents the use of the link when"



I am bothered that no author lists a telephone number in the Author's Addresses section.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)


 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3@gmail.com




------=_Part_112879_26763690.1227258123464--

--===============1288548217==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir

--===============1288548217==--


From secdir-bounces@ietf.org  Fri Nov 21 21:45:37 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5B0D13A6AB5;
	Fri, 21 Nov 2008 21:45:37 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0D0433A6AAD
	for ; Fri, 21 Nov 2008 21:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0wmhAu1thzTp for ;
	Fri, 21 Nov 2008 21:45:26 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251])
	by core3.amsl.com (Postfix) with ESMTP id 2B7A53A6A5A
	for ; Fri, 21 Nov 2008 21:45:26 -0800 (PST)
Received: from [192.168.1.106] ((unknown) [75.146.152.44]) 
	by rufus.isode.com (submission channel) via TCP with ESMTPA 
	id ; Sat, 22 Nov 2008 05:45:23 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <49279C4F.10909@isode.com>
Date: Fri, 21 Nov 2008 23:44:47 -0600
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: tsvwg-chairs@tools.ietf.org,
	draft-ietf-tsvwg-admitted-realtime-dscp@tools.ietf.org
MIME-Version: 1.0
Cc: iesg@iesg.org, "secdir@ietf.org" 
Subject: [secdir] secdir review of draft-ietf-tsvwg-admitted-realtime-dscp-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

This document requests one Differentiated Services Code Point (DSCP)
from the Internet Assigned Numbers Authority (IANA) for real-time
traffic classes similar to voice conforming to the Expedited
Forwarding Per Hop Behavior, and admitted using a call admission
procedure involving authentication, authorization, and capacity
admission.

This document also recommends that certain classes of video traffic
described in RFC 4594 and which have similar requirements be changed
to require admission using a Call Admission Control (CAC) procedure
involving authentication, authorization, and capacity admission.

For a person not familiar with the underlying technology,
I found the Security Consideration section to be insufficiently detailed
about threats. While the list of threats seems to be adequate,
it would be useful to have some pointers to documents describing possible
remedies (for example how to achieve adequately strong proof of identity),
or a clear statement that the protocol doesn't provide such facility.


_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Sat Nov 22 15:34:37 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4FC513A6B03;
	Sat, 22 Nov 2008 15:34:37 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8C3003A6B03
	for ; Sat, 22 Nov 2008 15:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.476
X-Spam-Level: 
X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5
	tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4,
	USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 3eJbirS12aVt for ;
	Sat, 22 Nov 2008 15:34:35 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
	by core3.amsl.com (Postfix) with ESMTP id D7E033A6807
	for ; Sat, 22 Nov 2008 15:34:35 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,651,1220227200"; d="scan'208";a="199826686"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 22 Nov 2008 23:34:34 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAMNYYWj031907; 
	Sat, 22 Nov 2008 15:34:34 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mAMNYTXU023034;
	Sat, 22 Nov 2008 23:34:34 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 22 Nov 2008 15:34:32 -0800
Received: from [172.28.172.194] ([10.21.89.76]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 22 Nov 2008 15:34:31 -0800
Message-Id: 
From: Fred Baker 
To: Alexey Melnikov 
In-Reply-To: <49279C4F.10909@isode.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Sat, 22 Nov 2008 17:34:30 -0600
References: <49279C4F.10909@isode.com>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 22 Nov 2008 23:34:31.0603 (UTC)
	FILETIME=[DE8C2030:01C94CFA]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1190; t=1227396874;
	x=1228260874; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fred@cisco.com;
	z=From:=20Fred=20Baker=20
	|Subject:=20Re=3A=20secdir=20review=20of=20draft-ietf-tsvwg
	-admitted-realtime-dscp-05 |Sender:=20;
	bh=qnVadOlrBxxQJx2Hi8YNejGKebaCRyLMgNzkbVQDLtM=;
	b=auFvpVb0KExU+mLAAeoyFyFeGmhEuYrpVI/PujDMs7gkYkjeBTcLRxSVPq
	X8cz/T6WtlB5FhfErEH+fqTx1ZFujgJ8P3RTxUnbXjjPUTB9muM+YJaQhdNP
	0HSttOWU3BGcXYy6tPXDrHWrUpIwuPTDQYOEEIupR44d8kmrVzU7g=;
Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
Cc: draft-ietf-tsvwg-admitted-realtime-dscp@tools.ietf.org,
	tsvwg-chairs@tools.ietf.org, iesg@iesg.org,
	"secdir@ietf.org" 
Subject: Re: [secdir] secdir review of
	draft-ietf-tsvwg-admitted-realtime-dscp-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org


On Nov 21, 2008, at 11:44 PM, Alexey Melnikov wrote:

> I found the Security Consideration section to be insufficiently  
> detailed
> about threats. While the list of threats seems to be adequate,
> it would be useful to have some pointers to documents describing  
> possible
> remedies (for example how to achieve adequately strong proof of  
> identity),
> or a clear statement that the protocol doesn't provide such facility.

Would a reference to 4542 be sufficient?

My sense is that the threat model on a AAA service is likely to be  
documented in something related to AAA services, and frankly you are  
more likely to have a pointer to the document than I. Similarly, the  
threat model regarding people getting capacity allocated to them that  
shouldn't have been seems implicit in RFC 1633, the documentation of  
RSVP, and the documentation of NSIS - protocols designed explicitly to  
prevent that from happening. There is of course a threat model for  
implementing such a protocol as well, which is mentioned in RFC 4230.

if I'm missing something and you want more, some idea of what kind of  
threat model you are looking for would be helpful.
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Mon Nov 24 11:59:40 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D5A723A6AFE;
	Mon, 24 Nov 2008 11:59:40 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D9DC53A6AFE;
	Mon, 24 Nov 2008 11:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.044
X-Spam-Level: 
X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0qqLtLioOYWW; Mon, 24 Nov 2008 11:59:39 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71])
	by core3.amsl.com (Postfix) with ESMTP id 3F6B03A67C0;
	Mon, 24 Nov 2008 11:59:39 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,660,1220227200"; d="scan'208";a="108485423"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-2.cisco.com with ESMTP; 24 Nov 2008 19:59:37 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAOJxbW6000975; 
	Mon, 24 Nov 2008 11:59:37 -0800
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68])
	by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAOJxb2W013386;
	Mon, 24 Nov 2008 19:59:37 GMT
Date: Mon, 24 Nov 2008 11:59:37 -0800 (PST)
From: Chris Lonvick 
To: iesg@ietf.org, secdir@ietf.org, msk+ietf@sendmail.com,
	lisa@osafoundation.org
Message-ID: 
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=747; t=1227556777; x=1228420777;
	c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=clonvick@cisco.com;
	z=From:=20Chris=20Lonvick=20
	|Subject:=20SECDIR=20review=20of=20draft-kucherawy-sender-a
	uth-header-17 |Sender:=20;
	bh=DNIKPqWUIj4fsmmn6CBiDYdPAWG0VdKZczuhe3dO7oM=;
	b=hHDCSwHGMehcdji8CLdUzt7JcCQ4Iv8Xg39N+W1bjNKBZkBY/qx6OAj0G5
	+lcob8OrBJ/EAQJzvQojSYiCk1zK5mZHY+ofUuRvv4FDYxjk95Xtp+0MIdrm
	CeRe/aMUY4;
Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
Subject: [secdir] SECDIR review of draft-kucherawy-sender-auth-header-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Unfortunately, I wasn't able to spend a lot of time with this document. 
I skimmed most of it and read through the Security Considerations section. 
>From what I saw, the document appears to be in good shape.  The Security 
Considerations section is thorough and appears to cover all of the cases. 
Overall, I believe that the Internet community will benefit from this 
work.

Best regards,
Chris
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Mon Nov 24 21:23:12 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 87A933A6BC5;
	Mon, 24 Nov 2008 21:23:12 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CC7C03A6A9A;
	Mon, 24 Nov 2008 21:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Level: 
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 
	BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id xQ6+Eyr8E4f4; Mon, 24 Nov 2008 21:23:11 -0800 (PST)
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81])
	by core3.amsl.com (Postfix) with ESMTP id F38023A6A88;
	Mon, 24 Nov 2008 21:23:10 -0800 (PST)
Received: from [128.89.255.73] (helo=Richard-Barnes-Laptop.local)
	by mx3.bbn.com with esmtp (Exim 4.63)
	(envelope-from )
	id 1L4qO4-0006Xr-9t; Tue, 25 Nov 2008 00:23:00 -0500
Message-ID: <492B8BB3.4010007@bbn.com>
Date: Tue, 25 Nov 2008 00:22:59 -0500
From: Richard Barnes 
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: iesg@ietf.org, secdir@ietf.org, IETF Discussion , 
	draft-ietf-calsify-rfc2445bis@tools.ietf.org
References: 
In-Reply-To: 
Subject: [secdir] SECDIR review of draft-ietf-calsify-rfc2445bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Hi all,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document defines a document format (iCalendar) for expressing 
calendaring information.  This format does not contain mechanisms for 
providing security features to the information encoded in it, but there 
is appropriate text in the Security Considerations to guide protocols 
that might carry iCalendar documents.

My only real concern is the ambiguity of the "Binary" value data type. 
The other value data types defined in this document have clear semantics 
attached that indicate how a compliant parser might handle the encoded 
data.  The Binary type defines how to decode the included data, but not 
what sort of information this data conveys.  Without further context to 
guide processing of this information, I'm concerned that this could lead 
to implementations that attempt to guess the type of binary content.  I 
would suggest adding text to Section 3.2.20 of the following character:
"
If this parameter indicates that the type of the property value is 
BINARY, then the FMTTYPE paramter MUST be set in order to indicate the 
MIME type of the encoded binary information.
"

In general, though, I think this document is ready to go.

--Richard
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Tue Nov 25 03:51:05 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 659963A692B;
	Tue, 25 Nov 2008 03:51:05 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8DBE63A67F5
	for ; Tue, 25 Nov 2008 03:48:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.165
X-Spam-Level: 
X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5
	tests=[AWL=-1.433, BAYES_00=-2.599, HTML_MESSAGE=0.001,
	J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, SARE_HTML_SINGLETS=1.666,
	UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id kMxEgDemH9kX for ;
	Tue, 25 Nov 2008 03:48:02 -0800 (PST)
Received: from mgw2.noc.ntt.com (mgw2.noc.ntt.com [210.160.15.6])
	by core3.amsl.com (Postfix) with ESMTP id 79AA33A692B
	for ; Tue, 25 Nov 2008 03:48:01 -0800 (PST)
Received: from mop2.noc.ntt.com
	by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id mAPBltPX015028;
	Tue, 25 Nov 2008 20:47:55 +0900 (JST)
Received: from mip1.noc.ntt.com (mvi2.noc.ntt.com)
	by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id
	<0KAW00ANI0RVZ5@ntt.com>; Tue, 25 Nov 2008 20:47:55 +0900 (JST)
Date: Tue, 25 Nov 2008 20:47:51 +0900
From: "Yuji KAMITE" 
In-reply-to: <25092678-15BA-42B6-B3CB-540C572A7859@nist.gov>
To: "'Tim Polk'" 
Message-id: <002101c94ef3$a5b23970$b3d80e0a@coe.ntt.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/mixed;
	boundary="----=_NextPart_000_0022_01C94F3F.1599E170"
Thread-index: AclI7lo6i8ORuYAQQhS2oFMexGUuVgF/9WEw
References: <002101c948d2$a6f73280$89fa320a@araoa.ntt.com>
	<25092678-15BA-42B6-B3CB-540C572A7859@nist.gov>
X-Mailman-Approved-At: Tue, 25 Nov 2008 03:51:04 -0800
Cc: 'Mark Townsley' ,
	draft-ietf-l2vpn-vpls-mcast-reqts@tools.ietf.org,
	l2vpn-chairs@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Status of draft-ietf-l2vpn-vpls-mcast-reqts?
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01C94F3F.1599E170
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Tim (CC: Sec-Dirs),

> I will keep an eye out for the new text, and would be glad to 
> review it.

For addressing your DISCUSSes and Sec-Dir comments
about this document, I am thinking about revising as attached.

In your review you pointed out that the current document
lacks of thorough security analysis, so now I propose the text
to address it.

I'd appreciate your recheck if it addresses the points you raised.
For detail, please see the attached text.  I also send the diff-file
for your convenience.

Best regards,
-Yuji

------------------------------
Proposed changes summary:
 - Modified Section 6.6.
      - Create subsection 6.6.1 for security threat analysis : 
        - This is totally new text for addressing Sam's DISCUSS and Sec-Dir comment below:
          https://datatracker.ietf.org/idtracker/draft-ietf-l2vpn-vpls-mcast-reqts/comment/75905/
          http://www.ietf.org/mail-archive/web/ietf/current/msg49004.html

      - Create subsection 6.6.2. for security requirements:  
        - Added a short paragraph to show highlighted relationship to address the Tim's DISCUSS
          https://datatracker.ietf.org/idtracker/draft-ietf-l2vpn-vpls-mcast-reqts/comment/78677/
        - Elaborated how each threat item is solved/mitigated 

 - Modified Section 7.
      - Added text as 3rd paragraph to reflect the proposed changes in Section 6.6.
------------------------------


> -----Original Message-----
> From: Tim Polk [mailto:tim.polk@nist.gov] 
> Sent: Tuesday, November 18, 2008 4:55 AM
> To: Yuji KAMITE
> Cc: 'Mark Townsley'; 
> draft-ietf-l2vpn-vpls-mcast-reqts@tools.ietf.org; 
> l2vpn-chairs@tools.ietf.org
> Subject: Re: Status of draft-ietf-l2vpn-vpls-mcast-reqts?
> 
> Hi Yuji,
> 
> I will keep an eye out for the new text, and would be glad to 
> review it.
> 
> Thanks,
> 
> Tim
> 
> On Nov 17, 2008, at 10:36 AM, Yuji KAMITE wrote:
> 
> > Mark,
> >
> > Regarding Tim's comment,
> > I've been writing up the security threat analysis recently, but 
> > couldn't submit before the deadline.
> > I'd like to show the curent proposed text for security very soon.  
> > (Hopefully in this week.) I hope Tim will take a look at it.
> >
> > BTW, regarding Ron's comment,
> > I did the changes to address his comment already.
> > But not sure if he actually confirmed it.
> >
> > Regards,
> > Yuji
> > -----Original Message-----
> > From: Mark Townsley [mailto:townsley@cisco.com]
> > Sent: Monday, November 17, 2008 9:40 AM
> > To: draft-ietf-l2vpn-vpls-mcast-reqts@tools.ietf.org;
> > l2vpn-chairs@tools.ietf.org
> > Subject: Status of draft-ietf-l2vpn-vpls-mcast-reqts?
> >
> >
> >
> > My notes say:
> >> 2 issues mostly covered, remaining security threat analysis issue 
> >> taking more time.
> > I assume this means the comment from Ron can be argued against, but 
> > that the security issue is more problematic.
> >
> > The document hasn't moved since the last IETF. It seems stuck and 
> > needs a little attention from someone.
> >
> > Authors, please try and sit down with Tim Polk this week 
> and resolve 
> > what needs to be done to move this document forward. If you need my 
> > help, please ask.
> >
> > Thanks,
> >
> > - Mark
> >
> >
> >> Discusses and Comments
> >> Ron Bonica:
> >> Discuss:
> >> [2007-12-20] Maybe I missed it, but the document doesn't seem to 
> >> address MAC learning.
> >>
> >> Comment:
> >> [2007-12-20] You say "
> >>
> >> "Furthermore, in some cases, IP service providers might expect 
> >> operational simplicity of VPLS.  That is, they avoid direct and 
> >> detailed knowledge of IP routing.  In this case, the multicast 
> >> delivery mechanism is expected to have not only efficiency 
> but also 
> >> simplicity.  Generally speaking, there is a trade-off between 
> >> efficiency and simplicity in terms of bandwidth usage and state 
> >> maintenance, so the optimum trade-off will vary depending on the 
> >> requirements of each IP service provider."
> >>
> >> The argument about "operational simplicity of VPLS" 
> relative to layer
> >> 3 service is difficult to support, as instead of "direct 
> and detailed 
> >> knowledge of IP routting", one has to deal with direct and 
> detailed 
> >> knowledge of MAC addresses (including MAC address learning), and 
> >> layer 2.
> >>
> >> Consider removing the entire paragraph
> >>
> >>
> >> Also, you say:
> >>
> >>   "A solution SHOULD honor customer multicast domains."
> >>
> >>
> >> Perhaps replace with "A solution SHOULD NOT alter customer 
> multicast 
> >> domains' boundaries", as it is not clear what "honor .. multicast 
> >> domains"
> >> really means. Otherwise, clarify what "honor" means.
> >>
> >> Also, you say:
> >>
> >> "Multicast forwarding restoration time MUST NOT be greater 
> than the 
> >> restoration time of a customer's Layer-3 multicast protocols.  For 
> >> example, if a customer uses PIM with default configuration, hello 
> >> hold timer is 105 seconds, and solutions are required to detect a 
> >> failure no later than this period."
> >>
> >> The above mixes *restoration* time at layer 3 with 
> *detection* time 
> >> at the VPLS infrastructure. Does not seems to be correct.
> >>
> >>
> >> Also, you say:
> >>
> >> Therefore, in addition to the L2VPN discovery requirements in 
> >> [RFC4665], a multicast VPLS solution SHOULD provide a method that 
> >> dynamically allows multicast membership information to be 
> discovered 
> >> by PEs.  Such membership information is, for example, a set of 
> >> multicast addresses.  What information is provided dynamically is 
> >> solution specific."
> >>
> >>
> >> This paragraph mixes several issues that should probably be 
> >> unbundled.
> >> First of all, unless a solution supports (A), as defined in 3.2, 
> >> there is little point in PEs' dynamically discovering multicast 
> >> membership info. So, "SHOULD" be conditioned on supporting (A).
> >>
> >> Second in one scenario a PE discovers multicast membership 
> info from 
> >> only the sites connected to that PE, while in another scenario in 
> >> addition to the previous scenario the PE discovers multicast 
> >> membership info from other PEs as well. The spec needs to 
> spell out 
> >> what exactly it means by "dynamically allow multicast membership 
> >> information to be discovered by PEs".
> >>
> >> Tim Polk:
> >> Discuss:
> >> [2008-03-11] [This is a revised discuss, integrating Sam Hartman's 
> >> issues and my own into a single discuss to support AD transition.]
> >>
> >> This discuss elaborates on issues raised in Steve Hanna's security 
> >> directorate review; that review also needs to be examined in its 
> >> entirety.
> >>
> >> The following issue from the secdir review is blocking:
> >>> Unfortunately, the document does not contain a systematic 
> security 
> >>> analysis of the problem. The Security Considerations section 
> >>> consists of two brief paragraphs. These paragraphs refer to other 
> >>> sections in the document where security requirements are 
> listed and 
> >>> to RFC 4665, which also lists security requirements. However, I 
> >>> could not find any methodical threat analysis listing the 
> possible 
> >>> threats relevant to the system and stating which ones are 
> protected 
> >>> against and which are not.
> >>
> >>> Without a thorough threat analysis, I have little confidence that 
> >>> the authors have thought carefully about the possible 
> threats to the 
> >>> system. I would expect this to lead to large gaps in the security 
> >>> requirements and this seems to be borne out in practice. For 
> >>> example, there is no discussion of threats due to compromise of 
> >>> components within the service provider network.
> >>
> >>> Even more troublesome, I think that a single node at a 
> customer site 
> >>> (presumably untrusted) can mount dangerous attacks. For 
> example, a 
> >>> node that joins many multicast groups can cause a large amount of 
> >>> state to be maintained in the L2VPN.
> >>
> >> Please provide a threat analysis and please work to address or 
> >> document the specific security concerns cited.
> >>
> >> Section 6.6 provides a list of mechanisms a VPLS solution SHOULD 
> >> include.  There is no apparent relationship between the 
> requirements, 
> >> and each is listed with a caveat regarding its application 
> (e.g., "if 
> >> examined").  The net effect is that list appears to be 
> nearly empty 
> >> under some circumstances: if multicast IP addresses are 
> not used for 
> >> forwarding, and neither Ethernet multicast control frames or IP 
> >> multicast control packets are examined, only the first and last 
> >> bullets would apply.
> >>
> >> First, are there implicit relationships that should be 
> highlighted to 
> >> clarify the overall effect? For example, if a VPLS solution always 
> >> examines either Ethernet multicast control frames or IP multicast 
> >> control packets, the net effect is very different.  If such 
> >> relationships exist they should be specifed.
> >>
> >> The SHOULD list is followed by several paragraphs with MAY 
> >> requirements.  Again, the net effect is that a VPLS solution might 
> >> provide none of these mechanisms.  The security considerations 
> >> section needs to elaborate on the consequences of a VPLS solution 
> >> that omits these security mechanisms.
> >
> 

------=_NextPart_000_0022_01C94F3F.1599E170
Content-Type: text/plain;
	name="draft-ietf-l2vpn-vpls-mcast-reqts-07_tmp2_0811.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-l2vpn-vpls-mcast-reqts-07_tmp2_0811.txt"

=0A=
=0A=
=0A=
Network Working Group                                     Y. Kamite, Ed.=0A=
Internet-Draft                                        NTT Communications=0A=
Intended status: Informational                                   Y. Wada=0A=
Expires: May 29, 2009                                                NTT=0A=
                                                              Y. Serbest=0A=
                                                                    AT&T=0A=
                                                                T. Morin=0A=
                                                          France Telecom=0A=
                                                                 L. Fang=0A=
                                                     Cisco Systems, Inc.=0A=
                                                            Nov 25, 2008=0A=
=0A=
=0A=
   Requirements for Multicast Support in Virtual Private LAN Services=0A=
                draft-ietf-l2vpn-vpls-mcast-reqts-07.txt=0A=
=0A=
Status of this Memo=0A=
=0A=
   By submitting this Internet-Draft, each author represents that any=0A=
   applicable patent or other IPR claims of which he or she is aware=0A=
   have been or will be disclosed, and any of which he or she becomes=0A=
   aware will be disclosed, in accordance with Section 6 of BCP 79.=0A=
=0A=
   Internet-Drafts are working documents of the Internet Engineering=0A=
   Task Force (IETF), its areas, and its working groups.  Note that=0A=
   other groups may also distribute working documents as Internet-=0A=
   Drafts.=0A=
=0A=
   Internet-Drafts are draft documents valid for a maximum of six months=0A=
   and may be updated, replaced, or obsoleted by other documents at any=0A=
   time.  It is inappropriate to use Internet-Drafts as reference=0A=
   material or to cite them other than as "work in progress."=0A=
=0A=
   The list of current Internet-Drafts can be accessed at=0A=
   http://www.ietf.org/ietf/1id-abstracts.txt.=0A=
=0A=
   The list of Internet-Draft Shadow Directories can be accessed at=0A=
   http://www.ietf.org/shadow.html.=0A=
=0A=
   This Internet-Draft will expire on May 29, 2009.=0A=
=0A=
Abstract=0A=
=0A=
   This document provides functional requirements for network solutions=0A=
   that support multicast over Virtual Private LAN Service (VPLS).  It=0A=
   specifies requirements both from the end user and service provider=0A=
   standpoints.  It is intended that potential solutions will use these=0A=
   requirements as guidelines.=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                  [Page 1]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
Table of Contents=0A=
=0A=
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4=0A=
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4=0A=
     1.2.  Scope of this document . . . . . . . . . . . . . . . . . .  5=0A=
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5=0A=
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5=0A=
     2.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  7=0A=
   3.  Problem Statements . . . . . . . . . . . . . . . . . . . . . .  7=0A=
     3.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  7=0A=
     3.2.  Multicast Scalability  . . . . . . . . . . . . . . . . . .  7=0A=
     3.3.  Application Considerations . . . . . . . . . . . . . . . .  8=0A=
       3.3.1.  Two Perspectives of the Service  . . . . . . . . . . .  9=0A=
   4.  General Requirements . . . . . . . . . . . . . . . . . . . . .  9=0A=
     4.1.  Scope of Transport . . . . . . . . . . . . . . . . . . . . 10=0A=
       4.1.1.  Traffic Types  . . . . . . . . . . . . . . . . . . . . 10=0A=
       4.1.2.  Multicast Packet Types . . . . . . . . . . . . . . . . 10=0A=
       4.1.3.  MAC Learning Consideration . . . . . . . . . . . . . . 12=0A=
     4.2.  Static Solutions . . . . . . . . . . . . . . . . . . . . . 12=0A=
     4.3.  Backward Compatibility . . . . . . . . . . . . . . . . . . 12=0A=
   5.  Customer Requirements  . . . . . . . . . . . . . . . . . . . . 12=0A=
     5.1.  CE-PE protocol . . . . . . . . . . . . . . . . . . . . . . 12=0A=
       5.1.1.  Layer-2 Aspect . . . . . . . . . . . . . . . . . . . . 12=0A=
       5.1.2.  Layer-3 Aspect . . . . . . . . . . . . . . . . . . . . 13=0A=
     5.2.  Multicast Domain . . . . . . . . . . . . . . . . . . . . . 14=0A=
     5.3.  Quality of Service (QoS) . . . . . . . . . . . . . . . . . 14=0A=
     5.4.  SLA Parameters Measurement . . . . . . . . . . . . . . . . 15=0A=
     5.5.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 15=0A=
       5.5.1.  Isolation from Unicast . . . . . . . . . . . . . . . . 15=0A=
       5.5.2.  Access Control . . . . . . . . . . . . . . . . . . . . 16=0A=
       5.5.3.  Policing and Shaping on Multicast  . . . . . . . . . . 16=0A=
     5.6.  Access Connectivity  . . . . . . . . . . . . . . . . . . . 16=0A=
     5.7.  Multi-Homing . . . . . . . . . . . . . . . . . . . . . . . 16=0A=
     5.8.  Protection and Restoration . . . . . . . . . . . . . . . . 16=0A=
     5.9.  Minimum MTU  . . . . . . . . . . . . . . . . . . . . . . . 16=0A=
     5.10. Frame Reordering Prevention  . . . . . . . . . . . . . . . 17=0A=
     5.11. Fate-Sharing between Unicast and Multicast . . . . . . . . 17=0A=
   6.  Service Provider Network Requirements  . . . . . . . . . . . . 18=0A=
     6.1.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . 18=0A=
       6.1.1.  Trade-off of Optimality and State Resource . . . . . . 18=0A=
       6.1.2.  Key Metrics for Scalability  . . . . . . . . . . . . . 19=0A=
     6.2.  Tunneling Requirements . . . . . . . . . . . . . . . . . . 20=0A=
       6.2.1.  Tunneling Technologies . . . . . . . . . . . . . . . . 20=0A=
       6.2.2.  MTU of MDTunnel  . . . . . . . . . . . . . . . . . . . 20=0A=
     6.3.  Robustness . . . . . . . . . . . . . . . . . . . . . . . . 21=0A=
     6.4.  Discovering Related Information  . . . . . . . . . . . . . 21=0A=
     6.5.  Operation, Administration and Maintenance  . . . . . . . . 21=0A=
       6.5.1.  Activation . . . . . . . . . . . . . . . . . . . . . . 21=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                  [Page 2]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
       6.5.2.  Testing  . . . . . . . . . . . . . . . . . . . . . . . 22=0A=
       6.5.3.  Performance Management . . . . . . . . . . . . . . . . 22=0A=
       6.5.4.  Fault Management . . . . . . . . . . . . . . . . . . . 23=0A=
     6.6.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 24=0A=
       6.6.1.  Security Threat Analysis . . . . . . . . . . . . . . . 24=0A=
       6.6.2.  Security Requirements  . . . . . . . . . . . . . . . . 25=0A=
     6.7.  Hierarchical VPLS support  . . . . . . . . . . . . . . . . 27=0A=
     6.8.  L2VPN Wholesale  . . . . . . . . . . . . . . . . . . . . . 27=0A=
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28=0A=
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28=0A=
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28=0A=
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28=0A=
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 28=0A=
     10.2. Informative References . . . . . . . . . . . . . . . . . . 28=0A=
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30=0A=
   Intellectual Property and Copyright Statements . . . . . . . . . . 32=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                  [Page 3]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
1.  Introduction=0A=
=0A=
1.1.  Background=0A=
=0A=
   VPLS (Virtual Private LAN Service) is a provider service that=0A=
   emulates the full functionality of a traditional Local Area Network=0A=
   (LAN).  VPLS interconnects several customer LAN segments over a=0A=
   packet switched network (PSN) backbone, creating a multipoint-to-=0A=
   multipoint Ethernet VPN.  For customers, their remote LAN segments=0A=
   behave as one single LAN.=0A=
=0A=
   In a VPLS, the provider network emulates a learning bridge, and=0A=
   forwarding takes place based on Ethernet MAC learning.  Hence, a VPLS=0A=
   requires MAC address learning/aging on a per PW (Pseudo Wire) basis,=0A=
   where forwarding decisions treat the PW as a "bridge port".=0A=
=0A=
   VPLS is a Layer-2 service.  However, it provides two applications=0A=
   from the customer's point of view:=0A=
=0A=
      - LAN Routing application: providing connectivity between customer=0A=
      routers=0A=
      - LAN Switching application: providing connectivity between=0A=
      customer Ethernet switches=0A=
=0A=
   Thus, in some cases, customers across MAN/WAN have transparent=0A=
   Layer-2 connectivity while their main goal is to run Layer-3=0A=
   applications within their routing domain.  As a result, different=0A=
   requirements arise from their variety of applications.=0A=
=0A=
   Originally, PEs (Provider Edges) in VPLS transport broadcast/=0A=
   multicast Ethernet frames by replicating all multicast/broadcast=0A=
   frames received from an AC to all PW's corresponding to a particular=0A=
   VSI.  Such a technique has the advantage of keeping the P (Provider=0A=
   Router) and PE devices completely unaware of IP multicast-specific=0A=
   issues.  Obviously, however, it has quite a few scalability drawbacks=0A=
   in terms of bandwidth consumption, which will lead to increased cost=0A=
   in large-scale deployment.=0A=
=0A=
   Meanwhile, there is a growing need for support of multicast-based=0A=
   services such as IP TV.  This commercial trend makes it necessary for=0A=
   most VPLS deployments to support multicast more efficiently than=0A=
   before.  It is also necessary as customer routers are now likely to=0A=
   be running IP multicast protocols and those routers and connected to=0A=
   switches that will be handling large amounts of multicast traffic.=0A=
=0A=
   Therefore, it is desirable to have more efficient techniques to=0A=
   support IP multicast over VPLS.=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                  [Page 4]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
1.2.  Scope of this document=0A=
=0A=
   This document provides functional requirements for network solutions=0A=
   that support IP multicast in VPLS [RFC4761] [RFC4762].  It identifies=0A=
   requirements that MAY apply to the existing base VPLS architecture in=0A=
   order to optimize IP multicast.  It also complements the generic L2=0A=
   VPN requirements document [RFC4665], by specifying additional=0A=
   requirements specific to the deployment of IP multicast in VPLS.=0A=
=0A=
   The technical specifications are outside the scope of this document.=0A=
   There is no intent to either specify solution-specific details in=0A=
   this document or application-specific requirements.  Also, this=0A=
   document does NOT aim to express multicast-inferred requirements that=0A=
   are not specific to VPLS.  It does NOT aim to express any=0A=
   requirements for native Ethernet specifications, either.=0A=
=0A=
   This document is proposed as a solution guideline and a checklist of=0A=
   requirements for solutions, by which we will evaluate how each=0A=
   solution satisfies the requirements.=0A=
=0A=
   This document clarifies the needs from both VPLS customer as well as=0A=
   provider standpoints and formulates the problems that should be=0A=
   addressed by technical solutions while staying solution agnostic.=0A=
=0A=
   A technical solution and corresponding service which supports this=0A=
   document's requirements are hereinafter called a "multicast VPLS".=0A=
=0A=
=0A=
2.  Conventions used in this document=0A=
=0A=
2.1.  Terminology=0A=
=0A=
   The reader is assumed to be familiar with the terminology, reference=0A=
   models and taxonomy defined in [RFC4664] and [RFC4665].  For=0A=
   readability purposes, we repeat some of the terms here.=0A=
=0A=
   Moreover, we also propose some other terms needed when IP multicast=0A=
   support in VPLS is discussed.=0A=
=0A=
   - ASM:  Any Source Multicast.  One of the two multicast service=0A=
      models where each corresponding service can have an arbitrary=0A=
      number of senders.=0A=
=0A=
   - G:  denotes a multicast group.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                  [Page 5]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   - MDTunnel:  Multicast Distribution Tunnel, the means by which the=0A=
      customer's multicast traffic will be conveyed across the SP=0A=
      network.  This is meant in a generic way: such tunnels can be=0A=
      point-to-point, point-to-multipoint or multipoint-to-multipoint.=0A=
      Although this definition may seem to assume that distribution=0A=
      tunnels are unidirectional, the wording encompasses bi-directional=0A=
      tunnels as well.=0A=
=0A=
   - Multicast Channel:  In the multicast SSM (Source Specific=0A=
      Multicast) model [RFC4607], a "multicast channel" designates=0A=
      traffic from a specific source S to a multicast group G. Also=0A=
      denominated as "(S,G)".=0A=
=0A=
   - Multicast domain:  An area in which multicast data is transmitted.=0A=
      In this document, this term has a generic meaning which can refer=0A=
      to Layer-2 and Layer-3.  Generally, the Layer-3 multicast domain=0A=
      is determined by the Layer-3 multicast protocol used to establish=0A=
      reachability between all potential receivers in the corresponding=0A=
      domain.  The Layer-2 multicast domain can be the same as the=0A=
      Layer-2 broadcast domain (i.e., VLAN), but it may be restricted to=0A=
      being smaller than the Layer-2 broadcast domain if an additional=0A=
      control protocol is used.=0A=
=0A=
   - CE:  Customer Edge Device.=0A=
=0A=
   - PE:  Provider Edge.=0A=
=0A=
   - P:  Provider Router.=0A=
=0A=
   - S:  denotes a multicast source.=0A=
=0A=
   - SP:  Service Provider.=0A=
=0A=
   - SSM:  Source Specific Multicast.  One of the two multicast service=0A=
      models where each corresponding service relies upon the use of a=0A=
      single source.=0A=
=0A=
   - U-PE/N-PE:  The device closest to the customer/user is called User=0A=
      facing PE (U-PE) and the device closest to the core network is=0A=
      called Network facing PE (N-PE).=0A=
=0A=
   - VPLS instance:  A service entity manageable in VPLS architecture.=0A=
      All CE devices participating in a single VPLS instance appear to=0A=
      be on the same LAN, composing a VPN across the SP's network.  A=0A=
      VPLS instance corresponds to a group of VSIs that are=0A=
      interconnected using PWs (Pseudo Wires).=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                  [Page 6]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   - VSI:  Virtual Switching Instance.  VSI is a logical entity in a PE=0A=
      that maps multiple ACs (Attachment Circuits) to multiple PWs=0A=
      (Pseudo Wires).  The VSI is populated in much the same way as a=0A=
      standard bridge populates its forwarding table.  Each PE device=0A=
      may have multiple VSIs, where each VSI belongs to a different VPLS=0A=
      instance.=0A=
=0A=
2.2.  Conventions=0A=
=0A=
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A=
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A=
   document are to be interpreted as described in [RFC2119] .=0A=
=0A=
=0A=
3.  Problem Statements=0A=
=0A=
3.1.  Motivation=0A=
=0A=
   Today, many kinds of IP multicast services are becoming available.=0A=
   Over their Layer-2 VPN service, particularly over VPLS, customers=0A=
   would often like to operate their multicast applications to remote=0A=
   sites.  Also, VPN service providers using an IP-based networks expect=0A=
   that such Layer-2 network infrastructure will efficiently support=0A=
   multicast data traffic.=0A=
=0A=
   However, VPLS has a shortcoming as it relates to multicast=0A=
   scalability as mentioned below because of the replication mechanisms=0A=
   intrinsic to the original architecture.  Accordingly, the primary=0A=
   goal for technical solutions is to solve this issue partially or=0A=
   completely, and provide efficient ways to support IP multicast=0A=
   services over VPLS.=0A=
=0A=
3.2.  Multicast Scalability=0A=
=0A=
   In VPLS, replication occurs at an ingress PE (in H-VPLS case, at=0A=
   N-PE) when a CE sends (1) Broadcast, (2) Multicast or (3) Unknown=0A=
   destination unicast.  There are two well known issues with this=0A=
   approach:=0A=
=0A=
   Issue A: Replication to non-member site=0A=
=0A=
      In case (1) and (3), the upstream PE has to transmit packets to=0A=
      all of the downstream PEs which belong to the common VPLS=0A=
      instance.  You cannot decrease the number of members, so this is=0A=
      basically an inevitable situation for most VPLS deployments.=0A=
=0A=
      In case (2), however, there is an issue that multicast traffic is=0A=
      sent to sites with no members.  Usually this is caused when the=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                  [Page 7]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
      upstream PE does not maintain downstream membership information.=0A=
      The upstream PE simply floods frames to all downstream PEs, and=0A=
      the downstream PEs forward them to directly connected CEs;=0A=
      however, those CEs might not be the members of any multicast=0A=
      group.  From the perspective of customers, they might suffer from=0A=
      pressure on their own resources due to unnecessary traffic.  From=0A=
      the perspective of SPs, they would not like wasteful over-=0A=
      provisioning to cover such traffic.=0A=
=0A=
   Issue B: Replication of PWs on shared physical path=0A=
=0A=
      In VPLS, a VSI associated with each VPLS instance behaves as a=0A=
      logical emulated bridge which can transport Ethernet across the=0A=
      PSN backbone using PWs.  In principle, PWs are designed for=0A=
      unicast traffic.=0A=
=0A=
      In all cases (1), (2) and (3), Ethernet frames are replicated on=0A=
      one or more PWs that belong to that VSI.  This replication is=0A=
      often inefficient in terms of bandwidth usage if those PWs are=0A=
      traversing shared physical links in the backbone.=0A=
=0A=
      For instance, suppose there are 20 remote PEs belonging to a=0A=
      particular VPLS instance, and all PWs happen to be traversing over=0A=
      the same link from one local PE to its next-hop P. In this case,=0A=
      even if a CE sends 50Mbps to the local PE, the total bandwidth of=0A=
      that link will be to 1000Mbps.=0A=
=0A=
      Note that while traditional 802.1D Ethernet switches replicate=0A=
      broadcast/multicast flows once at most per output interface, VPLS=0A=
      often needs to transmit one or more flows duplicated over the same=0A=
      output interface.=0A=
=0A=
      From the perspective of customers, there is no serious issue=0A=
      because they do not know what happens in the core.  However, from=0A=
      the perspective of SPs, unnecessary replication brings the risk of=0A=
      resource exhaustion when the number of PWs increases.=0A=
=0A=
   In both issues A and B, these undesirable situations will become=0A=
   obvious with the wide-spread use of IP multicast applications by=0A=
   customers.  Naturally the problem will become more serious as the=0A=
   number of sites grows.  In other words, there are concerns over the=0A=
   scalability of multicast in VPLS today.=0A=
=0A=
3.3.  Application Considerations=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                  [Page 8]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
3.3.1.  Two Perspectives of the Service=0A=
=0A=
   When it comes to IP multicast over VPLS, there are two different=0A=
   aspects in terms of service provisioning.  They are closely related=0A=
   to the functional requirements from two technical standpoints:=0A=
   Layer-2 and Layer-3.=0A=
=0A=
   - Native Ethernet service aspect=0A=
=0A=
      This aspect mainly affects Ethernet network service operators.=0A=
      Their main interest is to solve the issue that existing VPLS=0A=
      deployments cannot always handle multicast/broadcast frames=0A=
      efficiently.=0A=
=0A=
      Today, wide-area Ethernet services are becoming popular, and VPLS=0A=
      can be utilized to provide wide-area LAN services.  As customers=0A=
      come to use various kinds of content distribution applications=0A=
      which use IP multicast (or other protocols which lead to=0A=
      multicast/broadcast in the Ethernet layer), the total amount of=0A=
      traffic will also grow.  In addition, considerations of OAM,=0A=
      security and other related points in multicast in view of Layer-2=0A=
      are important as well.=0A=
=0A=
      In such circumstances, the native VPLS specification would not=0A=
      always be satisfactory if multicast traffic is more dominant in=0A=
      total resource utilization than before.  The scalability issues=0A=
      mentioned in the previous section are expected to be solved.=0A=
=0A=
   - IP multicast service aspect=0A=
=0A=
      This aspect mainly affects both IP service providers and end=0A=
      users.  Their main interest is to provide IP multicast services=0A=
      transparently but effectively by means of VPLS as a network=0A=
      infrastructure.=0A=
=0A=
      SPs might expect VPLS as an access/metro network to deliver=0A=
      multicast traffic (such as Triple-play (Video, Voice, Data) and=0A=
      Multicast IP VPNs) in an efficient way.=0A=
=0A=
=0A=
4.  General Requirements=0A=
=0A=
   We assume the basic requirements for VPLS written in [RFC4665] are=0A=
   fulfilled if there is no special reference in this document.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                  [Page 9]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
4.1.  Scope of Transport=0A=
=0A=
4.1.1.  Traffic Types=0A=
=0A=
4.1.1.1.  Multicast and Broadcast=0A=
=0A=
   As described before, any solution is expected to have mechanisms for=0A=
   efficient transport of IP multicast.  Multicast is related to both=0A=
   issues A and B (see section 3.2.); however, broadcast is related to=0A=
   issue B only because it does not need membership control.=0A=
=0A=
   -  A multicast VPLS solution SHOULD attempt to solve both issues (A)=0A=
      and (B), if possible.  However, since some applications prioritize=0A=
      solving one issue over the other, the solution MUST identify which=0A=
      issue (A or B) it is attempting to solve.  The solution SHOULD=0A=
      provide a basis for evaluating how well it solves the issue(s) it=0A=
      is targeting, if it is providing an approximate solution.=0A=
=0A=
4.1.1.2.  Unknown Destination Unicast=0A=
=0A=
   Unknown destination MAC unicast requires flooding, but its=0A=
   characteristics are quite different from multicast/broadcast.  When=0A=
   the unicast MAC address is learned, the PE changes its forwarding=0A=
   behavior from flooding over all PWs into sending over one PW.=0A=
   Thereby it will require different technical studies from multicast/=0A=
   broadcast, which is out of scope of this document.=0A=
=0A=
4.1.2.  Multicast Packet Types=0A=
=0A=
   Ethernet multicast is used for conveying Layer-3 multicast data.=0A=
   When IP multicast is encapsulated by an Ethernet frame, the IP=0A=
   multicast group address is mapped to the Ethernet destination MAC=0A=
   address.  In IPv4, the mapping uses the lower 23 bits of the (32bit)=0A=
   IPv4 multicast address and places them as the lower 23 bits of a=0A=
   destination MAC address with the fixed header of 01-00-5E in hex.=0A=
   Since this mapping is ambiguous (i.e., there is a multiplicity of 1=0A=
   Ethernet address to 32 IPv4 addresses), MAC-based forwarding is not=0A=
   ideal for IP multicast because some hosts might possibly receive=0A=
   packets they are not interested in, which is inefficient in traffic=0A=
   delivery and has an impact on security.  On the other hand, if the=0A=
   solution tracks IP addresses rather than MAC addresses, this concern=0A=
   can be prevented.  The drawback of this approach is, however, that=0A=
   the network administration becomes slightly more complicated.=0A=
=0A=
   Ethernet multicast is also used for Layer-2 control frames.  For=0A=
   example, BPDU (Bridge Protocol Data Unit) for IEEE 802.1D Spanning=0A=
   Tree uses a multicast destination MAC address (01-80-C2-00-00-00).=0A=
   Also some of IEEE 802.1ag [802.1ag] Connectivity Fault Management=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 10]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   (CFM) messages use a multicast destination MAC address dependent on=0A=
   their message type and application.  From the perspective of IP=0A=
   multicast, however, it is necessary in VPLS to flood such control=0A=
   frames to all participating CEs, without requiring any membership=0A=
   controls.=0A=
=0A=
   As for a multicast VPLS solution, it can only use Ethernet-related=0A=
   information, if you stand by the strict application of the basic=0A=
   requirement: "a L2VPN service SHOULD be agnostic to customer's Layer=0A=
   3 traffic [RFC4665]."  This means no Layer-3 information should be=0A=
   checked for transport.  However, it is obvious this is an impediment=0A=
   to solve Issue A.=0A=
=0A=
   Consequently, a multicast VPLS can be allowed to make use of some=0A=
   Layer-3-related supplementary information in order to improve=0A=
   transport efficiency.  In fact, today's LAN switch implementations=0A=
   often support such approaches and snoop upper layer protocols and=0A=
   examine IP multicast memberships (e.g., PIM snooping and IGMP/MLD=0A=
   snooping [RFC4541]).  This will implicitly suggest that VPLS may=0A=
   adopt similar techniques although this document does NOT state=0A=
   Layer-3 snooping is mandatory.  If such an approach is taken, careful=0A=
   consideration of Layer-3 state maintenance is necessary.  In=0A=
   addition, note that snooping approaches sometimes have disadvantages=0A=
   in the system's transparency; that is, one particular protocol's=0A=
   snooping solution might hinder other (especially future) protocol's=0A=
   working (e.g., an IGMPv2-snooping switch vs. a new IGMPv3-snooping=0A=
   one).  Also, note that there are potential alternatives to snooping:=0A=
   -  Static configuration of multicast Ethernet addresses and ports/=0A=
      interfaces=0A=
   -  Multicast control protocol based on Layer-2 technology which=0A=
      signals mappings of multicast addresses to ports/interfaces, such=0A=
      as GARP/GMRP[802.1D], CGMP[CGMP] and RGMP[RFC3488].=0A=
=0A=
   On the basis described above, general requirements about packet types=0A=
   are given as follows:=0A=
=0A=
   -  A solution SHOULD support a way to facilitate IP multicast=0A=
      forwarding of the customers.  It MAY observe Layer-3 information=0A=
      (i.e., multicast routing protocols and state) to the degree=0A=
      necessary, but any information irrelevant to multicast transport=0A=
      SHOULD NOT be consulted.=0A=
=0A=
   -  In a solution, Layer-2 control frames (e.g., BPDU, 802.1ag CFM)=0A=
      SHOULD be flooded to all PE/CEs in a common VPLS instance.  A=0A=
      solution SHOULD NOT change or limit the flooding scope to remote=0A=
      PE/CEs in terms of end-point reachability.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 11]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   -  In a solution, Layer-2 frames that encapsulate Layer-3 multicast=0A=
      control packets (e.g., PIM, IGMP(for IPv4), MLD(for IPv6)) MAY be=0A=
      flooded only to relevant members, with the goal of limiting=0A=
      flooding scope.  However, Layer-2 frames that encapsulate other=0A=
      Layer-3 control packets (e.g., OSPF, ISIS) SHOULD be flooded to=0A=
      all PE/CEs in a VPLS instance.=0A=
=0A=
4.1.3.  MAC Learning Consideration=0A=
=0A=
   In a common VPLS architecture, MAC learning is carried out by PEs=0A=
   based on the incoming frame's source MAC address, independently of=0A=
   the destination MAC address (i.e., regardless of whether it is=0A=
   unicast, multicast or broadcast).  This is the case with multicast=0A=
   VPLS solution's environment too.  In this document, the improvement=0A=
   of MAC learning scalability is beyond the scope.  It will be covered=0A=
   in the future work.=0A=
=0A=
4.2.  Static Solutions=0A=
=0A=
   A solution SHOULD allow static configuration to account for various=0A=
   operator policies, where the logical multicast topology does not=0A=
   change dynamically in conjunction with a customer's multicast=0A=
   routing.=0A=
=0A=
4.3.  Backward Compatibility=0A=
=0A=
   A solution SHOULD be backward compatible with the existing VPLS=0A=
   solution.  It SHOULD allow a case where a common VPLS instance is=0A=
   composed of both PEs supporting the solution and PEs not supporting=0A=
   it, and the multicast optimization (both forwarding and receiving) is=0A=
   achieved between the compliant PEs.=0A=
=0A=
   Note again that the existing VPLS solutions already have a simple=0A=
   flooding capability.  Thus this backward compatibility will give=0A=
   customers and SPs the improved efficiency of multicast forwarding=0A=
   incrementally as the solution is deployed.=0A=
=0A=
=0A=
5.  Customer Requirements=0A=
=0A=
5.1.  CE-PE protocol=0A=
=0A=
5.1.1.  Layer-2 Aspect=0A=
=0A=
   A solution SHOULD allow transparent operation of Ethernet control=0A=
   protocols employed by customers (e.g.  Spanning Tree Protocol=0A=
   [802.1D]) and their seamless operation with multicast data transport.=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 12]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   Solutions MAY examine Ethernet multicast control frames for the=0A=
   purpose of efficient dynamic transport (e.g.  GARP/GMRP [802.1D]).=0A=
   However, solutions MUST NOT assume all CEs are always running such=0A=
   protocols (typically in the case where a CE is a router and is not=0A=
   aware of Layer-2 details).=0A=
=0A=
   A whole Layer-2 multicast frame (whether for data or control) SHOULD=0A=
   NOT be altered from a CE to CE(s) EXCEPT for the VLAN Id field,=0A=
   ensuring that it is transparently transported.  If VLAN Ids are=0A=
   assigned by the SP, they can be altered.  Note, however, when VLAN=0A=
   Ids are changed, Layer-2 protocols may be broken in some cases, such=0A=
   as Multiple Spanning Tree [802.1s].  Also if the Layer-2 frame is=0A=
   encapsulating Layer-3 multicast control packet (e.g., PIM/IGMP) and=0A=
   customers allow it to be regenerated at PE (aka proxy: see section=0A=
   5.1.2.), then the MAC address for that frame MAY be altered to the=0A=
   minimum necessary (e.g., use PE's own MAC address as a source).=0A=
=0A=
5.1.2.  Layer-3 Aspect=0A=
=0A=
   Again, a solution MAY examine customer's Layer-3 multicast protocol=0A=
   packets for the purpose of efficient and dynamic transport.  If it=0A=
   does, supported protocols SHOULD include:=0A=
=0A=
   o  PIM-SM [RFC4601], PIM-SSM [RFC4607], bidirectional PIM [RFC5015]=0A=
      and PIM-DM [RFC3973]=0A=
   o  IGMP (v1[RFC1112], v2[RFC2236] and v3[RFC3376]) (for IPv4=0A=
      solutions)=0A=
   o  Multicast Listener Discovery Protocol (MLD) (v1[RFC2710] and=0A=
      v2[RFC3810]) (for IPv6 solutions).=0A=
=0A=
   A solution MUST NOT require any special Layer-3 multicast protocol=0A=
   packet processing by the end users.  However, it MAY require some=0A=
   configuration changes (e.g., turning explicit tracking on/off in=0A=
   PIM).=0A=
=0A=
   A whole Layer-3 multicast packet (whether for data or control), which=0A=
   is encapsulated inside a Layer-2 frame, SHOULD NOT be altered from a=0A=
   CE to CE(s), ensuring that it is transparently transported.  However,=0A=
   as for Layer-3 multicast control (like PIM Join/Prune/Hello and IGMP=0A=
   Query/Report packet), it MAY be altered to the minimum necessary if=0A=
   such partial non-transparency is acceptable from point of view of the=0A=
   multicast service.  Similarly, a PE MAY consume such Layer-3=0A=
   multicast control packets and regenerate an entirely new packet if=0A=
   partial non-transparency is acceptable with legitimate reason for=0A=
   customers (aka proxy).=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 13]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
5.2.  Multicast Domain=0A=
=0A=
   As noted in Section 2.1., the term "multicast domain" is used in a=0A=
   generic context for Layer-2 and Layer-3.=0A=
=0A=
   A solution SHOULD NOT alter customer multicast domains' boundaries.=0A=
   It MUST ensure that the provided Ethernet multicast domain always=0A=
   encompasses the corresponding customer Layer-3 multicast domain.=0A=
=0A=
   A solution SHOULD optimize those domains' coverage sizes, i.e., a=0A=
   solution SHOULD ensure that unnecessary traffic is not sent to CEs=0A=
   with no members.  Ideally, the provided domain size will be close to=0A=
   that of the customer's Layer-3 multicast membership distribution;=0A=
   however, it is OPTIONAL to achieve such absolute optimality from the=0A=
   perspective of Layer-3.=0A=
=0A=
   If a customer uses VLANs and a VLAN Id as a service delimiter (i.e.,=0A=
   each VPLS instance is represented by a unique customer VLAN tag=0A=
   carried by a frame through the UNI port), a solution MUST support=0A=
   separate multicast domains per VLAN Id.  Note that if VLAN Id=0A=
   translation is provided (i.e., if a customer VLAN at one site is=0A=
   mapped into a different customer VLAN at a different site), multicast=0A=
   domains will be created per set of VLAN Ids which are associated with=0A=
   translation.=0A=
=0A=
   If a customer uses VLANs but a VLAN Id is not a service delimiter=0A=
   (i.e., the VPN disregards customer VLAN Ids), a solution MAY provide=0A=
   separate multicast domains per VLAN Id.  A SP is not required to=0A=
   provide separate multicast domains per VLAN IDs, but it may be=0A=
   considered beneficial to do so.=0A=
=0A=
   A solution MAY build multicast domains based on Ethernet MAC=0A=
   addresses.  It MAY also build multicast domains based on the IP=0A=
   addresses inside Ethernet frames.  That is, PEs in each VPLS instance=0A=
   might control forwarding behavior and provide different multicast=0A=
   frame reachability depending on each MAC/IP destination address=0A=
   separately.  If IP multicast channels are fully considered in a=0A=
   solution, the provided domain size will be closer to actual channel=0A=
   reachability.=0A=
=0A=
5.3.  Quality of Service (QoS)=0A=
=0A=
   Customers require that multicast quality of service MUST be at least=0A=
   on par with what exists for unicast traffic.  Moreover, as multicast=0A=
   is often used to deliver high quality services such as TV broadcast,=0A=
   delay/jitter/loss sensitive traffic MUST be supported over multicast=0A=
   VPLS.=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 14]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   To accomplish this, the solution MAY have additional features to=0A=
   support high QoS such as bandwidth reservation and flow admission=0A=
   control.  Also multicast VPLS deployment SHALL benefit from IEEE=0A=
   802.1p CoS techniques [802.1D] and DiffServ [RFC2475] mechanisms.=0A=
=0A=
   Moreover, multicast traffic SHOULD NOT affect the QoS that unicast=0A=
   traffic receives and vice versa.  That is, separation of multicast=0A=
   and unicast traffic in terms of QoS is necessary.=0A=
=0A=
5.4.  SLA Parameters Measurement=0A=
=0A=
   Since SLA parameters are part of the service sold to customers, they=0A=
   simply want to verify their application performance by measuring the=0A=
   parameters SP(s) provide.=0A=
=0A=
   Multicast specific characteristics that may be monitored are, for=0A=
   instance, multicast statistics per stream (e.g. total/incoming/=0A=
   outgoing/dropped traffic by period of time), one-way delay, jitter=0A=
   and group join/leave delay (time to start receiving traffic from a=0A=
   multicast group across the VPN since join/leave was issued).  An=0A=
   operator may also wish to compare the difference in one-way delay for=0A=
   a solitary multicast group/stream from a single, source PE to=0A=
   multiple receiver PEs.=0A=
=0A=
   A solution SHOULD provide these parameters with Ethernet multicast=0A=
   group level granularity.  (For example, multicast MAC address will be=0A=
   one of those entries for classifying flows with statistics, delay and=0A=
   so on.)  However, if a solution is aimed at IP multicast transport=0A=
   efficiency, it MAY support IP multicast level granularity.  (For=0A=
   example, multicast IP address/channel will be entries for latency=0A=
   time.)=0A=
=0A=
   In order to monitor them, standard interfaces for statistics=0A=
   gathering SHOULD also be provided (e.g., standard SNMP MIB Modules).=0A=
=0A=
5.5.  Security=0A=
=0A=
   A solution MUST provide customers with architectures that give the=0A=
   same level of security both for unicast and multicast.=0A=
=0A=
5.5.1.  Isolation from Unicast=0A=
=0A=
   Solutions SHOULD NOT affect any forwarding information base,=0A=
   throughput or resiliency etc. of unicast frames; that is, they SHOULD=0A=
   provide isolation from unicast.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 15]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
5.5.2.  Access Control=0A=
=0A=
   A solution MAY filter multicast traffic inside a VPLS, upon the=0A=
   request of an individual customer, (for example, MAC/VLAN filtering,=0A=
   IP multicast channel filtering, etc.).=0A=
=0A=
5.5.3.  Policing and Shaping on Multicast=0A=
=0A=
   A solution SHOULD support policing and shaping multicast traffic on a=0A=
   per customer basis and on a per AC (Attachment Circuit) basis.  This=0A=
   is intended to prevent multicast traffic from exhausting resources=0A=
   for unicast inside a common customer's VPN.  This might also be=0A=
   beneficial for QoS separation (see section 5.3).=0A=
=0A=
5.6.  Access Connectivity=0A=
=0A=
   First and foremost various physical connectivity types described in=0A=
   [RFC4665] MUST be supported.=0A=
=0A=
5.7.  Multi-Homing=0A=
=0A=
   A multicast VPLS MUST allow a situation in which a CE is dual-homed=0A=
   to two different SPs via diverse access networks -- one is supporting=0A=
   multicast VPLS but the other is not supporting it, (because it is an=0A=
   existing VPLS or 802.1Q/QinQ network).=0A=
=0A=
5.8.  Protection and Restoration=0A=
=0A=
   A multicast VPLS infrastructure SHOULD allow redundant paths to=0A=
   assure high availability.=0A=
=0A=
   Multicast forwarding restoration time MUST NOT be greater than the=0A=
   time it takes a customer's Layer-3 multicast protocols to detect a=0A=
   failure in the VPLS infrastructure.  For example, if a customer uses=0A=
   PIM with default configuration, hello hold timer is 105 seconds, and=0A=
   solutions are required to restore a failure no later than this=0A=
   period.  To achieve this, a solution might need to support providing=0A=
   alternative multicast paths.=0A=
=0A=
   Moreover, if multicast forwarding was not successfully restored=0A=
   (e.g., in case of no redundant paths), a solution MAY raise alarms to=0A=
   provide outage notification to customers before such a hold timer=0A=
   expires.=0A=
=0A=
5.9.  Minimum MTU=0A=
=0A=
   Multicast applications are often sensitive to packet fragmentation=0A=
   and reassembly, so the requirement to avoid fragmentation might be=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 16]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   stronger than the existing VPLS solution.=0A=
=0A=
   A solution SHOULD provide customers with enough committed minimum MTU=0A=
   (i.e., service MTU) for multicast Ethernet frames to ensure that IP=0A=
   fragmentation between customer sites never occurs.  It MAY give=0A=
   different MTU sizes to multicast and unicast.=0A=
=0A=
5.10.  Frame Reordering Prevention=0A=
=0A=
   A solution SHOULD attempt to prevent frame reordering when delivering=0A=
   customer multicast traffic.  Likewise, for unicast and unknown=0A=
   unicast traffic, it SHOULD attempt not to increase the likelihood of=0A=
   reordering compared with existing VPLS solutions.=0A=
=0A=
   It is to be noted that delivery of out-of-order frames is not=0A=
   avoidable in certain cases.  Specifically if a solution adopts some=0A=
   MDTunnels (see section 6.2.1) and dynamically selects them for=0A=
   optimized delivery (e.g., switching from one aggregate tree to=0A=
   another), end-to-end data delivery is prone to be out-of-order.  This=0A=
   fact can be considered a trade-off between bandwidth optimization and=0A=
   network stability.  Therefore, such a solution is expected to promote=0A=
   awareness about this kind of drawback.=0A=
=0A=
5.11.  Fate-Sharing between Unicast and Multicast=0A=
=0A=
   In native Ethernet, multicast and unicast connectivity are often=0A=
   managed together.  For instance, 802.1ag CFM Continuity Check message=0A=
   is forwarded by multicast as a periodic heartbeat, but it is supposed=0A=
   to check the "whole" traffic continuity regardless of unicast or=0A=
   multicast, at the same time.  Hence, the aliveness of unicast and=0A=
   multicast is naturally coupled (i.e., fate-shared) in this customer's=0A=
   environment.=0A=
=0A=
   A multicast VPLS solution may decouple the path that a customer's=0A=
   unicast and multicast traffic follow through a SP's backbone, in=0A=
   order to provide the most optimal path for multicast data traffic.=0A=
   This may cause concern among some multicast VPLS customers who desire=0A=
   that, during a failure in the SP's network, both unicast and=0A=
   multicast traffic fail concurrently.=0A=
=0A=
   Therefore, there will be an additional requirement that makes both=0A=
   unicast and multicast connectivity coupled.  This means that if=0A=
   either one of them have a failure, the other is also disabled.  If=0A=
   one of the services (either unicast or multicast) becomes=0A=
   operational, the other is also activated simultaneously.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 17]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   -  It SHOULD be identified if the solution can provide customers with=0A=
      fate-sharing between unicast and multicast connectivity for their=0A=
      LAN switching application.  It MAY have a configurable mechanism=0A=
      for SPs to provide that on behalf of customers, e.g., aliveness=0A=
      synchronization, but its use is OPTIONAL.=0A=
=0A=
   This policy will benefit customers.  Some customers would like to=0A=
   detect failure soon at CE side and restore full connectivity by=0A=
   switching over to their backup line, rather than to keep poor half=0A=
   connectivity (i.e., either unicast or multicast being in fail).  Even=0A=
   if either unicast or multicast is kept alive, it is just=0A=
   disadvantageous to the customer's application protocols which need=0A=
   both traffic.  Fate-sharing policy contributes to prevent such a=0A=
   complicated situation.=0A=
=0A=
   Note that how serious this issue is depends on each customer's stance=0A=
   in Ethernet operation.  If all CEs are IP routers i.e., if VPLS is=0A=
   provided for LAN routing application, the customer might not care=0A=
   about it because both unicast and multicast connectivity is assured=0A=
   in IP layer.  If the CE routers are running an IGP (e.g., OSPF/IS-IS)=0A=
   and a multicast routing protocol (e.g., PIM), then aliveness of both=0A=
   the unicast and multicast paths will be detected by the CEs.  This=0A=
   does not guarantee that unicast and multicast traffic are to follow=0A=
   the same path in the SP's backbone network, but does mitigate this=0A=
   issue to some degree.=0A=
=0A=
=0A=
6.  Service Provider Network Requirements=0A=
=0A=
6.1.  Scalability=0A=
=0A=
   The existing VPLS architecture has major advantages in scalability.=0A=
   For example, P-routers are free from maintaining customers'=0A=
   information because customer traffic is encapsulated in PSN tunnels.=0A=
   Also a PW's split-horizon technique can prevent loops, making PE=0A=
   routers free from maintaining complicated spanning trees.=0A=
=0A=
   However, a multicast VPLS needs additional scalability considerations=0A=
   related to its expected enhanced mechanisms.  [RFC3809] lists common=0A=
   L2VPN sizing and scalability requirements and metrics, which are=0A=
   applicable in multicast VPLS too.  Accordingly, this section deals=0A=
   with specific requirements related to scalability.=0A=
=0A=
6.1.1.  Trade-off of Optimality and State Resource=0A=
=0A=
   A solution needs to improve the scalability of multicast as is shown=0A=
   in section 3:=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 18]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
      Issue A: Replication to non-member site.=0A=
      Issue B: Replication of PWs on shared physical path.=0A=
=0A=
   For both issues, the optimization of physical resources (i.e. link=0A=
   bandwidth usage and router duplication performance) will become a=0A=
   major goal.  However, there is a trade-off between optimality and=0A=
   state resource consumption.=0A=
=0A=
   In order to solve Issue A, a PE might have to maintain multicast=0A=
   group information for CEs which was not kept in the existing VPLS=0A=
   solutions.  This will present scalability concerns about state=0A=
   resources (memory, CPU, etc.) and their maintenance complexity.=0A=
=0A=
   In order to solve Issue B, PE and P routers might have to have=0A=
   knowledge of additional membership information for remote PEs, and=0A=
   possibly additional tree topology information, when they are using=0A=
   point-to-multipoint techniques (PIM tree, P2MP-LSP, etc.).=0A=
=0A=
   Consequently, the scalability evaluation of multicast VPLS solutions=0A=
   needs a careful trade-off analysis between bandwidth optimality and=0A=
   state resource consumption.=0A=
=0A=
6.1.2.  Key Metrics for Scalability=0A=
=0A=
      (Note: This part has a number of similar characteristics to=0A=
      requirements for Layer 3 Multicast VPN [RFC4834].)=0A=
=0A=
   A multicast VPLS solution MUST be designed to scale well with an=0A=
   increase in the number of any of the following metrics:=0A=
=0A=
   -  the number of PEs=0A=
   -  the number of VPLS instances (total and per PE)=0A=
   -  the number of PEs and sites in any VPLS instance=0A=
   -  the number of client VLAN Ids=0A=
   -  the number of client Layer-2 MAC multicast groups=0A=
   -  the number of client Layer-3 multicast channels (groups or source-=0A=
      groups)=0A=
   -  the number of PWs and PSN Tunnels (MDTunnels) (total and per PE)=0A=
=0A=
   Each multicast VPLS solution SHALL document its scalability=0A=
   characteristics in quantitative terms.  A solution SHOULD quantify=0A=
   the amount of state that a PE and a P device has to support.=0A=
=0A=
   The scalability characteristics SHOULD include:=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 19]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   -  the processing resources required by the control plane in managing=0A=
      PWs (neighborhood or session maintenance messages, keepalives,=0A=
      timers, etc.)=0A=
   -  the processing resources required by the control plane in managing=0A=
      PSN tunnels=0A=
   -  the memory resources needed for the control plane=0A=
   -  the amount of protocol information transmitted to manage a=0A=
      multicast VPLS (e.g. signaling throughput)=0A=
   -  the amount of Layer-2/Layer-3 multicast information a P/PE router=0A=
      consumes (e.g. traffic rate of join/leave, keepalives etc.)=0A=
   -  the number of multicast IP addresses used (if IP multicast in ASM=0A=
      mode is proposed as a multicast distribution tunnel)=0A=
   -  other particular elements inherent to each solution that impact=0A=
      scalability=0A=
=0A=
   Another metric for scalability is operational complexity.  Operations=0A=
   will naturally become more complicated if the number of managed=0A=
   objects (e.g., multicast groups) increases, or the topology changes=0A=
   occur more frequently.  A solution SHOULD note the factors which lead=0A=
   to additional operational complexity.=0A=
=0A=
6.2.  Tunneling Requirements=0A=
=0A=
6.2.1.  Tunneling Technologies=0A=
=0A=
   A MDTunnel denotes a multicast distribution tunnel.  This is a=0A=
   generic term for tunneling where customer multicast traffic is=0A=
   carried over a provider's network.  In the L2VPN service context, it=0A=
   will correspond to a PSN tunnel.=0A=
=0A=
   A solution SHOULD be able to use a range of tunneling technologies,=0A=
   including point-to-point (unicast oriented) and point-to-multipoint/=0A=
   multipoint-to-multipoint (multicast oriented).  For example, today=0A=
   there are many kinds of protocols for tunneling such as L2TP, IP,=0A=
   (including multicast IP trees), MPLS (including P2MP-LSP [RFC4875]=0A=
   and P2MP/MP2MP-LSP [I-D.ietf-mpls-ldp-p2mp] ), etc.=0A=
=0A=
   Note that which variant, point-to-point, point-to-multipoint or=0A=
   multipoint-to-multipoint, is used depends largely on the trade-offs=0A=
   mentioned above and the targeted network and applications.=0A=
   Therefore, this document does not mandate any specific protocols.  A=0A=
   solution, however, SHOULD state reasonable criteria if it adopts a=0A=
   specific kind of tunneling protocol.=0A=
=0A=
6.2.2.  MTU of MDTunnel=0A=
=0A=
   From the view of a SP, it is not acceptable to have fragmentation/=0A=
   reassembly so often while packets are traversing a MDTunnel.=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 20]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   Therefore, a solution SHOULD support a method that provides the=0A=
   minimum path MTU of the MDTunnel in order to accommodate the service=0A=
   MTU.=0A=
=0A=
6.3.  Robustness=0A=
=0A=
   Multicast VPLS solutions SHOULD avoid single points of failures or=0A=
   propose technical solutions that make it possible to implement a=0A=
   failover mechanism.=0A=
=0A=
6.4.  Discovering Related Information=0A=
=0A=
   The operation of a multicast VPLS solution SHALL be as light as=0A=
   possible and providing automatic configuration and discovery SHOULD=0A=
   be considered a high priority.=0A=
=0A=
   Therefore, in addition to the L2VPN discovery requirements in=0A=
   [RFC4665], a multicast VPLS solution SHOULD provide a method that=0A=
   dynamically allows multicast membership information to be discovered=0A=
   by PEs if the solution supports (A), as defined in section 3.2.  This=0A=
   means, a PE needs to discover multicast membership (e.g., join group=0A=
   addresses) that is controlled dynamically from the sites connected to=0A=
   that PE.  In addition, a PE needs to discover such information=0A=
   automatically from other remote PEs as well in order to limit=0A=
   flooding scope across the backbone.=0A=
=0A=
6.5.  Operation, Administration and Maintenance=0A=
=0A=
6.5.1.  Activation=0A=
=0A=
   The activation of multicast enhancement in a solution MUST be=0A=
   possible:=0A=
=0A=
   o  with a VPLS instance granularity=0A=
   o  with an Attachment Circuit granularity (i.e., with a PE-CE=0A=
      Ethernet port granularity, or with a VLAN Id granularity when it=0A=
      is a service delimiter)=0A=
=0A=
   Also it SHOULD be possible:=0A=
=0A=
   o  with a CE granularity (when multiple CEs of a same VPN are=0A=
      associated with a common VPLS instance)=0A=
   o  with a distinction between multicast reception and emission=0A=
   o  with a multicast MAC address granularity=0A=
   o  with a customer IP multicast group and/or channel granularity=0A=
      (when Layer-3 information is consulted)=0A=
=0A=
   Also it MAY be possible:=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 21]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   o  with a VLAN Id granularity when it is not a service delimiter=0A=
=0A=
6.5.2.  Testing=0A=
=0A=
   A solution MUST provide a mechanism for testing multicast data=0A=
   connectivity and verifying the associated information.  Examples that=0A=
   SHOULD be supported which are specific to multicast are:=0A=
=0A=
   -  Testing connectivity per multicast MAC address=0A=
   -  Testing connectivity per multicast Layer-3 group/channel=0A=
   -  Verifying data plane and control plane integrity (e.g.  PW,=0A=
      MDTunnel)=0A=
   -  Verifying multicast membership-relevant information (e.g.=0A=
      multicast MAC-addresses/PW-ports associations, Layer-3 group=0A=
      associations)=0A=
=0A=
   Operators usually want to test if an end-to-end multicast user's=0A=
   connectivity is OK before and after activation.  Such end-to-end=0A=
   multicast connectivity checking SHOULD enable the end-to-end testing=0A=
   of the data path used by that customer's multicast data packets.=0A=
   Specifically, end-to-end checking will have CE-to-CE path test and=0A=
   PE-to-PE path test.  A solution MUST support PE-to-PE path test and=0A=
   MAY support CE-to-CE path test.=0A=
=0A=
   Also operators will want to make use of a testing mechanism for=0A=
   diagnosis and troubleshooting.  In particular, a solution SHOULD be=0A=
   able to monitor information describing how client multicast traffic=0A=
   is carried over the SP network.  Note that if a solution supports=0A=
   frequent dynamic membership changes with optimized transport,=0A=
   troubleshooting within the SP's network will tend to be difficult.=0A=
=0A=
6.5.3.  Performance Management=0A=
=0A=
   Mechanisms to monitor multicast specific parameters and statistics=0A=
   MUST be offered to the SP.=0A=
=0A=
      (Note: This part has a number of similar characteristics to=0A=
      requirements for Layer 3 Multicast VPN [RFC4834].)=0A=
=0A=
   A solution MUST provide SPs with access to:=0A=
=0A=
   -  Multicast traffic statistics (total traffic forwarded, incoming,=0A=
      outgoing, dropped, etc., by period of time)=0A=
=0A=
   A solution SHOULD provide access to:=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 22]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   -  Information about a customer's multicast resource usage (the=0A=
      amount of multicast state and throughput)=0A=
   -  Performance information related to multicast traffic usage, e.g.,=0A=
      one-way delay, jitter, loss, delay variations (the difference in=0A=
      one-way delay for a solitary multicast group/stream from a single,=0A=
      source PE to multiple receiver PEs) etc.=0A=
   -  Alarms when limits are reached on such resources=0A=
   -  Statistics on decisions related to how client traffic is carried=0A=
      on MDTunnels (e.g.  "How much traffic was switched onto a=0A=
      multicast tree dedicated to such groups or channels")=0A=
   -  Statistics on parameters that could help the provider to evaluate=0A=
      its optimality/state trade-off=0A=
=0A=
   All or part of this information SHOULD be made available through=0A=
   standardized SNMP MIB Modules (Management Information Base).=0A=
=0A=
6.5.4.  Fault Management=0A=
=0A=
   A multicast VPLS solution needs to consider those management steps=0A=
   taken by SPs below:=0A=
=0A=
   o  Fault detection=0A=
         A solution MUST provide tools that detect group membership/=0A=
         reachability failure and traffic looping for multicast=0A=
         transport.  It is anticipated that such tools are coordinated=0A=
         with the testing mechanisms mentioned in 6.5.2.=0A=
=0A=
         In particular, such mechanisms SHOULD be able to detect a=0A=
         multicast failure quickly, (on par with unicast cases).  It=0A=
         SHOULD also avoid situations where multicast traffic has been=0A=
         in a failure state for a relatively long time while unicast=0A=
         traffic remains operational.  If such a situation were to=0A=
         occur, it would end up causing problems with customer=0A=
         applications that depend on a combination of unicast and=0A=
         multicast forwarding.=0A=
=0A=
         With multicast, there may be many receivers associated with a=0A=
         particular mulitcast stream/group.  As the number of receivers=0A=
         increases, the number of places (typically nearest the=0A=
         receivers) required to detect a fault will increase=0A=
         proportionately.  This raises concerns over the scalability of=0A=
         fault detection in large multicast deployments.  Consequently,=0A=
         a fault detection solution SHOULD scale well; in particular, a=0A=
         solution should consider key metrics for scalability as=0A=
         described in section 6.1.2.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 23]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   o  Fault notification=0A=
         A solution MUST also provide fault notification and trouble=0A=
         tracking mechanisms. (e.g.  SNMP-trap and syslog.)=0A=
=0A=
         In case of multicast, one point of failure often affects a=0A=
         number of downstream routers/receivers that might be able to=0A=
         raise a notification.  Hence notification messages MAY be=0A=
         summarized or compressed for operators' ease of management.=0A=
=0A=
   o  Fault isolation=0A=
         A solution MUST provide diagnostic/troubleshooting tools for=0A=
         multicast as well.  Also it is anticipated that such tools are=0A=
         coordinated with the testing mechanisms mentioned in 6.5.2.=0A=
=0A=
         In particular, a solution needs to correctly identify the area=0A=
         inside a multicast group impacted by the failure.  A solution=0A=
         SHOULD be able to diagnose if an entire multicast group is=0A=
         faulty or if some specific destinations are still alive.=0A=
=0A=
6.6.  Security=0A=
=0A=
6.6.1.  Security Threat Analysis=0A=
=0A=
   In multicast VPLS, there is a concern that one or more customer nodes=0A=
   (presumably untrusted) might cause multicast-related attacks to the=0A=
   SP network.  There is a danger that it might compromise some=0A=
   components which belong to the whole system.=0A=
=0A=
   This subsection states possible security threats relevant to the=0A=
   system and which are protected against and which are not.=0A=
=0A=
   General security consideration about a base VPLS (as part of L2VPNs)=0A=
   is referred to [RFC4665].  Following is the threat analysis list=0A=
   which is inherent to multicast VPLS.=0A=
=0A=
   (a)  Attack by huge amount of multicast control packets.=0A=
      There is a threat that a CE joins too many multicast groups and=0A=
      causes Denial of Service (DoS).  This is caused by sending a large=0A=
      number of packets join/prune messages in short time and/or putting=0A=
      a large variety of group addresses in join/prune messages.  This=0A=
      attack will waste PE's control resources (e.g., CPU, memory) which=0A=
      examine customer control messages (for solving issue A in section=0A=
      3.2.) and it will not continue expected services for other trusted=0A=
      customers.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 24]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   (b)  Attack by invalid/malformed multicast control packets.=0A=
      There is a threat that a CE sends invalid or malformed control=0A=
      packets that might corrupt PE, which will cause DoS attack.  In=0A=
      particular, a CE might be spoofing legitimate source/group IP=0A=
      multicast addresses in such control packets (in PIM, IGMP etc.)=0A=
      and source/destination MAC addresses as Layer 2 frame.=0A=
=0A=
   (c)  Attack by rapid state change of multicast.=0A=
      If a malicious CE changes multicast state by sending control=0A=
      packets in an extremely short period, this might affect PE's=0A=
      control resources (e.g., CPU, memory) to follow such state=0A=
      changes.  Besides, it might also affect PE/P's control resources=0A=
      if MDTunnel inside the core is dynamically created in conjunction=0A=
      with customer's multicast group.=0A=
=0A=
   (d)  Attack by high volume of multicast/broadcast data traffic.=0A=
      A malicious CE might send very high volume of multicast and/or=0A=
      broadcast data to a PE.  If that PE does not provide any=0A=
      safeguards, it will cause excessive replication in SP network and=0A=
      the bandwidth resources for other trusted customers might be=0A=
      exhausted.=0A=
=0A=
   (e)  Attack by high volume of unknown destination unicast data=0A=
      traffic.=0A=
      A malicious CE can send a high volume of unknown unicast to a PE.=0A=
      Generally according to VPLS architecture, that PE must flood such=0A=
      unknown traffic to all correspond PEs in the same VPN.  A variety=0A=
      of unknown destinations and huge amount of such frames might cause=0A=
      excess traffic in SP network unless there is an appropriate=0A=
      safeguard provided.=0A=
=0A=
6.6.2.  Security Requirements=0A=
=0A=
   Based on the analysis in the previous subsection, the security=0A=
   requirements from the SP's perspective are shown as follows.=0A=
=0A=
   A SP network MUST be invulnerable to malformed or maliciously=0A=
   constructed customer traffic.  This applies to both multicast data=0A=
   packets and multicast control packets.=0A=
=0A=
   Moreover, because multicast, broadcast, and unknown-unicast need more=0A=
   resources than unicast, a SP network MUST have safeguards against=0A=
   unwanted or malicious multicast traffic.  This applies to both=0A=
   multicast data packets and multicast control packets.=0A=
=0A=
   Specifically, a multicast VPLS solution SHOULD have mechanisms to=0A=
   protect a SP network from:=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 25]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   (1)  invalid multicast MAC addresses=0A=
   (2)  invalid multicast IP addresses=0A=
   (3)  malformed Ethernet multicast control protocol frames=0A=
   (4)  malformed IP multicast control protocol packets=0A=
   (5)  high volumes of=0A=
      *  valid/invalid customer control packets=0A=
      *  valid/invalid customer data packets (broadcast/multicast/=0A=
         unknown-unicast)=0A=
=0A=
   Depending each solution's actual approach to tackle with issue A and=0A=
   B or both (see section 3.2.), there are relationships to be=0A=
   highlighted about each item's importance listed above.  First off,=0A=
   protection against (3) and (4) becomes significantly important if a=0A=
   solution supports solving issue A, and PEs are processing customer's=0A=
   Ethernet/IP multicast control messages from CE.  Moreover protection=0A=
   against (2) should also be much focused because PIM/IGMP snooping=0A=
   will usually require that PE's data forwarding be based on IP=0A=
   addresses.  By contrast, however, if a solution is solving only issue=0A=
   B, not A, then PEs might never process customer's multicast control=0A=
   messages at all, and they do not perform IP address-based forwarding,=0A=
   but does native Ethernet forwarding.  If so, there is relatively less=0A=
   danger about (2)(3)(4) compared to the first case.=0A=
=0A=
   The following are a few additional guidelines in detail.=0A=
=0A=
      For protecting against threat (a), a solution SHOULD support to=0A=
      impose some bounds on the quantity of state used by a VPN to be=0A=
      imposed in order to prevent state resource exhaustion (i.e., lack=0A=
      of memory, CPU etc.).  In this case, the bounds MUST be=0A=
      configurable per VPN basis, not total of various VPNs so that SP=0A=
      can isolate the resorce waste that is caused by any malicious=0A=
      customer.=0A=
=0A=
      For protecting against threat (d) and (e), a solution SHOULD=0A=
      support to perform traffic policing to limit the unwanted data=0A=
      traffic shown above.  In this case, while policing MAY be=0A=
      configurable to the sum of unicast, multicast, broadcast and=0A=
      unknown unicast traffic, it SHOULD also be configurable to each=0A=
      such type of traffic individually in order to prevent physical=0A=
      resource exhaustion (i.e., lack of bandwidth and degradation of=0A=
      throughput).  If the policing limit is configured on total traffic=0A=
      only, there will be a concern that one customer's huge multicast=0A=
      might close other irrelevant unicast traffic.  If it can be=0A=
      configured individually, this concern will be avoided.  Moreover,=0A=
      such a policing mechanism MUST be configurable per VPN basis, not=0A=
      total of various VPNs to isolate malicious customer's traffic from=0A=
      others.=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 26]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
      For protecting against threat (c), a solution SHOULD be able to=0A=
      limit frequent changes of group membership by customers.  For=0A=
      example, PEs might support a dampening mechanism that throttles=0A=
      their multicast state changes if the customers are changing too=0A=
      excessively.  Also if MDTunnel is provided being tightly coupled=0A=
      to dynamic changes of customer's multicast domain, it is also=0A=
      effective to delay building the tunnel when customer's state is=0A=
      changed frequently.=0A=
=0A=
      Protecting against threat (b) might not be an easy task.=0A=
      Generally, checking the legitimacy of customer's IP multicast=0A=
      control packets will eventually require the authentication between=0A=
      PE and CE in Layer 3; however, L2VPN (including VPLS) by its=0A=
      nature does not usually assume Layer 3-based security mechanism=0A=
      supported at PE-CE level.=0A=
      The ramification of this fact is that there remains possibility=0A=
      that a PE's control plain might be badly affected by corrupted=0A=
      multicast control packets that the PE is examining.  Hence each PE=0A=
      implementation will need to make an effort to minimize this impact=0A=
      from malicious customers and isolate it from other trusted=0A=
      customers as much as possible.=0A=
      Nevertheless, it is possible to mitigate this threat to some=0A=
      degree.  For example, a PE MAY support a filter mechanism about IP=0A=
      and MAC addresses in L2/L3 header and a filter mechanism about=0A=
      source/group addresses in the multicast join/prune messages.  This=0A=
      will help a PE to validate customers' control messages, to a=0A=
      certain extent.=0A=
=0A=
6.7.  Hierarchical VPLS support=0A=
=0A=
   A VPLS multicast solution SHOULD allow a hierarchical VPLS (H-VPLS)=0A=
   [RFC4762] service model.  In other words, a solution is expected to=0A=
   operate seamlessly with existing hub and spoke PW connectivity.=0A=
=0A=
   Note that it is also important to take into account the case of=0A=
   redundant spoke connections between U-PEs and N-PEs.=0A=
=0A=
6.8.  L2VPN Wholesale=0A=
=0A=
   A solution MUST allow a situation where one SP is offering L2VPN=0A=
   services to another SP.  One example here is a wholesale model where=0A=
   one VPLS interconnects other SPs' VPLS or 802.1D network islands.=0A=
   For customer SP, their multicast forwarding can be optimized by=0A=
   making use of multicast VPLS in the wholesaler SP.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 27]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
7.  Security Considerations=0A=
=0A=
   Security concerns and requirements for a base VPLS solution are=0A=
   described in [RFC4665].=0A=
=0A=
   In addition, there are security considerations specific to multicast=0A=
   VPLS.  Thus a set of security issues have been identified that MUST=0A=
   be addressed when considering the design and deployment of multicast=0A=
   VPLS.  Such issues have been described in Section 5.5 and 6.6.=0A=
=0A=
   In particular, security requirements from the view of customers are=0A=
   shown in Section 5.5.  Security requirements from the view of=0A=
   providers are shown in Section 6.6.  Section 6.6.1 conducts security=0A=
   threat analysis about the provider's whole system.  Section 6.6.2=0A=
   explains how each threat can be addressed or mitigated.=0A=
=0A=
=0A=
8.  IANA Considerations=0A=
=0A=
   This document has no actions for IANA.=0A=
=0A=
=0A=
9.  Acknowledgments=0A=
=0A=
   The authors thank the contributors of [RFC4834] since the structure=0A=
   and content of this document were, for some sections, largely=0A=
   inspired by [RFC4834].=0A=
=0A=
   The authors also thank Yuichi Ikejiri, Jerry Ash, Bill Fenner, Vach=0A=
   Kompella, Shane Amante, Ben Niven-Jenkins and Venu Hemige for their=0A=
   valuable reviews and feedbacks.=0A=
=0A=
=0A=
10.  References=0A=
=0A=
10.1.  Normative References=0A=
=0A=
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate=0A=
              Requirement Levels", BCP 14, RFC 2119, March 1997.=0A=
=0A=
   [RFC4665]  Augustyn, W. and Y. Serbest, "Service Requirements for=0A=
              Layer 2 Provider-Provisioned Virtual Private Networks",=0A=
              RFC 4665, September 2006.=0A=
=0A=
10.2.  Informative References=0A=
=0A=
   [802.1D]   ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition=0A=
              (Revision and redesignation of ISO/IEC  10038:98), "Part=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 28]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
              3: Media Access Control (MAC) Bridges", ISO/IEC 15802-3:,=0A=
              1998.=0A=
=0A=
   [802.1ag]  IEEE, "Virtual Bridge Local Area Networks: Connectivity=0A=
              Fault Management (Work in Progress)", 2007.=0A=
=0A=
   [802.1s]   IEEE Std 802.1s-2002, "Virtual Bridged Local Area=0A=
              Networks- Amendment 3: Multiple Spanning Trees", 2002.=0A=
=0A=
   [CGMP]     Farinacci, D., Tweedly, A., and T. Speakman, "Cisco Group=0A=
              Management Protocol (CGMP)",=0A=
              ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt , 1996/=0A=
              1997.=0A=
=0A=
   [I-D.ietf-mpls-ldp-p2mp]=0A=
              Minei, I., "Label Distribution Protocol Extensions for=0A=
              Point-to-Multipoint and  Multipoint-to-Multipoint Label=0A=
              Switched Paths", draft-ietf-mpls-ldp-p2mp-05 (work in=0A=
              progress), June 2008.=0A=
=0A=
   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,=0A=
              RFC 1112, August 1989.=0A=
=0A=
   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version=0A=
              2", RFC 2236, November 1997.=0A=
=0A=
   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,=0A=
              and W. Weiss, "An Architecture for Differentiated=0A=
              Services", RFC 2475, December 1998.=0A=
=0A=
   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast=0A=
              Listener Discovery (MLD) for IPv6", RFC 2710,=0A=
              October 1999.=0A=
=0A=
   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.=0A=
              Thyagarajan, "Internet Group Management Protocol, Version=0A=
              3", RFC 3376, October 2002.=0A=
=0A=
   [RFC3488]  Wu, I. and T. Eckert, "Cisco Systems Router-port Group=0A=
              Management Protocol (RGMP)", RFC 3488, February 2003.=0A=
=0A=
   [RFC3809]  Nagarajan, A., "Generic Requirements for Provider=0A=
              Provisioned Virtual Private Networks (PPVPN)", RFC 3809,=0A=
              June 2004.=0A=
=0A=
   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery=0A=
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 29]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol=0A=
              Independent Multicast - Dense Mode (PIM-DM): Protocol=0A=
              Specification (Revised)", RFC 3973, January 2005.=0A=
=0A=
   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,=0A=
              "Considerations for Internet Group Management Protocol=0A=
              (IGMP) and Multicast Listener Discovery (MLD) Snooping=0A=
              Switches", RFC 4541, May 2006.=0A=
=0A=
   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,=0A=
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):=0A=
              Protocol Specification (Revised)", RFC 4601, August 2006.=0A=
=0A=
   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for=0A=
              IP", RFC 4607, August 2006.=0A=
=0A=
   [RFC4664]  Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual=0A=
              Private Networks (L2VPNs)", RFC 4664, September 2006.=0A=
=0A=
   [RFC4761]  Kompella, K. and Y. Rekhter, "Virtual Private LAN Service=0A=
              (VPLS) Using BGP for Auto-Discovery and Signaling",=0A=
              RFC 4761, January 2007.=0A=
=0A=
   [RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service=0A=
              (VPLS) Using Label Distribution Protocol (LDP) Signaling",=0A=
              RFC 4762, January 2007.=0A=
=0A=
   [RFC4834]  Morin, T., Ed., "Requirements for Multicast in Layer 3=0A=
              Provider-Provisioned Virtual Private Networks (PPVPNs)",=0A=
              RFC 4834, April 2007.=0A=
=0A=
   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,=0A=
              "Extensions to Resource Reservation Protocol - Traffic=0A=
              Engineering (RSVP-TE) for Point-to-Multipoint TE Label=0A=
              Switched Paths (LSPs)", RFC 4875, May 2007.=0A=
=0A=
   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,=0A=
              "Bidirectional Protocol Independent Multicast (BIDIR-=0A=
              PIM)", RFC 5015, October 2007.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 30]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
Authors' Addresses=0A=
=0A=
   Yuji Kamite (editor)=0A=
   NTT Communications Corporation=0A=
   Tokyo Opera City Tower=0A=
   3-20-2 Nishi Shinjuku, Shinjuku-ku=0A=
   Tokyo  163-1421=0A=
   Japan=0A=
=0A=
   Email: y.kamite@ntt.com=0A=
=0A=
=0A=
   Yuichiro Wada=0A=
   NTT=0A=
   3-9-11 Midori-cho=0A=
   Musashino-shi=0A=
   Tokyo  180-8585=0A=
   Japan=0A=
=0A=
   Email: wada.yuichiro@lab.ntt.co.jp=0A=
=0A=
=0A=
   Yetik Serbest=0A=
   AT&T Labs=0A=
   9505 Arboretum Blvd.=0A=
   Austin, TX  78759=0A=
   USA=0A=
=0A=
   Email: yetik_serbest@labs.att.com=0A=
=0A=
=0A=
   Thomas Morin=0A=
   France Telecom R&D=0A=
   2, avenue Pierre-Marzin=0A=
   22307 Lannion Cedex=0A=
   France=0A=
=0A=
   Email: thomas.morin@francetelecom.com=0A=
=0A=
=0A=
   Luyuan Fang=0A=
   Cisco Systems, Inc.=0A=
   300 Beaver Brook Road=0A=
   Boxborough, MA  01719=0A=
   USA=0A=
=0A=
   Email: lufang@cisco.com=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 31]=0A=
=0C=0A=
Internet-Draft         Multicast VPLS Requirements              Nov 2008=0A=
=0A=
=0A=
Full Copyright Statement=0A=
=0A=
   Copyright (C) The IETF Trust (2008).=0A=
=0A=
   This document is subject to the rights, licenses and restrictions=0A=
   contained in BCP 78, and except as set forth therein, the authors=0A=
   retain all their rights.=0A=
=0A=
   This document and the information contained herein are provided on an=0A=
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A=
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A=
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A=
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A=
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A=
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A=
=0A=
=0A=
Intellectual Property=0A=
=0A=
   The IETF takes no position regarding the validity or scope of any=0A=
   Intellectual Property Rights or other rights that might be claimed to=0A=
   pertain to the implementation or use of the technology described in=0A=
   this document or the extent to which any license under such rights=0A=
   might or might not be available; nor does it represent that it has=0A=
   made any independent effort to identify any such rights.  Information=0A=
   on the procedures with respect to rights in RFC documents can be=0A=
   found in BCP 78 and BCP 79.=0A=
=0A=
   Copies of IPR disclosures made to the IETF Secretariat and any=0A=
   assurances of licenses to be made available, or the result of an=0A=
   attempt made to obtain a general license or permission for the use of=0A=
   such proprietary rights by implementers or users of this=0A=
   specification can be obtained from the IETF on-line IPR repository at=0A=
   http://www.ietf.org/ipr.=0A=
=0A=
   The IETF invites any interested party to bring to its attention any=0A=
   copyrights, patents or patent applications, or other proprietary=0A=
   rights that may cover technology that may be required to implement=0A=
   this standard.  Please address the information to the IETF at=0A=
   ietf-ipr@ietf.org.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Kamite, et al.            Expires May 29, 2009                 [Page 32]=0A=
=0C=0A=
=0A=

------=_NextPart_000_0022_01C94F3F.1599E170
Content-Type: text/html;
	name="diff-0811.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="diff-0811.html"


=20
=20

=20
=20
=20
=20
=20
=20
  =20
  =20
  Diff: draft-ietf-l2vpn-vpls-mcast-reqts-06.txt - =
draft-ietf-l2vpn-vpls-mcast-reqts-07_tmp2_0811.txt=20
  =20
=20
=20
  =20
  =20
      
 draft-ietf-l2vpn-vpls-mcast-reqts-0=
6.txt  =
 draft-ietf-l2vpn-vpls-mcast-reqts-07_tmp2_0811.txt 
 

      
Network Working Group                                     =
Y. Kamite, Ed. Network Working Group   =
                                  Y. Kamite, Ed.

      
Internet-Draft                                        NTT =
Communications Internet-Draft          =
                              NTT Communications

      
Intended status: Informational                            =
       Y. Wada Intended status: =
Informational                                   Y. Wada

      

      
Expires: February 6, 2009 =
                                           NTT Expires: May 29, 2009     =
                                           NTT

      
   =
                                                           Y. =
Serbest                                =
                               Y. Serbest

      
   =
                                                                 =
AT&T                               =
                                      AT&T

      
   =
                                                             T. =
Morin                                  =
                               T. Morin

      
   =
                                                       France =
Telecom                                =
                           France Telecom

      
   =
                                                              L. =
Fang                                   =
                               L. Fang

      
   =
                                                  Cisco Systems, =
Inc.                                   =
                   Cisco Systems, Inc.

      

      
 =
                                                            Aug 5, 2008  =
                                                           Nov 25, 2008

      
 

      
   =
Requirements for Multicast Support in Virtual Private LAN =
Services    Requirements for Multicast =
Support in Virtual Private LAN Services

      

      
 =
               draft-ietf-l2vpn-vpls-mcast-reqts-06.txt         =
        draft-ietf-l2vpn-vpls-mcast-reqts-07.txt

      
 

      
Status of this Memo Status of this Memo

      
 

      
   =
By submitting this Internet-Draft, each author represents that =
any    By submitting this =
Internet-Draft, each author represents that any

      
   =
applicable patent or other IPR claims of which he or she is =
aware    applicable patent or other =
IPR claims of which he or she is aware

      
   =
have been or will be disclosed, and any of which he or she =
becomes    have been or will be =
disclosed, and any of which he or she becomes

      
   =
aware will be disclosed, in accordance with Section 6 of BCP =
79.    aware will be disclosed, in =
accordance with Section 6 of BCP 79.

      
 

      
   =
Internet-Drafts are working documents of the Internet =
Engineering    Internet-Drafts are =
working documents of the Internet Engineering

      
   =
Task Force (IETF), its areas, and its working groups.  Note =
that    Task Force (IETF), its areas, =
and its working groups.  Note that

      
 =


      
skipping to change at page 1, line 41 =
skipping to change at =
page 1, line 41

      
   =
and may be updated, replaced, or obsoleted by other documents at =
any    and may be updated, replaced, =
or obsoleted by other documents at any

      
   =
time.  It is inappropriate to use Internet-Drafts as reference =
   time.  It is inappropriate to use =
Internet-Drafts as reference

      
   =
material or to cite them other than as "work in progress." =
   material or to cite them other than as "work =
in progress."

      
 

      
   =
The list of current Internet-Drafts can be accessed at    The list of current Internet-Drafts can be accessed =
at

      
   =
http://www.ietf.org/ietf/1id-abstracts.txt.    http://www.ietf.org/ietf/1id-abstracts.txt.

      
 

      
   =
The list of Internet-Draft Shadow Directories can be accessed =
at    The list of Internet-Draft =
Shadow Directories can be accessed at

      
   =
http://www.ietf.org/shadow.html.    =
http://www.ietf.org/shadow.html.

      
 

      

      
 =
  This Internet-Draft will expire on February =
6, 2009.    This =
Internet-Draft will expire on May 29, =
2009.

      
 

      
Abstract Abstract

      
 

      
   =
This document provides functional requirements for network =
solutions    This document provides =
functional requirements for network solutions

      
   =
that support multicast over Virtual Private LAN Service (VPLS).  =
It    that support multicast over =
Virtual Private LAN Service (VPLS).  It

      
   =
specifies requirements both from the end user and service =
provider    specifies requirements =
both from the end user and service provider

      
   =
standpoints.  It is intended that potential solutions will use =
these    standpoints.  It is intended =
that potential solutions will use these

      
   =
requirements as guidelines.    =
requirements as guidelines.

      
 

      
Table of Contents Table =
of Contents

      
 =


      
skipping to change at page 2, line 48 =
skipping to change at =
page 2, line 48

      
   =
  5.8.  Protection and Restoration . . . . . . . . . . . . . . . . =
16      5.8.  Protection and =
Restoration . . . . . . . . . . . . . . . . 16

      
   =
  5.9.  Minimum MTU  . . . . . . . . . . . . . . . . . . . . . . . =
16      5.9.  Minimum MTU  . . . . . . =
. . . . . . . . . . . . . . . . . 16

      
   =
  5.10. Frame Reordering Prevention  . . . . . . . . . . . . . . . =
17      5.10. Frame Reordering =
Prevention  . . . . . . . . . . . . . . . 17

      
   =
  5.11. Fate-Sharing between Unicast and Multicast . . . . . . . . =
17      5.11. Fate-Sharing between =
Unicast and Multicast . . . . . . . . 17

      
   =
6.  Service Provider Network Requirements  . . . . . . . . . . . . =
18    6.  Service Provider Network =
Requirements  . . . . . . . . . . . . 18

      
   =
  6.1.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . =
18      6.1.  Scalability  . . . . . . =
. . . . . . . . . . . . . . . . . 18

      
   =
    6.1.1.  Trade-off of Optimality and State Resource . . . . . . =
18        6.1.1.  Trade-off of =
Optimality and State Resource . . . . . . 18

      
   =
    6.1.2.  Key Metrics for Scalability  . . . . . . . . . . . . . =
19        6.1.2.  Key Metrics for =
Scalability  . . . . . . . . . . . . . 19

      
   =
  6.2.  Tunneling Requirements . . . . . . . . . . . . . . . . . . =
20      6.2.  Tunneling Requirements . =
. . . . . . . . . . . . . . . . . 20

      
   =
    6.2.1.  Tunneling Technologies . . . . . . . . . . . . . . . . =
20        6.2.1.  Tunneling =
Technologies . . . . . . . . . . . . . . . . 20

      

      
 =
      6.2.2.  MTU of MDTunnel  . . . . . . . . . . . . . . . . . . . =
21      =
  6.2.2.  MTU of MDTunnel  . . . . . . . . . . . . . . . . . . . 20

      
   =
  6.3.  Robustness . . . . . . . . . . . . . . . . . . . . . . . . =
21      6.3.  Robustness . . . . . . . =
. . . . . . . . . . . . . . . . . 21

      
   =
  6.4.  Discovering Related Information  . . . . . . . . . . . . . =
21      6.4.  Discovering Related =
Information  . . . . . . . . . . . . . 21

      
   =
  6.5.  Operation, Administration and Maintenance  . . . . . . . . =
21      6.5.  Operation, =
Administration and Maintenance  . . . . . . . . 21

      
   =
    6.5.1.  Activation . . . . . . . . . . . . . . . . . . . . . . =
21        6.5.1.  Activation . . . . . =
. . . . . . . . . . . . . . . . . 21

      
   =
    6.5.2.  Testing  . . . . . . . . . . . . . . . . . . . . . . . =
22        6.5.2.  Testing  . . . . . . =
. . . . . . . . . . . . . . . . . 22

      
   =
    6.5.3.  Performance Management . . . . . . . . . . . . . . . . =
22        6.5.3.  Performance =
Management . . . . . . . . . . . . . . . . 22

      
   =
    6.5.4.  Fault Management . . . . . . . . . . . . . . . . . . . =
23        6.5.4.  Fault Management . . =
. . . . . . . . . . . . . . . . . 23

      
   =
  6.6.  Security . . . . . . . . . . . . . . . . . . . . . . . . . =
24      6.6.  Security . . . . . . . . =
. . . . . . . . . . . . . . . . . 24

      

      
 =
    6.7.  Hierarchical VPLS support  . . . . . . . . . . . . . . . . =
25      =
  6.6.1.  Security Threat Analysis . . . . . . . =
. . . . . . . . 24

      
 =
    6.8.  L2VPN Wholesale  . . . . . . . . . . . . . . . . . . . . . =
25        6.6.2.  Security =
Requirements  . . . . . . . . . . . . . . . . 25

      
 =
  7.  Security Considerations  . . . . . . . . . . . . . . . . . . . =
25      =
6.7.  Hierarchical VPLS support  . . . . . . . . . . . . . . . . 27

      
 =
  8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . =
26      =
6.8.  L2VPN Wholesale  . . . . . . . . . . . . . . . . . . . . . 27

      
 =
  9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . =
26    =
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28

      
 =
  10. References . . . . . . . . . . . . . . . . . . . . . . . . . . =
26    =
8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28

      
 =
    10.1. Normative References . . . . . . . . . . . . . . . . . . . =
26    =
9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28

      
 =
    10.2. Informative References . . . . . . . . . . . . . . . . . . =
26    =
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28

      
 =
  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . =
28      =
10.1. Normative References . . . . . . . . . . . . . . . . . . . 28

      
 =
  Intellectual Property and Copyright Statements . . . . . . . . . . =
30      =
10.2. Informative References . . . . . . . . . . . . . . . . . . 28

      
    Authors' =
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30

      
    Intellectual =
Property and Copyright Statements . . . . . . . . . . 32

      
 

      
1. =
 Introduction 1.  Introduction

      
 

      
1.1.  Background 1.1.  =
Background

      
 

      
   =
VPLS (Virtual Private LAN Service) is a provider service that =
   VPLS (Virtual Private LAN Service) is a =
provider service that

      
   =
emulates the full functionality of a traditional Local Area =
Network    emulates the full =
functionality of a traditional Local Area Network

      
   =
(LAN).  VPLS interconnects several customer LAN segments over a =
   (LAN).  VPLS interconnects several customer =
LAN segments over a

      
   =
packet switched network (PSN) backbone, creating a =
multipoint-to-    packet switched =
network (PSN) backbone, creating a multipoint-to-

      
   =
multipoint Ethernet VPN.  For customers, their remote LAN =
segments    multipoint Ethernet VPN.  =
For customers, their remote LAN segments

      
 =


      
skipping to change at page 13, line =
28 skipping to =
change at page 13, line 28

      
   =
customers allow it to be regenerated at PE (aka proxy: see =
section    customers allow it to be =
regenerated at PE (aka proxy: see section

      
   =
5.1.2.), then the MAC address for that frame MAY be altered to =
the    5.1.2.), then the MAC address =
for that frame MAY be altered to the

      
   =
minimum necessary (e.g., use PE's own MAC address as a source). =
   minimum necessary (e.g., use PE's own MAC =
address as a source).

      
 

      
5.1.2.  Layer-3 Aspect 5.1.2.  Layer-3 Aspect

      
 

      
   =
Again, a solution MAY examine customer's Layer-3 multicast =
protocol    Again, a solution MAY =
examine customer's Layer-3 multicast protocol

      
   =
packets for the purpose of efficient and dynamic transport.  If =
it    packets for the purpose of =
efficient and dynamic transport.  If it

      
   =
does, supported protocols SHOULD include:    does, supported protocols SHOULD include:

      
 

      

      
 =
  o  PIM-SM [RFC4601], PIM-SSM [RFC4607], bidirectional PIM =
   o  PIM-SM [RFC4601], PIM-SSM [RFC4607], =
bidirectional PIM [RFC5015]

      
 =
     [I-D.ietf-pim-bidir] and PIM-DM =
[RFC3973]       and PIM-DM =
[RFC3973]

      
   =
o  IGMP (v1[RFC1112], v2[RFC2236] and v3[RFC3376]) (for IPv4 =
   o  IGMP (v1[RFC1112], v2[RFC2236] and =
v3[RFC3376]) (for IPv4

      
   =
   solutions)       solutions)

      
   =
o  Multicast Listener Discovery Protocol (MLD) (v1[RFC2710] and =
   o  Multicast Listener Discovery Protocol =
(MLD) (v1[RFC2710] and

      
   =
   v2[RFC3810]) (for IPv6 solutions).  =
     v2[RFC3810]) (for IPv6 solutions).

      
 

      
   =
A solution MUST NOT require any special Layer-3 multicast =
protocol    A solution MUST NOT =
require any special Layer-3 multicast protocol

      
   =
packet processing by the end users.  However, it MAY require =
some    packet processing by the end =
users.  However, it MAY require some

      
   =
configuration changes (e.g., turning explicit tracking on/off =
in    configuration changes (e.g., =
turning explicit tracking on/off in

      
   =
PIM).    PIM).

      
 

      
 =


      
skipping to change at page 20, line =
39 skipping to =
change at page 20, line 39

      
 

      
   =
A MDTunnel denotes a multicast distribution tunnel.  This is a =
   A MDTunnel denotes a multicast distribution =
tunnel.  This is a

      
   =
generic term for tunneling where customer multicast traffic is =
   generic term for tunneling where customer =
multicast traffic is

      
   =
carried over a provider's network.  In the L2VPN service context, =
it    carried over a provider's =
network.  In the L2VPN service context, it

      
   =
will correspond to a PSN tunnel.    =
will correspond to a PSN tunnel.

      
 

      
   =
A solution SHOULD be able to use a range of tunneling =
technologies,    A solution SHOULD be =
able to use a range of tunneling technologies,

      
   =
including point-to-point (unicast oriented) and =
point-to-multipoint/    including =
point-to-point (unicast oriented) and point-to-multipoint/

      
   =
multipoint-to-multipoint (multicast oriented).  For example, =
today    multipoint-to-multipoint =
(multicast oriented).  For example, today

      
   =
there are many kinds of protocols for tunneling such as L2TP, =
IP,    there are many kinds of =
protocols for tunneling such as L2TP, IP,

      

      
 =
  (including multicast IP trees), MPLS (including P2MP-LSP =
   (including multicast IP trees), MPLS =
(including P2MP-LSP [RFC4875]

      
 =
  [I-D.ietf-mpls-rsvp-te-p2mp] and =
P2MP/MP2MP-LSP    and P2MP/MP2MP-LSP =
[I-D.ietf-mpls-ldp-p2mp] ), etc.

      
 =
  [I-D.ietf-mpls-ldp-p2mp] ), etc. 

      
 

      
   =
Note that which variant, point-to-point, point-to-multipoint or =
   Note that which variant, point-to-point, =
point-to-multipoint or

      
   =
multipoint-to-multipoint, is used depends largely on the =
trade-offs    =
multipoint-to-multipoint, is used depends largely on the =
trade-offs

      
   =
mentioned above and the targeted network and applications. =
   mentioned above and the targeted network and =
applications.

      
   =
Therefore, this document does not mandate any specific protocols.  =
A    Therefore, this document does not =
mandate any specific protocols.  A

      
   =
solution, however, SHOULD state reasonable criteria if it adopts =
a    solution, however, SHOULD state =
reasonable criteria if it adopts a

      
   =
specific kind of tunneling protocol.   =
 specific kind of tunneling protocol.

      
 

      
6.2.2.  MTU of MDTunnel 6.2.2.  MTU of MDTunnel

      
 

      
 =


      
skipping to change at page 24, line =
28 skipping to =
change at page 24, line 26

      
   =
      multicast as well.  Also it is anticipated that such tools =
are          multicast as well.  Also =
it is anticipated that such tools are

      
   =
      coordinated with the testing mechanisms mentioned in =
6.5.2.          coordinated with the =
testing mechanisms mentioned in 6.5.2.

      
 

      
   =
      In particular, a solution needs to correctly identify the =
area          In particular, a =
solution needs to correctly identify the area

      
   =
      inside a multicast group impacted by the failure.  A =
solution          inside a multicast =
group impacted by the failure.  A solution

      
   =
      SHOULD be able to diagnose if an entire multicast group =
is          SHOULD be able to diagnose =
if an entire multicast group is

      
   =
      faulty or if some specific destinations are still alive. =
         faulty or if some specific =
destinations are still alive.

      
 

      
6.6.  Security 6.6.  =
Security

      
 

      

      
 6.6.1.  Security Threat Analysis

      
 

      
    In multicast VPLS, there is a concern that one or =
more customer nodes

      
    (presumably untrusted) might cause multicast-related =
attacks to the

      
    SP network.  There is a danger that it might =
compromise some

      
    components which belong to the whole =
system.

      
 

      
    This subsection states possible security threats =
relevant to the

      
    system and which are protected against and which are =
not.

      
 

      
    General security consideration about a base VPLS (as =
part of L2VPNs)

      
    is referred to [RFC4665].  Following is the threat =
analysis list

      
    which is inherent to multicast VPLS.

      
 

      
    (a)  Attack by huge amount of multicast control =
packets.

      
       There is a threat that a CE joins too many =
multicast groups and

      
       causes Denial of Service (DoS).  This is caused =
by sending a large

      
       number of packets join/prune messages in short =
time and/or putting

      
       a large variety of group addresses in join/prune =
messages.  This

      
       attack will waste PE's control resources (e.g., =
CPU, memory) which

      
       examine customer control messages (for solving =
issue A in section

      
       3.2.) and it will not continue expected services =
for other trusted

      
       customers.

      
 

      
    (b)  Attack by invalid/malformed multicast control =
packets.

      
       There is a threat that a CE sends invalid or =
malformed control

      
       packets that might corrupt PE, which will cause =
DoS attack.  In

      
       particular, a CE might be spoofing legitimate =
source/group IP

      
       multicast addresses in such control packets (in =
PIM, IGMP etc.)

      
       and source/destination MAC addresses as Layer 2 =
frame.

      
 

      
    (c)  Attack by rapid state change of =
multicast.

      
       If a malicious CE changes multicast state by =
sending control

      
       packets in an extremely short period, this might =
affect PE's

      
       control resources (e.g., CPU, memory) to follow =
such state

      
       changes.  Besides, it might also affect PE/P's =
control resources

      
       if MDTunnel inside the core is dynamically =
created in conjunction

      
       with customer's multicast group.

      
 

      
    (d)  Attack by high volume of multicast/broadcast =
data traffic.

      
       A malicious CE might send very high volume of =
multicast and/or

      
       broadcast data to a PE.  If that PE does not =
provide any

      
       safeguards, it will cause excessive replication =
in SP network and

      
       the bandwidth resources for other trusted =
customers might be

      
       exhausted.

      
 

      
    (e)  Attack by high volume of unknown destination =
unicast data

      
       traffic.

      
       A malicious CE can send a high volume of unknown =
unicast to a PE.

      
       Generally according to VPLS architecture, that PE =
must flood such

      
       unknown traffic to all correspond PEs in the same =
VPN.  A variety

      
       of unknown destinations and huge amount of such =
frames might cause

      
       excess traffic in SP network unless there is an =
appropriate

      
       safeguard provided.

      
 

      
 6.6.2.  Security Requirements

      
 

      
    Based on the analysis in the previous subsection, =
the security

      
    requirements from the SP's perspective are shown as =
follows.

      
                     =
                                                     

      
   =
A SP network MUST be invulnerable to malformed or maliciously =
   A SP network MUST be invulnerable to =
malformed or maliciously

      
   =
constructed customer traffic.  This applies to both multicast =
data    constructed customer traffic.  =
This applies to both multicast data

      
   =
packets and multicast control packets.    packets and multicast control packets.

      
 

      
   =
Moreover, because multicast, broadcast, and unknown-unicast need =
more    Moreover, because multicast, =
broadcast, and unknown-unicast need more

      
   =
resources than unicast, a SP network MUST have safeguards =
against    resources than unicast, a =
SP network MUST have safeguards against

      
   =
unwanted or malicious multicast traffic.  This applies to both =
   unwanted or malicious multicast traffic.  =
This applies to both

      
   =
multicast data packets and multicast control packets.    multicast data packets and multicast control =
packets.

      
 

      
   =
Specifically, a multicast VPLS solution SHOULD have mechanisms =
to    Specifically, a multicast VPLS =
solution SHOULD have mechanisms to

      
   =
protect a SP network from:    protect =
a SP network from:

      
 

      

      
 =
  -  invalid multicast MAC addresses (always)    =
(1)  invalid multicast MAC =
addresses

      
   -  invalid multicast =
IP addresses (if they are used for =
forwarding)    (2)  invalid multicast IP addresses

      
   -  malformed Ethernet =
multicast control protocol frames (if they =
are    (3)  malformed Ethernet multicast control =
protocol frames

      
      examined) =
   (4)  =
malformed IP multicast control protocol packets

      
   -  malformed IP =
multicast control protocol packets (if they =
are    (5)  high volumes of

      
      examined) =


      
   -  high volumes =
of 

      
   =
   *  valid/invalid customer control packets       *  valid/invalid customer control packets

      
   =
   *  valid/invalid customer data packets (broadcast/multicast/ =
      *  valid/invalid customer data packets =
(broadcast/multicast/

      
   =
      unknown-unicast)          =
unknown-unicast)

      
 

      

      
 =
  The following are a few additional guidelines.    Depending each solution's =
actual approach to tackle with issue A and

      
    B or both (see section 3.2.), there are relationships to be

      
    highlighted about each item's importance listed =
above.  First off,

      
    protection against (3) and (4) becomes significantly =
important if a

      
    solution supports solving issue A, and PEs are =
processing customer's

      
    Ethernet/IP multicast control messages from CE.  =
Moreover protection

      
    against (2) should also be much focused because =
PIM/IGMP snooping

      
    will usually require that PE's data forwarding be =
based on IP

      
    addresses.  By contrast, however, if a solution is =
solving only issue

      
    B, not A, then PEs might never process customer's =
multicast control

      
    messages at all, and they do not perform IP =
address-based forwarding,

      
    but does native Ethernet forwarding.  If so, there =
is relatively less

      
    danger about (2)(3)(4) compared to the first =
case.

      
 

      

      
 =
     A solution MAY allow some bounds on the =
quantity of state used by    =
The following are a few additional guidelines in detail.

      
 =
     a VPN to be imposed in order to prevent state resource =
exhaustion 

      
      (i.e., lack of memory, CPU =
etc.). 

      
 

      

      
 =
     Also a solution MAY allow a policing mechanism to limit the     =
  For protecting against threat (a), a =
solution SHOULD support to

      
 =
     unwanted data traffic shown above.  In this =
case, while policing       =
impose some bounds on the quantity of state used by =
a VPN to be

      
      MAY be configurable to the =
sum of unicast, multicast, =
broadcast       imposed in order to prevent state resource exhaustion (i.e., lack

      
      and unknown unicast =
traffic, it MAY also be configurable to each       of memory, CPU etc.).  In =
this case, the bounds MUST be

      
      such type of traffic =
individually, or to their =
combination in       configurable per VPN basis, not total of =
various VPNs so that SP

      
 =
     order to prevent physical resource =
exhaustion (i.e., lack of       can isolate the resorce waste that is caused by =
any malicious

      
 =
     bandwidth and degradation of throughput).       customer.

      
 

      

      
 =
     Moreover, mechanisms to limit =
frequent changes of group membership  =
     For protecting against threat (d) and (e), a =
solution SHOULD

      
 =
     by customers MAY be supported.  For =
example, if the core       support to perform traffic =
policing to limit the unwanted data

      
      distribution tunnel =
is tightly coupled to dynamic changes of       traffic shown above.  In =
this case, while policing MAY be

      
 =
     customer multicast domain, a kind of dampening =
function should be       configurable to the sum of unicast, multicast, =
broadcast and

      
 =
     possible.       unknown unicast traffic, it SHOULD also be =
configurable to each

      
       such type of traffic individually in order to =
prevent physical

      
       resource exhaustion (i.e., lack of bandwidth and =
degradation of

      
       throughput).  If the policing limit is configured =
on total traffic

      
       only, there will be a concern that one customer's =
huge multicast

      
       might close other irrelevant unicast traffic.  If =
it can be

      
       configured individually, this concern will be =
avoided.  Moreover,

      
       such a policing mechanism MUST be configurable per VPN =
basis, not

      
       total of various VPNs to isolate malicious =
customer's traffic from

      
       others.

      
 

      
       For protecting against threat (c), a solution =
SHOULD be able to

      
       limit =
frequent changes of group membership by customers.  For

      
       example, =
PEs might support a dampening mechanism that =
throttles

      
       their multicast state changes if the customers are changing too

      
       excessively.  Also if MDTunnel is provided being tightly coupled

      
       to dynamic =
changes of customer's multicast domain, =
it is also

      
       effective to delay building the tunnel when =
customer's state is

      
       changed frequently.

      
 

      
       Protecting against threat (b) might not be an =
easy task.

      
       Generally, checking the legitimacy of =
customer's IP multicast

      
       control packets will eventually require the =
authentication between

      
       PE and CE in Layer 3; however, L2VPN (including =
VPLS) by its

      
       nature does not usually assume Layer 3-based =
security mechanism

      
       supported at PE-CE level.

      
       The ramification of this fact is that there =
remains possibility

      
       that a PE's control plain might be badly affected by corrupted

      
       multicast control packets that the PE is =
examining.  Hence each PE

      
       implementation will need to make an effort to =
minimize this impact

      
       from malicious customers and isolate it from =
other trusted

      
       customers as much as possible.

      
       Nevertheless, it is possible to mitigate this threat to =
some

      
       degree.  For example, a PE MAY support a filter =
mechanism about IP

      
       and MAC addresses in L2/L3 header and a filter =
mechanism about

      
       source/group addresses in the multicast =
join/prune messages.  This

      
       will help a PE to validate customers' control =
messages, to a

      
       certain extent.

      
 

      
6.7.  Hierarchical VPLS support 6.7.  Hierarchical VPLS support

      
 

      
   =
A VPLS multicast solution SHOULD allow a hierarchical VPLS =
(H-VPLS)    A VPLS multicast solution =
SHOULD allow a hierarchical VPLS (H-VPLS)

      
   =
[RFC4762] service model.  In other words, a solution is expected =
to    [RFC4762] service model.  In =
other words, a solution is expected to

      
   =
operate seamlessly with existing hub and spoke PW connectivity. =
   operate seamlessly with existing hub and =
spoke PW connectivity.

      
 

      
   =
Note that it is also important to take into account the case of =
   Note that it is also important to take into =
account the case of

      
   =
redundant spoke connections between U-PEs and N-PEs.    redundant spoke connections between U-PEs and =
N-PEs.

      
 

      
 =


      
skipping to change at page 25, line =
45 skipping to =
change at page 28, line 10

      
   =
services to another SP.  One example here is a wholesale model =
where    services to another SP.  One =
example here is a wholesale model where

      
   =
one VPLS interconnects other SPs' VPLS or 802.1D network =
islands.    one VPLS interconnects =
other SPs' VPLS or 802.1D network islands.

      
   =
For customer SP, their multicast forwarding can be optimized by =
   For customer SP, their multicast forwarding =
can be optimized by

      
   =
making use of multicast VPLS in the wholesaler SP.    making use of multicast VPLS in the wholesaler =
SP.

      
 

      
7. =
 Security Considerations 7.  Security =
Considerations

      
 

      
   =
Security concerns and requirements for a base VPLS solution are =
   Security concerns and requirements for a =
base VPLS solution are

      
   =
described in [RFC4665].    described =
in [RFC4665].

      
 

      

      
 =
  In additions, there are security =
considerations specific to multicast  =
  In addition, there are security considerations specific to =
multicast

      
   =
VPLS.  Thus a set of security issues have been identified that =
MUST    VPLS.  Thus a set of security =
issues have been identified that MUST

      
   =
be addressed when considering the design and deployment of =
multicast    be addressed when =
considering the design and deployment of multicast

      
   =
VPLS.  Such issues have been described in Section 5.5 and 6.6. =
   VPLS.  Such issues have been described in =
Section 5.5 and 6.6.

      
 

      

      
    In particular, security requirements from the view of =
customers are

      
    shown in Section 5.5.  Security requirements from =
the view of

      
    providers are shown in Section 6.6.  Section 6.6.1 =
conducts security

      
    threat analysis about the provider's whole system.  =
Section 6.6.2

      
    explains how each threat can be addressed or =
mitigated.

      
                     =
                                                     

      
8. =
 IANA Considerations 8.  IANA =
Considerations

      
 

      
   =
This document has no actions for IANA.    This document has no actions for IANA.

      
 

      
9. =
 Acknowledgments 9.  =
Acknowledgments

      
 

      
   =
The authors thank the contributors of [RFC4834] since the =
structure    The authors thank the =
contributors of [RFC4834] since the structure

      
   =
and content of this document were, for some sections, largely =
   and content of this document were, for some =
sections, largely

      
   =
inspired by [RFC4834].    inspired by =
[RFC4834].

      
 

      
 =


      
skipping to change at page 27, line 7 =
skipping to change at =
page 29, line 24

      
   =
           Management Protocol (CGMP)",               Management Protocol (CGMP)",

      
   =
           ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt , =
1996/               =
ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt , 1996/

      
   =
           1997.               =
1997.

      
 

      
   =
[I-D.ietf-mpls-ldp-p2mp]    =
[I-D.ietf-mpls-ldp-p2mp]

      
   =
           Minei, I., "Label Distribution Protocol Extensions =
for               Minei, I., "Label =
Distribution Protocol Extensions for

      
   =
           Point-to-Multipoint and  Multipoint-to-Multipoint =
Label               =
Point-to-Multipoint and  Multipoint-to-Multipoint Label

      
   =
           Switched Paths", draft-ietf-mpls-ldp-p2mp-05 (work =
in               Switched Paths", =
draft-ietf-mpls-ldp-p2mp-05 (work in

      
   =
           progress), June 2008.       =
        progress), June 2008.

      
 

      

      
 =
  [I-D.ietf-mpls-rsvp-te-p2mp] =


      
              Aggarwal, R., =
"Extensions to RSVP-TE for Point-to- 

      
              Multipoint TE =
LSPs", draft-ietf-mpls-rsvp-te-p2mp-07 (work 

      
              in progress), =
January 2007. 

      
 

      
   =
[I-D.ietf-pim-bidir] 

      
              Handley, M., =
"Bi-directional Protocol Independent 

      
              Multicast =
(BIDIR-PIM)", draft-ietf-pim-bidir-09 (work in 

      
              progress), =
February 2007. 

      
 =
                                                                        =
 

      
   =
[RFC1112]  Deering, S., "Host extensions for IP multicasting", STD =
5,    [RFC1112]  Deering, S., "Host =
extensions for IP multicasting", STD 5,

      
   =
           RFC 1112, August 1989.      =
         RFC 1112, August 1989.

      
 

      
   =
[RFC2236]  Fenner, W., "Internet Group Management Protocol, =
Version    [RFC2236]  Fenner, W., =
"Internet Group Management Protocol, Version

      
   =
           2", RFC 2236, November 1997.               2", RFC 2236, November 1997.

      
 

      
   =
[RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, =
Z.,    [RFC2475]  Blake, S., Black, =
D., Carlson, M., Davies, E., Wang, Z.,

      
   =
           and W. Weiss, "An Architecture for Differentiated =
              and W. Weiss, "An Architecture =
for Differentiated

      
   =
           Services", RFC 2475, December 1998.               Services", RFC 2475, December =
1998.

      
 

      
 =


      
skipping to change at page 28, line =
28 skipping to =
change at page 30, line 36

      
   =
           RFC 4761, January 2007.     =
          RFC 4761, January 2007.

      
 

      
   =
[RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN =
Service    [RFC4762]  Lasserre, M. and =
V. Kompella, "Virtual Private LAN Service

      
   =
           (VPLS) Using Label Distribution Protocol (LDP) =
Signaling",               (VPLS) Using =
Label Distribution Protocol (LDP) Signaling",

      
   =
           RFC 4762, January 2007.     =
          RFC 4762, January 2007.

      
 

      
   =
[RFC4834]  Morin, T., Ed., "Requirements for Multicast in Layer =
3    [RFC4834]  Morin, T., Ed., =
"Requirements for Multicast in Layer 3

      
   =
           Provider-Provisioned Virtual Private Networks =
(PPVPNs)",               =
Provider-Provisioned Virtual Private Networks (PPVPNs)",

      
   =
           RFC 4834, April 2007.       =
        RFC 4834, April 2007.

      
 

      

      
    [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. =
Yasukawa,

      
               "Extensions to Resource Reservation =
Protocol - Traffic

      
               Engineering (RSVP-TE) for =
Point-to-Multipoint TE Label

      
               Switched Paths (LSPs)", RFC 4875, May =
2007.

      
 

      
    [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., =
and L. Vicisano,

      
               "Bidirectional Protocol Independent =
Multicast (BIDIR-

      
               PIM)", RFC 5015, October =
2007.

      
                     =
                                                     

      
Authors' Addresses Authors' Addresses

      
 

      
   =
Yuji Kamite (editor)    Yuji Kamite =
(editor)

      
   =
NTT Communications Corporation    NTT =
Communications Corporation

      
   =
Tokyo Opera City Tower    Tokyo Opera =
City Tower

      
   =
3-20-2 Nishi Shinjuku, Shinjuku-ku    =
3-20-2 Nishi Shinjuku, Shinjuku-ku

      
   =
Tokyo  163-1421    Tokyo  =
163-1421

      
   =
Japan    Japan

      
 

      
   =
Email: y.kamite@ntt.com    Email: =
y.kamite@ntt.com


     
 

     
 End of changes. 18 change blocks. 

     
54 lines changed or =
deleted 165 lines changed or =
added

     

This =
html diff was produced by rfcdiff 1.35. The latest version is available =
from http://tools.ietf.org/tools/rfcdiff/ 

   

   
   

------=_NextPart_000_0022_01C94F3F.1599E170
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir

------=_NextPart_000_0022_01C94F3F.1599E170--



From secdir-bounces@ietf.org  Tue Nov 25 11:35:31 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BBC613A6AA7;
	Tue, 25 Nov 2008 11:35:31 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5B33B3A6902
	for ; Tue, 25 Nov 2008 11:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id bERV1X2YU6cl for ;
	Tue, 25 Nov 2008 11:35:29 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251])
	by core3.amsl.com (Postfix) with ESMTP id 261103A6C2F
	for ; Tue, 25 Nov 2008 11:35:29 -0800 (PST)
Received: from [172.16.2.190] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com (submission channel) via TCP with ESMTPA 
	id ; Tue, 25 Nov 2008 19:35:25 +0000
Message-ID: <492C534E.5030300@isode.com>
Date: Tue, 25 Nov 2008 19:34:38 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Fred Baker 
References: <49279C4F.10909@isode.com>
	
In-Reply-To: 
MIME-Version: 1.0
Cc: draft-ietf-tsvwg-admitted-realtime-dscp@tools.ietf.org,
	tsvwg-chairs@tools.ietf.org, iesg@iesg.org,
	"secdir@ietf.org" 
Subject: Re: [secdir] secdir review of
	draft-ietf-tsvwg-admitted-realtime-dscp-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Hi Fred,

Fred Baker wrote:

> On Nov 21, 2008, at 11:44 PM, Alexey Melnikov wrote:
>
>> I found the Security Consideration section to be insufficiently  
>> detailed
>> about threats. While the list of threats seems to be adequate,
>> it would be useful to have some pointers to documents describing  
>> possible
>> remedies (for example how to achieve adequately strong proof of  
>> identity),
>> or a clear statement that the protocol doesn't provide such facility.
>
> Would a reference to 4542 be sufficient?

It looks like a reference to section 2.4 of RFC 4542 would be helpful.

> My sense is that the threat model on a AAA service is likely to be  
> documented in something related to AAA services, and frankly you are  
> more likely to have a pointer to the document than I. Similarly, the  
> threat model regarding people getting capacity allocated to them that  
> shouldn't have been seems implicit in RFC 1633, the documentation of  
> RSVP, and the documentation of NSIS - protocols designed explicitly 
> to  prevent that from happening. There is of course a threat model 
> for  implementing such a protocol as well, which is mentioned in RFC 
> 4230.

I think a reference to RFC 4230 would be helpful as well.

> if I'm missing something and you want more, some idea of what kind of  
> threat model you are looking for would be helpful.

I was reading your Security Considerations:

   A major requirement of this service is effective use of a signaling
   protocol such as RSVP, with the capabilities to identify its user
   either as an individual or as a member of some corporate entity, and
   assert a policy such as "routine" or "priority".

   This capability, one has to believe, will be abused by script kiddies
   and others if the proof of identity is not adequately strong

My question after reading this part was "how one can make make proof of identity sufficiently strong?".
So some pointers helping a reader to find this information would be useful here.

   or if
   policies are written or implemented improperly by the carriers.  This
   goes without saying, but this section is here for it to be said...


_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Tue Nov 25 11:36:53 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EAD963A6AA7;
	Tue, 25 Nov 2008 11:36:53 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 561CF3A6AA7;
	Tue, 25 Nov 2008 11:36:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id B5DynPe1WYPC; Tue, 25 Nov 2008 11:36:51 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41])
	by core3.amsl.com (Postfix) with ESMTP id 872153A6902;
	Tue, 25 Nov 2008 11:36:51 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1])
	by fledge.watson.org (8.14.3/8.14.2) with ESMTP id mAPJakUP079431;
	Tue, 25 Nov 2008 14:36:46 -0500 (EST)
	(envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost)
	by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id
	mAPJajeq079428; Tue, 25 Nov 2008 14:36:45 -0500 (EST)
	(envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Tue, 25 Nov 2008 14:36:45 -0500 (EST)
From: Samuel Weiler 
To: secdir@ietf.org, ietf@ietf.org
Message-ID: 
User-Agent: Alpine 1.10 (BSF 962 2008-03-14)
MIME-Version: 1.0
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0
	(fledge.watson.org [127.0.0.1]);
	Tue, 25 Nov 2008 14:36:46 -0500 (EST)
Cc: Harald Tveit Alvestrand 
Subject: [secdir] secdir review of draft-housley-iesg-rfc3932bis-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document appears to change ONLY the IRTF review process -- the
IESG long ago quit reviewing the substance of independent documents
from a security perspective.  Accordingly, the security considerations
is correct:

    The process change described in this memo has no direct bearing on
    the security of the Internet.

That said, I'm puzzled by the continued inclusion of "rejected
alternative bypass" as a reason to delay publication.  In section 4,
this document proposes that readers could be confused by the order of
publication of documents.  At the same time, this document is removing
the mandatory IESG note from independent submissions in favor of a new
header (defined in another doc, listed as a normative reference).  If
that header is sufficient to dispel confusion when it comes to the
substantive matters of "we haven't reviewed this", can't it also be
relied on to be adequate to avoid confusion arising from publication
order?  Accordingly, I suggest removing reason 3, as least so far as
"rejected alternative bypass" is concerned.

-- Sam

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Tue Nov 25 11:47:37 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 45CFB3A69E3;
	Tue, 25 Nov 2008 11:47:37 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 59ECD3A69E3
	for ; Tue, 25 Nov 2008 11:47:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8VvEl0a97YRZ for ;
	Tue, 25 Nov 2008 11:47:35 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41])
	by core3.amsl.com (Postfix) with ESMTP id 670453A6991
	for ; Tue, 25 Nov 2008 11:47:35 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1])
	by fledge.watson.org (8.14.3/8.14.2) with ESMTP id mAPJlWh2080352
	for ; Tue, 25 Nov 2008 14:47:32 -0500 (EST)
	(envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost)
	by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id
	mAPJlWIV080349
	for ; Tue, 25 Nov 2008 14:47:32 -0500 (EST)
	(envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Tue, 25 Nov 2008 14:47:32 -0500 (EST)
From: Samuel Weiler 
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: 
User-Agent: Alpine 1.10 (BSF 962 2008-03-14)
MIME-Version: 1.0
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0
	(fledge.watson.org [127.0.0.1]);
	Tue, 25 Nov 2008 14:47:32 -0500 (EST)
Subject: [secdir] Assignments for December 2nd
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

The NFS docs are on the telechat agenda next week (December 4th), and 
the IESG has scheduled another telechat for December 11th.  FWIW, 
we've been through nearly the whole rotation in November.

Brian Weis is next in the rotation.

Review instructions and related resources are at:
    http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam

For telechat next week (review by Tuesday, 2 December)

Derek Atkins                   T  draft-ietf-6man-reserved-iids-01
Lakshminath Dondeti            T  draft-ietf-monami6-multiplecoa-10
Marcus Leech                   T  draft-ietf-dnsext-forgery-resilience-09
Vidya Narayanan                T  draft-ietf-lemonade-imap-notify-07
Yaron Sheffer                  TR draft-ietf-mip4-dsmipv4-08
Susan Thomson                  T  draft-ietf-nfsv4-minorversion1-dot-x-09
Hannes Tschofenig              T  draft-ietf-nfsv4-pnfs-block-09
Nico Williams                  T  draft-ietf-nfsv4-minorversion1-26
Larry Zhu                      T  draft-arkko-arp-iana-rules-01

For later telechats:

Tobias Gondrom                 T  draft-ietf-pim-rpf-vector-06
Marcus Leech                   T  draft-housley-internet-draft-sig-file-06
Hilarie Orman                  T  draft-ietf-avt-rtp-g719-04

Last calls and special requests:

Rob Austein                       draft-ietf-dime-qos-parameters-07
Pat Cain                        R draft-ietf-ipdvb-sec-req-09
Pat Cain                          draft-ietf-geopriv-pdif-lo-profile-14
Ran Canetti                       draft-ietf-kitten-gssapi-channel-bindings-05
Alan DeKok                        draft-ietf-mext-nemo-v4traversal-06
Shawn Emery                       draft-ietf-nfsv4-rfc1831bis-10
Stephen Farrell                   draft-ietf-ospf-lls-05
Phillip Hallam-Baker              draft-ietf-radext-design-05
Steve Hanna                     R draft-kucherawy-sender-auth-header-17
Steve Hanna                       draft-ietf-radext-management-authorization-06
David Harrington                  draft-ietf-sip-saml-05
Sam Hartman                       draft-ietf-smime-3850bis-08
Paul Hoffman                      draft-ietf-smime-3851bis-08
Love Hornquist-Astrand            draft-ietf-tcpm-rfc4138bis-04
Jeffrey Hutzelman                 draft-ietf-tcpm-tcp-uto-09
Scott Kelly                       draft-ietf-tsvwg-rsvp-proxy-approaches-06
Stephen Kent                      draft-ietf-tsvwg-rsvp-proxy-proto-07
Julien Laganier                   draft-ietf-softwire-mesh-framework-05
Julien Laganier                   draft-ietf-softwire-encaps-ipsec-01
Catherine Meadows                 draft-ietf-speechsc-mrcpv2-17
Catherine Meadows                 draft-ietf-l2tpext-tdm-06
Alexey Melnikov                   draft-ietf-pce-pcep-xro-06
Sandy Murphy                      draft-ietf-mpls-mpls-and-gmpls-security-framework-04
Sandy Murphy                      draft-ietf-roll-urban-routing-reqs-02
Vidya Narayanan                   draft-ietf-sip-saml-05
Magnus Nystrom                    draft-freed-sieve-ihave-03
Radia Perlman                     draft-ietf-mpls-cosfield-def-07
Eric Rescorla                     draft-wing-sipping-srtp-key-04
Eric Rescorla                     draft-ietf-dkim-ssp-07
Joe Salowey                       draft-ietf-mpls-te-scaling-analysis-03
Stefan Santesson                  draft-ietf-pkix-ecc-subpubkeyinfo-10
Juergen Schoenwaelder             draft-ietf-nfsv4-rpc-netid-03
Yaron Sheffer                     draft-ietf-sip-session-policy-framework-05
Susan Thomson                     draft-loreto-simple-im-srv-label-02
Hannes Tschofenig                 draft-ietf-trill-prob-05
Sean Turner                       draft-mammoliti-l2tp-accessline-avp-04
Carl Wallace                      draft-ietf-isis-hmac-sha-07
Carl Wallace                      draft-melnikov-imapext-filters-06
Sam Weiler                        draft-chown-v6ops-rogue-ra-02
Sam Weiler                        draft-raj-dhc-tftp-addr-option-04
Brian Weis                        draft-ietf-isis-wg-extlsp-04
Nico Williams                     draft-ietf-v6ops-ra-guard-01
Larry Zhu                         draft-thaler-v6ops-teredo-extensions-02
Glen Zorn                         draft-hoffman-dac-vbr-04
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Tue Nov 25 13:19:22 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id ADBDB3A6C5C;
	Tue, 25 Nov 2008 13:19:22 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BCD2728C116
	for ; Tue, 25 Nov 2008 13:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level: 
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 
	BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id CQ03fJ3jDn+d for ;
	Tue, 25 Nov 2008 13:19:21 -0800 (PST)
Received: from QMTA08.emeryville.ca.mail.comcast.net
	(qmta08.emeryville.ca.mail.comcast.net [76.96.30.80])
	by core3.amsl.com (Postfix) with ESMTP id BD5503A6C5C
	for ; Tue, 25 Nov 2008 13:19:20 -0800 (PST)
Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19])
	by QMTA08.emeryville.ca.mail.comcast.net with comcast
	id jVTR1a0030QkzPwA8ZKJ1L; Tue, 25 Nov 2008 21:19:18 +0000
Received: from gwzPC ([67.170.97.40])
	by OMTA02.emeryville.ca.mail.comcast.net with comcast
	id jZKG1a00n0sGXSz8NZKH9q; Tue, 25 Nov 2008 21:19:18 +0000
X-Authority-Analysis: v=1.0 c=1 a=_8bqiaEy-iYA:10 a=t4FJ9NeVm4YA:10
	a=6jR8yVF0jzLxKOQmdwMA:9 a=79vLQpAdbcu_XKAm1w0A:7
	a=YmLe-zPs7df_Q3gD2ONZ0hfW34UA:4 a=gi0PWCVxevcA:10
From: "Glen Zorn" 
To: , ,
	, , ,
	
Date: Tue, 25 Nov 2008 13:18:41 -0800
Message-ID: <005201c94f43$648bdaa0$2da38fe0$@net>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AclPQ2NHFs8Mcfz5TrKkLQMjP7o34w==
Content-Language: en-us
Subject: [secdir] secdir review of draft-hoffman-dac-vbr-04.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I can find no fault with this document.

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Tue Nov 25 23:58:33 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C70CE3A6B3E;
	Tue, 25 Nov 2008 23:58:33 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 45A8D3A67F2;
	Tue, 25 Nov 2008 23:58:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id wuIf3-9ammx4; Tue, 25 Nov 2008 23:58:31 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41])
	by core3.amsl.com (Postfix) with ESMTP id 616723A657C;
	Tue, 25 Nov 2008 23:58:30 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1])
	by fledge.watson.org (8.14.3/8.14.2) with ESMTP id mAQ7wP2E037928;
	Wed, 26 Nov 2008 02:58:25 -0500 (EST)
	(envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost)
	by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id
	mAQ7wPJZ037924; Wed, 26 Nov 2008 02:58:25 -0500 (EST)
	(envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Wed, 26 Nov 2008 02:58:25 -0500 (EST)
From: Samuel Weiler 
To: secdir@ietf.org
Message-ID: 
User-Agent: Alpine 1.10 (BSF 962 2008-03-14)
MIME-Version: 1.0
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0
	(fledge.watson.org [127.0.0.1]);
	Wed, 26 Nov 2008 02:58:25 -0500 (EST)
Cc: dhc-chairs@tools.ietf.org, raj@cisco.com, ietf@ietf.org, iesg@ietf.org
Subject: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary:

At the very least, I suggest mandating the use of DHCP Auth and 
removing the suggestion to use option 66 to enhance security.  And, in 
the absence of a more data about how widely used this option is, I 
suggest not publishing this document at all.

Details:

In 2004 RFC3942 defined a procedure for vendors to lay claim to DHCP 
option code points that, while previously set aside for 
"site-specific" options, had been used by vendors.  This document 
attempts to claim such a code point.

It's not clear why a distinct code point is needed here.  The document
claims that the "TFTP server name" option (#66) must contain a domain
name, but I'm pretty sure that real-world devices (e.g. the Cisco
7960) happily accept and use v4 address literals in option 66.
Furthermore, there appear to be other DHCP options that could do the
trick (e.g. #128, documented in the IANA registry as "TFTP Server IP
address (for IP Phone software load)").

The document's write-up says "it is believed that to some extent this
option is in use in some deployments of VoIP devices".  That's not a
very convincing argument that enough devices use this to justify
invoking the RFC3942 procedure, given that other devices are making do
just fine with existing fields.  Do these devices ALSO check option
#66, such that continued use of #150 is really unnecessary?  In the
four years since publication of RFC3942, have enough of these devices
been obsoleted (or updated to also use other DHCP option fields) that
this code point is no longer needed?

And if we do want to proceed with defining this option: shouldn't it
also allow for v6 addresses?  (The current doc only allows for v4.)

The security considerations section cites rogue DHCP servers as attack
vectors, but doesn't do enough to encourage the use of DHCP Auth.
Furthermore, it suggests using the "TFTP server name" option, on the
basis that a client must do a DNS lookup to use the contents, thereby
giving an tiny extra layer of assurance.  I'm pretty sure that
real-world devices happily accept v4 literals in option 66, making the
suggestion a poor one.

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Wed Nov 26 08:50:34 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id DD2383A6C1A;
	Wed, 26 Nov 2008 08:50:34 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A4AAF3A6C04;
	Wed, 26 Nov 2008 08:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.48
X-Spam-Level: 
X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id rIdiqPm725ug; Wed, 26 Nov 2008 08:50:32 -0800 (PST)
Received: from cs.tcd.ie (relay.cs.tcd.ie
	[IPv6:2001:770:10:200:214:4fff:feb0:ab6c])
	by core3.amsl.com (Postfix) with ESMTP id 657423A688A;
	Wed, 26 Nov 2008 08:50:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by relay.cs.tcd.ie (Postfix) with ESMTP id CC9CD3EA1D;
	Wed, 26 Nov 2008 16:50:22 +0000 (GMT)
X-Virus-Scanned: amavisd-new at cs.tcd.ie
Received: from cs.tcd.ie ([127.0.0.1])
	by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8zC8CaH1B2ev; Wed, 26 Nov 2008 16:50:21 +0000 (GMT)
Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18])
	by smtp.cs.tcd.ie (Postfix) with ESMTP id A9C5B3EA02;
	Wed, 26 Nov 2008 16:50:21 +0000 (GMT)
Message-ID: <492D7E49.40101@cs.tcd.ie>
Date: Wed, 26 Nov 2008 16:50:17 +0000
From: Stephen Farrell 
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: draft-ietf-ospf-lls@tools.ietf.org, ospf-chairs@ietf.org, 
	IESG , secdir@ietf.org
X-Enigmail-Version: 0.95.7
Content-Type: multipart/mixed; boundary="------------070906000204050803070406"
Subject: [secdir] secdir review of draft-ietf-ospf-lls
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

This is a multi-part message in MIME format.
--------------070906000204050803070406
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The draft [1] specifies a way to add new extension TLVs to/after OSPF
packets and includes a way to authenticate those.

I have a few things here that I think need attention, but they
can probably mostly be easily handled with additional clarifying
text. My comments are attached.

Stephen.

[1] http://tools.ietf.org/html/draft-ietf-ospf-lls




--------------070906000204050803070406
Content-Type: text/plain;
 name="ospf-lls-rev.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ospf-lls-rev.txt"


#1: Section 2.2 describes the use of the checksum field, but never says what to
do if the checksum is wrong. Is just the LLS block igored or the entire OSPF
message?

#2: Section 2.2 doesn't say whether the checksum bits (presumably zero'd?) are
considered part of the LLS block when calculating the checksum.

#3: I don't understand the reason for omitting the checksum if the
cryptographic authentication TLV is present. Since the spec doesn't say what to
put in the checksum field in that case, the absence of the checksum can't be
checked which'd lead the implementation to have to poke about looking for the
crypto. TLV before it knows what to do. That seems error prone. At the least,
more clarity as to the receiver actions is required.

#4: If the OSPF packet is not cryptographically authenticated, is it still ok
to include a cryptographic authentication TLV in the LLS? If so, what should I
do if the LLS crypto. fails to validate? Simplest might be to insist that
either both are protected or neither is, but I don't know if that matches the
requirements.

#5: Section 2.5 has no references and doesn't describe which algorithm is to be
used, now how keying is achieved. Questions arising include: a) rfc 2328
defines three types of authentication in appendix D, including Null
authentication - that one says to ignore the authentication field and use the
checksum, which seems to conflict with what this draft says (if crypto TLV
present, ignore checksum); b) similarly, the "simple password" method from 2328
also seems to require checking the checksum. (It might be as easy to just say
those two MUST NOT be used); c) I assume that the key lifecycle requirements
are the same as in 2328, appendix D.3 (if LLS is allowed to be authenticated
when the OSPFv2 packet is not, then this could be an issue). 

#6: Is it ok to use the same key & alg on the different inputs if the MD5 alg
from 2328 is re-used here with the same key and but different inputs? In that
case the OSPFv2 packet will contain MD5(OSPFv2-packet||key||pad||len) and the
LLS will contain MD5(LLS-data-block||key) where both the OSPFv2-packet and the
LLS-data-block contain the same sequence number. I don't have a specific
problem that I can call out with that but do wonder if its ok.  Ought it be
looked at by some cryptgrapher? (If a HMAC option is available then using that
would probably be better, or if a diiferent key, e.g. one derived from the key
protecting the OSPFv2-packet, were used for the LLS that might also be better.
But those would change the bits on the wire so might not be an option anymore?)

#7: Presumably it is not ok to include a cryptographic authentiation TLV in an
OSPFv3 packet? Might be worth a MUST NOT statement.

#8: If the crypto TLV is not the last TLV, then are the subsequent TLVs
included in the "LLS data block" input to the crypto processing? I think the
definition of the "LLS data block" as input to crypto processing needs to be
clearer - maybe take D.4.3 from 2328 as an example if the same MD5 alg is to be
used.

#9: If there are specific reasons why the crypto TLV might not be the last one,
that'd be worth noting.

#10: The cryptographic TLV doesn't (I think) protect the overall length of the
LLS (if I'm right in #8 above that TLVs following the crypto TLV are not
protected). In that case a single LLS mixes authenticated and unauthenticated
TLVs, which could allow an attacker to replace those that follow the crypto
TLV, or mess with the overall length or do other bad things. I think some
statement is required as to what a receiver MUST do in such cases, but I don't
know enough to suggest any text.  (Since the LLS can contain any extension, how
do we know its ok to mix authenticated and unauthenticated TLVs like that?)

Nits/Typos:

section 2.1 - "The L bit is only set in Hello and DD packets." Would that be
better as: "The L bit MUST NOT be set except in Hello and DD packets that
conain LLS." Might be more likely to be picked up by implementers?

section 2.3 - "...unique for each type of TLVs" s/TLVs/TLV/

section 2.3 - Seems odd to have a mixture of length fields that're sometimes in
32-bit words and sometimes in bytes but I assume its too late to change that
now.

section 4 - "...since OSPF router not..." s/router/routers/

section 5 - "...as OSPFv2 protocol..." s/OSPFv2/the OSPFv2/


--------------070906000204050803070406
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir

--------------070906000204050803070406--


From secdir-bounces@ietf.org  Wed Nov 26 09:50:42 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 605FA28C172;
	Wed, 26 Nov 2008 09:50:42 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9175328C161
	for ; Wed, 26 Nov 2008 09:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.413
X-Spam-Level: 
X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5
	tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id h19GfwLltR29 for ;
	Wed, 26 Nov 2008 09:50:39 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152])
	by core3.amsl.com (Postfix) with SMTP id 66E1128C0CE
	for ; Wed, 26 Nov 2008 09:50:39 -0800 (PST)
Received: (qmail 30525 invoked by uid 0); 26 Nov 2008 17:50:32 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (98.174.219.28)
	by woodstock.binhost.com with SMTP; 26 Nov 2008 17:50:32 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 26 Nov 2008 10:14:54 -0500
To: Samuel Weiler ,secdir@ietf.org,ietf@ietf.org
From: Russ Housley 
In-Reply-To: 
References: 
Mime-Version: 1.0
Message-Id: <20081126175039.66E1128C0CE@core3.amsl.com>
Cc: Harald Tveit Alvestrand 
Subject: Re: [secdir] secdir review of draft-housley-iesg-rfc3932bis-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Sam:

>That said, I'm puzzled by the continued inclusion of "rejected
>alternative bypass" as a reason to delay publication.  In section 4,
>this document proposes that readers could be confused by the order of
>publication of documents.  At the same time, this document is removing
>the mandatory IESG note from independent submissions in favor of a new
>header (defined in another doc, listed as a normative reference).  If
>that header is sufficient to dispel confusion when it comes to the
>substantive matters of "we haven't reviewed this", can't it also be
>relied on to be adequate to avoid confusion arising from publication
>order?  Accordingly, I suggest removing reason 3, as least so far as
>"rejected alternative bypass" is concerned.

There are two scenarios to consider.  They are AD-sponsored 
informational RFC and independent submission informational RFC.

1. AD-sponsored informational RFC

Here the title page will indicate IETF Stream for both 
documents.  The publication of the rejected alternative prior to the 
standards-track document leaves a time period where people that are 
not watching carefully do not know that the standards-track 
alternative is in the works.  If one only watches the RFC series, it 
is unclear that the other document is coming, and the first one 
indicates that is a product of the IETF.

Today, the AD will hold the rejected alternative until the 
standards-track document is in the RFC Editor queue, and the 
informational document will be published with a note indicating that 
a standards-track alternative is available in RFC xxxx.

2. Independent submission informational RFC

Here the title page will indicate that the standards-track document 
is part of the IETF Stream and that the rejected alternative will 
indicate that the informational document is part of the Independent 
Submission Stream.  The publication of the rejected alternative prior 
to the standards-track document leaves a time period where people 
that are not watching carefully do not know that the standards-track 
alternative is in the works.  If one only watches the RFC series, it 
is unclear that the other document is coming, but no one should be 
confused that the informational document was the product of the IETF.

Today, the IESG asks the RFC Editor to hold the rejected alternative 
until the standards-track document is in the RFC Editor queue, and 
the informational document will be published with a note indicating 
that a standards-track alternative is available in RFC xxxx.  That is 
the point of the response you are questioning.

Russ 

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Wed Nov 26 12:16:13 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 022F33A67DB;
	Wed, 26 Nov 2008 12:16:13 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B1D953A6877
	for ; Wed, 26 Nov 2008 12:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level: 
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 
	BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 1ilH87zX9AHm for ;
	Wed, 26 Nov 2008 12:16:10 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230])
	by core3.amsl.com (Postfix) with ESMTP id 6C19C3A67D4
	for ; Wed, 26 Nov 2008 12:16:10 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id b25so586280rvf.49
	for ; Wed, 26 Nov 2008 12:16:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from
	:organization:user-agent:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=UHXtJMSpoYUfD9MF6RCy8ZoVcvJ68qE5gTQb6TssEyo=;
	b=RgXSoSbNuSbaTd+zKTkUQdRKaP08lsEoHjGtTN7bjed3np0sHxYGA+xKXfSPLoZND3
	YAdBTYmfF8zmusKtDJygMuyATXbRcZX8Odq8qZ34vllkcQyupKxSoVn4weWC3lKaD1QH
	bcN1FKXFLPCaSt78F4pU+5JJY5TMnRL4V0Nl4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:organization:user-agent:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	b=wJKAsuIYW/6kRpwjuPXJjCFCpGI8TDWdGHFZkzvmfoXD2MGVtCNE6riRr7pFGwAN/k
	ZYIwqeF6RpO7kH0/E9v3k6AihTbXj3RA/lKnZV226a0GDu7ptrKxHPU5hayS8vbHEMy1
	1qm7ZeMC+/OzWWkGmVhsgpDGnBsZjEZQ4GER4=
Received: by 10.140.164.6 with SMTP id m6mr3081507rve.29.1227730566930;
	Wed, 26 Nov 2008 12:16:06 -0800 (PST)
Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz
	[130.216.38.124])
	by mx.google.com with ESMTPS id k2sm1103147rvb.1.2008.11.26.12.16.04
	(version=SSLv3 cipher=RC4-MD5); Wed, 26 Nov 2008 12:16:06 -0800 (PST)
Message-ID: <492DAE7C.8040308@gmail.com>
Date: Thu, 27 Nov 2008 09:15:56 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Samuel Weiler 
References: 
	<20081126175720.D74D428C1BD@core3.amsl.com>
In-Reply-To: <20081126175720.D74D428C1BD@core3.amsl.com>
Cc: Harald Tveit Alvestrand , ietf@ietf.org,
	secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-housley-iesg-rfc3932bis-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Sam,

I agree with Russ. I think the clearest possible result is the one
we achieved in the case appended below, but that required quite
some work in the absence of a well-defined procedure, even without
there being an independent submission to synchronize. I think the
draft makes such cases easier to get right.

    Brian

3246 An Expedited Forwarding PHB (Per-Hop Behavior). B. Davie, A.
     Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S.
     Davari, V. Firoiu, D. Stiliadis. March 2002. (Format: TXT=33896
     bytes) (Obsoletes RFC2598) (Status: PROPOSED STANDARD)

3247 Supplemental Information for the New Definition of the EF PHB
     (Expedited Forwarding Per-Hop Behavior). A. Charny, J. Bennet, K.
     Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C.
     Kalmanek, K. Ramakrishnan. March 2002. (Format: TXT=53786 bytes)
     (Status: INFORMATIONAL)

3248 A Delay Bound alternative revision of RFC 2598. G. Armitage, B.
     Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J.
     Schnizlein. March 2002. (Format: TXT=21597 bytes) (Status:
     INFORMATIONAL)

On 2008-11-27 04:14, Russ Housley wrote:
> Sam:
> 
>> That said, I'm puzzled by the continued inclusion of "rejected
>> alternative bypass" as a reason to delay publication.  In section 4,
>> this document proposes that readers could be confused by the order of
>> publication of documents.  At the same time, this document is removing
>> the mandatory IESG note from independent submissions in favor of a new
>> header (defined in another doc, listed as a normative reference).  If
>> that header is sufficient to dispel confusion when it comes to the
>> substantive matters of "we haven't reviewed this", can't it also be
>> relied on to be adequate to avoid confusion arising from publication
>> order?  Accordingly, I suggest removing reason 3, as least so far as
>> "rejected alternative bypass" is concerned.
> 
> There are two scenarios to consider.  They are AD-sponsored
> informational RFC and independent submission informational RFC.
> 
> 1. AD-sponsored informational RFC
> 
> Here the title page will indicate IETF Stream for both documents.  The
> publication of the rejected alternative prior to the standards-track
> document leaves a time period where people that are not watching
> carefully do not know that the standards-track alternative is in the
> works.  If one only watches the RFC series, it is unclear that the other
> document is coming, and the first one indicates that is a product of the
> IETF.
> 
> Today, the AD will hold the rejected alternative until the
> standards-track document is in the RFC Editor queue, and the
> informational document will be published with a note indicating that a
> standards-track alternative is available in RFC xxxx.
> 
> 2. Independent submission informational RFC
> 
> Here the title page will indicate that the standards-track document is
> part of the IETF Stream and that the rejected alternative will indicate
> that the informational document is part of the Independent Submission
> Stream.  The publication of the rejected alternative prior to the
> standards-track document leaves a time period where people that are not
> watching carefully do not know that the standards-track alternative is
> in the works.  If one only watches the RFC series, it is unclear that
> the other document is coming, but no one should be confused that the
> informational document was the product of the IETF.
> 
> Today, the IESG asks the RFC Editor to hold the rejected alternative
> until the standards-track document is in the RFC Editor queue, and the
> informational document will be published with a note indicating that a
> standards-track alternative is available in RFC xxxx.  That is the point
> of the response you are questioning.
> 
> Russ
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Wed Nov 26 20:29:48 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id ABD083A6A59;
	Wed, 26 Nov 2008 20:29:48 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C43443A6A36;
	Wed, 26 Nov 2008 20:29:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id VNy09sDcTq5f; Wed, 26 Nov 2008 20:29:46 -0800 (PST)
Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50])
	by core3.amsl.com (Postfix) with ESMTP id 2BAF83A6820;
	Wed, 26 Nov 2008 20:29:46 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com
	(Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25
	2004))
	with ESMTP id <0KAZ00IBS5T7DL00@mail-mta.sfvic.sunlabs.com>; Wed,
	26 Nov 2008 20:29:31 -0800 (PST)
Received: from [192.168.1.100] ([24.16.44.155])
	by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02
	(built
	Aug 25 2004)) with ESMTPSA id <0KAZ00FAD5T7JNM0@mail.sunlabs.com>; Wed,
	26 Nov 2008 20:29:31 -0800 (PST)
Date: Wed, 26 Nov 2008 20:29:33 -0800
From: Radia Perlman 
To: iesg@ietf.org, secdir@ietf.org, loa@PI.nu, rajiva@cisco.com
Message-id: <492E222D.3000408@sun.com>
MIME-version: 1.0
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
Subject: [secdir] secdir review of draft-ietf-mpls-cosfield-def-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document is proposing changing the name of a field in the MPLS header,
which used to be called "EXP" for "experimental", and they propose to
change it to "TC" for "traffic Class". This seems, as the security considerations
section states, to have no impact on security.

Radia

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Thu Nov 27 00:51:36 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8474528C16B;
	Thu, 27 Nov 2008 00:51:36 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6574228C175
	for ; Thu, 27 Nov 2008 00:51:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.214
X-Spam-Level: 
X-Spam-Status: No, score=-4.214 tagged_above=-999 required=5 tests=[AWL=2.385, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Sg73e--zOrxu for ;
	Thu, 27 Nov 2008 00:51:33 -0800 (PST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
	by core3.amsl.com (Postfix) with ESMTP id 4306128C16B
	for ; Thu, 27 Nov 2008 00:51:33 -0800 (PST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAR8pUbE002811
	for ; Thu, 27 Nov 2008 03:51:30 -0500
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mAR8pOoM002783
	for ; Thu, 27 Nov 2008 03:51:24 -0500
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	mAR8pHvY004096
	for ; Thu, 27 Nov 2008 03:51:17 -0500 (EST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de
	[212.201.44.23])
	by mit.edu (Spam Firewall) with ESMTP id 6AA6D13E5774
	for ; Thu, 27 Nov 2008 03:50:52 -0500 (EST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48])
	by hermes.jacobs-university.de (Postfix) with ESMTP id 6EF50C0071;
	Thu, 27 Nov 2008 09:50:52 +0100 (CET)
Received: from hermes.jacobs-university.de ([212.201.44.23])
	by localhost (demetrius3.jacobs-university.de [212.201.44.32])
	(amavisd-new, port 10024)
	with ESMTP id lCPODIWT6yfB; Thu, 27 Nov 2008 09:50:46 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133])
	by hermes.jacobs-university.de (Postfix) with ESMTP id B6250C0006;
	Thu, 27 Nov 2008 09:50:46 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501)
	id 728798850E0; Thu, 27 Nov 2008 09:50:45 +0100 (CET)
Date: Thu, 27 Nov 2008 09:50:45 +0100
From: Juergen Schoenwaelder 
To: Mike Eisler 
Message-ID: <20081127085045.GA6956@elstar.local>
Mail-Followup-To: Mike Eisler , iesg@ietf.org,
	secdir@mit.edu, nfsv4-chairs@tools.ietf.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Cc: secdir@mit.edu, iesg@ietf.org, nfsv4-chairs@tools.ietf.org
Subject: [secdir] secdir review of review-draft-ietf-nfsv4-rpc-netid-03.txt
X-BeenThere: secdir@ietf.org
Reply-To: j.schoenwaelder@jacobs-university.de
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document defines IANA registries for two parameters used in the
RPC binding protocol (r_netid and r_addr) [RFC1833] and as such does
not have any impact on network security by itself. However, the
current text in the Security Considerations section

   See section 9 of [7].

(where [7] means RFC 5226) should in my view be improved / replaced
since the text referred to does not really apply. Here is a proposal
of some text that might be a starting point for more meaningful
security considerations text:

   Since this document is only concerned with the IANA management of
   the Network Identifier (netid) and Universal Network Addresses
   (uaddrs) format registry, it raises no new security issues.

While taking a look at RFC 1833, I learned that RFC 1833 does not
discuss security issues at all. Is there a document discussing
security issues of the RPC Binding protocol?  I could not find
one. Are there any plans to revise RFC 1833? It seems to me that a
decent discussion of the security aspects of the Binding protocol is
somewhat important to have somewhere. This is a general observation I
like to share but not specific to the document I have reviewed.

Editorial comment:

I found the introduction and some other parts of the document
difficult to read. Sentences like "Since the publication of [2], it
has been found to be necessary that protocols like [5] and [6] ..."
caused to me to flip pages several times. I suggest to be a bit more
verbose to make it easier for readers, e.g. "Since the publication of
the RPC Bind protocol [RFC1833], it has been found to be necessary
that protocols like NFS version 4 [RFC3530] and Remote Direct Memory
Access [ID-RDMA] ...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Fri Nov 28 12:03:13 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4718D3A69E9;
	Fri, 28 Nov 2008 12:03:13 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CBDB73A683D;
	Fri, 28 Nov 2008 12:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id enDzsdegElLx; Fri, 28 Nov 2008 12:03:12 -0800 (PST)
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6])
	by core3.amsl.com (Postfix) with ESMTP id EC0903A67C1;
	Fri, 28 Nov 2008 12:03:11 -0800 (PST)
Received: from pgpdev.ihtfp.org (c-76-109-66-143.hsd1.fl.comcast.net
	[76.109.66.143])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "cliodev.ihtfp.com",
	Issuer "IHTFP Consulting Certification Authority" (verified OK))
	by mail.ihtfp.org (Postfix) with ESMTP id 8C0FC8B4005;
	Fri, 28 Nov 2008 15:03:07 -0500 (EST)
Received: (from warlord@localhost)
	by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id mASK3xjj026934;
	Fri, 28 Nov 2008 15:03:59 -0500
To: iesg@ietf.org, secdir@ietf.org
From: Derek Atkins 
Date: Fri, 28 Nov 2008 15:03:57 -0500
Message-ID: 
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Cc: 6man-chairs@tools.ietf.org, suresh.krishnan@ericsson.com
Subject: [secdir] sec-dir review of draft-ietf-6man-reserved-iids-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

While this document itself does not have any security issues (it's
just creating a registry with IANA) it brings up some interesting
points.  First, what methods should IANA use to "authenticate and
authorize" entities to create or update changes to the registry?  But
more importantly, what's to stop a rogue system from declaring itself
to use one of the reserved addresses?  And what happens to the network
as a whole if a system does this?

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From secdir-bounces@ietf.org  Fri Nov 28 13:18:22 2008
Return-Path: 
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B215428C0E1;
	Fri, 28 Nov 2008 13:18:22 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 34CC33A6977
	for ; Fri, 28 Nov 2008 13:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.526
X-Spam-Level: 
X-Spam-Status: No, score=-4.526 tagged_above=-999 required=5 tests=[AWL=2.073, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vsubmwnmV4LM for ;
	Fri, 28 Nov 2008 13:18:20 -0800 (PST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
	by core3.amsl.com (Postfix) with ESMTP id 5123C3A67C1
	for ; Fri, 28 Nov 2008 13:18:20 -0800 (PST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mASLIHAP016222
	for ; Fri, 28 Nov 2008 16:18:17 -0500
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id mASLIDPT016211
	for ; Fri, 28 Nov 2008 16:18:13 -0500
Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	mASLI7hc009004
	for ; Fri, 28 Nov 2008 16:18:08 -0500 (EST)
Received: from mailout12.yourhostingaccount.com
	(mailout12.yourhostingaccount.com [65.254.253.97])
	by mit.edu (Spam Firewall) with ESMTP id 4387AC7DF7E
	for ; Fri, 28 Nov 2008 16:17:47 -0500 (EST)
Received: from mailscan12.yourhostingaccount.com ([10.1.15.12]
	helo=mailscan12.yourhostingaccount.com)
	by mailout12.yourhostingaccount.com with esmtp (Exim)
	id 1L6Aig-0001v0-W6
	for secdir@mit.edu; Fri, 28 Nov 2008 16:17:47 -0500
Received: from impout03.yourhostingaccount.com ([10.1.55.3]
	helo=impout03.yourhostingaccount.com)
	by mailscan12.yourhostingaccount.com with esmtp (Exim)
	id 1L6Aig-0000xo-9p; Fri, 28 Nov 2008 16:17:46 -0500
Received: from authsmtp04.yourhostingaccount.com ([10.1.18.4])
	by impout03.yourhostingaccount.com with NO UCE
	id klHm1a00205G96J0000000; Fri, 28 Nov 2008 16:17:46 -0500
X-EN-OrigOutIP: 10.1.18.4
X-EN-IMPSID: klHm1a00205G96J0000000
Received: from c-98-216-48-22.hsd1.ma.comcast.net ([98.216.48.22]
	helo=Familyroom)
	by authsmtp04.yourhostingaccount.com with esmtpa (Exim)
	id 1L6Aif-0004ix-Po; Fri, 28 Nov 2008 16:17:46 -0500
Received: from Familyroom by Familyroom (PGP Universal service);
	Fri, 28 Nov 2008 16:17:42 -0500
X-PGP-Universal: processed;
	by Familyroom on Fri, 28 Nov 2008 16:17:42 -0500
From: "Patrick Cain" 
To: 
Date: Fri, 28 Nov 2008 16:17:34 -0500
Message-ID: <000901c9519e$be4bc890$3ae359b0$@com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AclRnqzX0V2yt1PQSn+3F2/xxN1/xg==
Content-Language: en-us
X-EN-UserInfo: 058f9b27fa04b0cf04458fb359a831ba:155e17fc3c7b3afdad05516cd0497062
X-EN-AuthUser: pcain@coopercain.com
X-EN-OrigIP: 98.216.48.22
X-EN-OrigHost: c-98-216-48-22.hsd1.ma.comcast.net
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Cc: secdir@mit.edu, iesg@ietf.org
Subject: [secdir]  secdir review of draft-ietf-ipdvb-sec-req-09
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Document synopsis (snipped):

The MPEG-2 standard defined by ISO 13818-1 supports a range of 
   transmission methods for a range of services. This document 
   provides a threat analysis and derives the security requirements 
   when using the Transport Stream, TS, to support an Internet 
   network-layer using Unidirectional Lightweight Encapsulation 
   (ULE) defined in RFC4326.

-----

I reviewed this document previously and my comments were addressed. The
document looks okay to me from a security standpoint. 

Pat Cain

_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir