From scott@hyperthought.com Tue Aug 3 14:32:02 2010 Return-Path: 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 EAE213A6B0A for ; Tue, 3 Aug 2010 14:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-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 5Y1dCAhCHKih for ; Tue, 3 Aug 2010 14:31:59 -0700 (PDT) Received: from smtp192.iad.emailsrvr.com (smtp192.iad.emailsrvr.com [207.97.245.192]) by core3.amsl.com (Postfix) with ESMTP id B77203A6768 for ; Tue, 3 Aug 2010 14:31:57 -0700 (PDT) Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8C80A1B425D; Tue, 3 Aug 2010 17:32:26 -0400 (EDT) Received: from dynamic2.wm-web.iad.mlsrvr.com (dynamic2.wm-web.iad.mlsrvr.com [192.168.2.151]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 79D3F1B407A; Tue, 3 Aug 2010 17:32:26 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic2.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 5DE0F28E8066; Tue, 3 Aug 2010 17:32:26 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 3 Aug 2010 14:32:26 -0700 (PDT) Date: Tue, 3 Aug 2010 14:32:26 -0700 (PDT) From: "Scott G. Kelly" To: "Ole Troan" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1280871146.382928184@192.168.2.231> X-Mailer: webmail8 Cc: draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org, cpe-router@external.cisco.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router 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: , X-List-Received-Date: Tue, 03 Aug 2010 21:32:02 -0000 Hi Ole,=0A=0AOn Monday, August 2, 2010 5:58am, "Ole Troan" s= aid:=0A=0A=0A>=0A>> The security considerations section begins = with a paragraph stating that basic=0A>> stateless egress and ingress filte= rs should be supported (lowercase "should"),=0A>> and goes on to say that t= he CE router should offer mechanisms to filter traffic=0A>> entering the cu= stomer network, but that how these are implemented is out of scope=0A>> (lo= wercase "should").=0A> =0A> we tried to limit RFC2119 language to only the = numbered requirements. the initial=0A> paragraph is only to set the stage f= or the more detailed requirements below.=0A> basically just saying that the= CPE should support a packet filtering capability.=0A> but from a security = point of view I'm not sure if we can state this in very much=0A> more concr= ete terms?=0A=0AOkay, I guess it makes more sense when viewed as introducto= ry text for the numbered requirements.=0A=0A>> Then, it has the following s= tatements:=0A>>=0A>> Security requirements:=0A>>=0A>> S-1: The IPv6 CE= router SHOULD support=0A>> [I-D.ietf-v6ops-cpe-simple-security].= =0A>>=0A>> S-2: The IPv6 CE router MUST support ingress filtering in acc= ordance=0A>> with [RFC2827] (BCP 38)=0A>>=0A>> When I first read th= is, I thought the statements in the first paragraph were=0A>> somewhat weak= and imprecise, as they don't use RFC2119 language. When I read=0A>> draft-= ietf-v6ops-cpe-simple-security-12.txt, I thought that document gives a=0A>>= relatively thorough treatment of security considerations, but I'm not sure= what=0A>> it means to say "The IPv6 CE router SHOULD support" it.=0A> =0A>= the intention was to state the the CPE router should have the capability o= f doing=0A> the functions described in the simple security draft. but we di= d not want to make=0A> any recommendation what the default should be. I bel= ieve recommending that simple=0A> security is enabled by default in a CPE r= outers would violate the Internet=0A> architecture principles. would it hel= p if we changed the text to:=0A> =0A> S-1: The IPv6 CE router SHOULD suppor= t the [I-D.ietf-v6ops-cpe-simple-security].=0A> This functionality MUST be = user configurable and this=0A> specification makes no recommendatio= n what the default setting should be.=0A=0ASince the referenced draft is in= formational and does not mandate any behavior (it only makes non-binding re= commendations), I'm still confused about what it means to "support" it - it= seems very difficult to pin down. Do you mean that these devices MUST prov= ide knobs for all capabilities defined there, or just some of them (and if = so, which ones)? =0A=0ASince both of these documents are informational, per= haps it doesn't matter, but it seems like we'd be doing the user community = a better service if we took a definite position on baseline security requir= ements for these devices.=0A=0A =0A> while on the topic of= security. we should perhaps have said something more about=0A> device secu= rity. as in requirements for access to the device itself. today many of=0A>= these routers allow telnet and http access, more often than not with defau= lt=0A> password. where they also make a distinction between 'inside' and 'o= utside', which=0A> some recent attacks have taken advantage of.=0A=0AThe si= mple security document does reference management applications (section 3.5)= , but only states that they should not be accessible on the WAN interface b= y default. It might be worthwhile to update it according to your thoughts a= bove. =0A=0A--Scott=0A From new-work-bounces@ietf.org Sun Aug 1 05:16:03 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838203A6B38; Sun, 1 Aug 2010 05:16:03 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE583A6B0A for ; Sun, 1 Aug 2010 05:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 ntV9Y2Zzj7EI for ; Sun, 1 Aug 2010 05:15:55 -0700 (PDT) Received: from mail8.itu.ch (mail8.itu.ch [156.106.192.38]) by core3.amsl.com (Postfix) with ESMTP id 1EC863A6A14 for ; Sun, 1 Aug 2010 05:15:54 -0700 (PDT) Received: from PROTINT1.blue.itu.ch (protint1.itu.ch [156.106.128.47]) by mail8.itu.ch (8.13.8/8.14.4) with ESMTP id o71CGKJC002104 for ; Sun, 1 Aug 2010 14:16:21 +0200 Received: from mailbox3.blue.itu.ch ([156.106.134.231]) by PROTINT1.blue.itu.ch with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Aug 2010 14:16:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 1 Aug 2010 14:16:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New ITU-T Study Group 16 Question: "Telepresence systems" Thread-Index: Acsxc1k9m1uClo+0RheIyVJkGrYVMA== From: To: X-OriginalArrivalTime: 01 Aug 2010 12:16:20.0878 (UTC) FILETIME=[59DBFAE0:01CB3173] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (mail8.itu.ch [156.106.192.38]); Sun, 01 Aug 2010 14:16:21 +0200 (CEST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: multipart/mixed; boundary="===============1229249115==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 04 Aug 2010 04:08:54 -0700 Subject: [secdir] [New-work] New ITU-T Study Group 16 Question: "Telepresence systems" X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 12:16:03 -0000 This is a multi-part message in MIME format. --===============1229249115== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3173.5A0750C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3173.5A0750C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At its 19-30 July 2010 meeting, ITU-T Study Group 16 agreed to the creation of a new Question entitled "Telepresence systems": New ITU-T Study Group 16 Question 5/16: Telepresence systems 1. Motivation Telepresence represents an important evolution of the videoconferencing market. This trend is expected to accelerate, as mainstream video applications begin to offer telepresence features. Many products exist today that, although they are based on IETF SIP and ITU-T H.323 protocols, lack interoperability due to proprietary extensions needed to these base protocols to offer a user-rich experience. The increased penetration of broadband communications and higher user awareness of video applications, coupled with financial and environmental gains brought by remote collaboration tools have brought a boost to applications such as telepresence. This makes it important that standardized solutions be developed to ensure multi-vendor interoperability on a global basis. 2. Question Study items to be considered include, but are not limited to: * Definition and scope of telepresence systems * Functions and service requirements for interoperable telepresence systems * Standardizing the means for full interworking between telepresence systems, including means facilitating the coherent presentation of multiple audio and video streams - allowing remote participants to be rendered at their true size for their apparent distance, maintaining correct eye contact, gesticular cues, and simultaneously providing spatial audio that is consistent with the video presentation, as well as taking into account the meeting environment to provide a more immersive experience. * Standardizing the means for interworking between current telepresence systems and other systems, including the legacy telephone network and advanced multimedia systems, through additions to ITU-T H.246 and other Recommendations as necessary. * Considerations on how to further enhance telepresence systems to mitigate negative impact on climate change and to encourage a positive impact reducing greenhouse gas (GHG) emissions. 3. Tasks Tasks include but are not limited to: * Define services and functions to support interoperability of current generation telepresence systems using existing protocols such as ITU-T H.323 and SIP. * Identify modification and/or extensions needed in existing protocols to support telepresence, in coordination with other standardization bodies, forums and consortia, as needed. * Modify and/or extend existing protocols under the ITU-T SG 16 responsibility to enable interoperable telepresence systems (in particular, Recommendations of the ITU-T H.300 series). * Identify methods for exchange of meeting environment information in order to allow adaptation between unlike telepresence system environments. * Provide guidelines to achieve the required user experience for telepresence systems (such as methods to achieve eye contact, same lighting environments in separate rooms, audio levels, and echo cancellation). * Identify requirements for media codecs, taking into account needs for scalability, multiple views, multiple audio channels, and mixing of media streams including efficient compressed digital to compressed digital processing. * Enable interoperable telecoms/ICT accessibility features in telepresence systems. * Identify requirements towards second-generation telepresence systems. * Consider the role of control systems in telepresence systems. 4. Relationships Recommendations: H. series and relevant F/G/T-series Questions: Q1/16 (Multimedia systems and terminals), Q2/16 (H.323 systems), Q3/16 (Multimedia Gateways), Q4/16 (QoS), Q6/16 (Visual Coding), Q7/16 (Systems and coordination aspects of media coding), Q10/16 (Speech and audio coding and related software tools), Q12/16 (AMS), Q13/16 (IPTV), Q16/16 (Speech enhancement functions in signal processing network equipment), Q18/16 (Interaction aspects of signal processing network equipment), Q22/16 (Multimedia applications and services), Q26/16 (Accessibility to Multimedia Systems and Services) Study Groups: * ITU-T Study Groups: 5 (Environment and Climate Change), 9 (cable, video quality), 11 (signalling), 12 (QoS, QoE, Quality assessment methodologies), 13 (NGN, future networks), 17 (Security, languages) * ITU-R Study Group 6 (Broadcasting) * ITU-D Study Group 2 Standardization bodies, forums and consortia: * ISO/IEC JTC 1/SC 29 "Coding of audio, picture, multimedia and hypermedia information" * International Multimedia Teleconferencing Consortium (IMTC) for interoperability aspects and enhancements to existing Recommendations * IETF Real-time Applications and Infrastructure (RAI) for IETF-defined protocols * Unified Communications Interoperability Forum (UCIF) for interoperability aspects between enterprises, service providers, and consumer clouds. ------_=_NextPart_001_01CB3173.5A0750C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New ITU-T Study Group 16 Question: "Telepresence = systems"

At its 19-30 July 2010 meeting, ITU-T = Study Group 16 agreed to the creation of a new Question entitled = “Telepresence systems”:

New ITU-T = Study Group 16 Question 5/16:  Telepresence systems

1. Motivation
Telepresence = represents an important evolution of the videoconferencing market. This = trend is expected to accelerate, as mainstream video applications begin = to offer telepresence features.  Many products exist today that, = although they are based on IETF SIP and ITU-T H.323 protocols, lack = interoperability due to proprietary extensions needed to these base = protocols to offer a user-rich experience.

The increased = penetration of broadband communications and higher user awareness of = video applications, coupled with financial and environmental gains = brought by remote collaboration tools have brought a boost to = applications such as telepresence.  This makes it important that = standardized solutions be developed to ensure multi-vendor = interoperability on a global basis.

2. Question
Study items to = be considered include, but are not limited to:

    • Definition and = scope of telepresence systems
    • Functions and = service requirements for interoperable telepresence = systems
    • Standardizing = the means for full interworking between telepresence systems, including = means facilitating the coherent presentation of multiple audio and video = streams – allowing remote participants to be rendered at their = true size for their apparent distance, maintaining correct eye contact, = gesticular cues, and simultaneously providing spatial audio that is = consistent with the video presentation, as well as taking into account = the meeting environment to provide a more immersive = experience.
    • Standardizing = the means for interworking between current telepresence systems and = other systems, including the legacy telephone network and advanced = multimedia systems, through additions to ITU-T H.246 and other = Recommendations as necessary.
    • Considerations = on how to further enhance telepresence systems to mitigate negative = impact on climate change and to encourage a positive impact reducing = greenhouse gas (GHG) emissions.

3. Tasks
Tasks include = but are not limited to:

    • Define services = and functions to support interoperability of current generation = telepresence systems using existing protocols such as ITU-T H.323 and = SIP.
    • Identify = modification and/or extensions needed in existing protocols to support = telepresence, in coordination with other standardization bodies, forums = and consortia, as needed.
    • Modify and/or = extend existing protocols under the ITU-T SG 16 responsibility to enable = interoperable telepresence systems (in particular, Recommendations of = the ITU-T H.300 series).
    • Identify methods = for exchange of meeting environment information in order to allow = adaptation between unlike telepresence system = environments.
    • Provide = guidelines to achieve the required user experience for telepresence = systems (such as methods to achieve eye contact, same lighting = environments in separate rooms, audio levels, and echo = cancellation).
    • Identify = requirements for media codecs, taking into account needs for = scalability, multiple views, multiple audio channels, and mixing of = media streams including efficient compressed digital to compressed = digital processing.
    • Enable = interoperable telecoms/ICT accessibility features in telepresence = systems.
    • Identify = requirements towards second-generation telepresence = systems.
    • Consider the = role of control systems in telepresence systems.

4. Relationships
Recommendations:
H. series and = relevant F/G/T-series
Questions:
Q1/16 = (Multimedia systems and terminals), Q2/16 (H.323 systems), = Q3/16 (Multimedia Gateways), Q4/16 (QoS), Q6/16 (Visual = Coding), Q7/16 (Systems and coordination aspects of media = coding), Q10/16 (Speech and audio coding and related software = tools), Q12/16 (AMS), Q13/16 (IPTV), Q16/16 (Speech = enhancement functions in signal processing network equipment), = Q18/16 (Interaction aspects of signal processing network = equipment), Q22/16 (Multimedia applications and services), = Q26/16 (Accessibility to Multimedia Systems and = Services)

Study = Groups:

    • ITU-T Study = Groups: 5 (Environment and = Climate Change), 9 = (cable, video = quality), 11 (signalling), 12 (QoS, QoE, Quality = assessment methodologies), 13 = (NGN, future = networks), 17 (Security, languages)
    • ITU-R Study = Group 6 (Broadcasting)
    • ITU-D Study = Group 2

Standardization bodies, forums and consortia:

    • ISO/IEC JTC 1/SC = 29 "Coding of audio, = picture, multimedia and hypermedia information"
    • International = Multimedia Teleconferencing Consortium (IMTC) for interoperability = aspects and enhancements to existing Recommendations
    • IETF Real-time = Applications and Infrastructure (RAI) for IETF-defined = protocols
    • Unified = Communications Interoperability Forum (UCIF) for interoperability = aspects between enterprises, service providers, and consumer = clouds.

------_=_NextPart_001_01CB3173.5A0750C0-- --===============1229249115== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============1229249115==-- From ot@cisco.com Mon Aug 2 05:58:11 2010 Return-Path: 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 711C63A68B7; Mon, 2 Aug 2010 05:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 w-48KMPIp6M8; Mon, 2 Aug 2010 05:58:10 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 42FA53A67F5; Mon, 2 Aug 2010 05:58:10 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALddVkxAZnwM/2dsb2JhbACgDnGmIpp8gxCCKQSIfw X-IronPort-AV: E=Sophos;i="4.55,302,1278288000"; d="scan'208";a="142274304" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Aug 2010 12:58:36 +0000 Received: from dhcp-osl-vl300-64-103-53-101.cisco.com (dhcp-osl-vl300-64-103-53-101.cisco.com [64.103.53.101]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o72CwZL0003670; Mon, 2 Aug 2010 12:58:35 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ole Troan X-Priority: 3 (Normal) In-Reply-To: <1280060673.59399192@192.168.2.231> Date: Mon, 2 Aug 2010 14:58:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1280060673.59399192@192.168.2.231> To: "Scott G. Kelly" X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Wed, 04 Aug 2010 04:08:54 -0700 Cc: draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org, cpe-router@external.cisco.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router 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: , X-List-Received-Date: Mon, 02 Aug 2010 12:58:11 -0000 Scott, thank you very much for a thorough review! some further comments 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. = 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. >=20 > As the title implies, this document discusses basic requirements for = IPv6 customer edge routers. The comments given here are limited to = security only. >=20 > The security considerations section begins with a paragraph stating = that basic stateless egress and ingress filters should be supported = (lowercase "should"), and goes on to say that the CE router should offer = mechanisms to filter traffic entering the customer network, but that how = these are implemented is out of scope (lowercase "should"). we tried to limit RFC2119 language to only the numbered requirements. = the initial paragraph is only to set the stage for the more detailed = requirements below. basically just saying that the CPE should support a = packet filtering capability. but from a security point of view I'm not = sure if we can state this in very much more concrete terms? > Then, it has the following statements: >=20 > Security requirements: >=20 > S-1: The IPv6 CE router SHOULD support > [I-D.ietf-v6ops-cpe-simple-security]. >=20 > S-2: The IPv6 CE router MUST support ingress filtering in = accordance > with [RFC2827] (BCP 38) >=20 > When I first read this, I thought the statements in the first = paragraph were somewhat weak and imprecise, as they don't use RFC2119 = language. When I read draft-ietf-v6ops-cpe-simple-security-12.txt, I = thought that document gives a relatively thorough treatment of security = considerations, but I'm not sure what it means to say "The IPv6 CE = router SHOULD support" it.=20 the intention was to state the the CPE router should have the capability = of doing the functions described in the simple security draft. but we = did not want to make any recommendation what the default should be. I = believe recommending that simple security is enabled by default in a CPE = routers would violate the Internet architecture principles. would it = help if we changed the text to: S-1: The IPv6 CE router SHOULD support the = [I-D.ietf-v6ops-cpe-simple-security]. This functionality MUST be user = configurable and this specification makes no recommendation what the default setting = should be. >=20 > What does this mean? Since the referenced ID only makes = recommendations (and explicitly states the RFC2119 language is not = binding) what does it mean to "support" it? Must a device implement all = recommendations? Must it implement only certain ones?=20 >=20 > I think it makes sense to reference the simple security document = rather than re-writing significant sections of it here, but I also think = that this statement of security requirements should be considerably more = precise. while on the topic of security. we should perhaps have said something = more about device security. as in requirements for access to the device = itself. today many of these routers allow telnet and http access, more = often than not with default password. where they also make a distinction = between 'inside' and 'outside', which some recent attacks have taken = advantage of. does the security directorate have any other (and more detailed) = recommendations they would have liked to see in this document? cheers, Ole From scott@hyperthought.com Fri Aug 6 11:50:13 2010 Return-Path: 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 378B33A6912 for ; Fri, 6 Aug 2010 11:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 QbFTU-k7tgpH for ; Fri, 6 Aug 2010 11:50:11 -0700 (PDT) Received: from smtp122.iad.emailsrvr.com (smtp122.iad.emailsrvr.com [207.97.245.122]) by core3.amsl.com (Postfix) with ESMTP id 5CB9A3A6898 for ; Fri, 6 Aug 2010 11:50:11 -0700 (PDT) Received: from relay22.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id DAFBE1B40CA; Fri, 6 Aug 2010 14:50:42 -0400 (EDT) Received: from dynamic3.wm-web.iad.mlsrvr.com (dynamic3.wm-web.iad.mlsrvr.com [192.168.2.152]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id C67171B40D9; Fri, 6 Aug 2010 14:50:42 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic3.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id B1FC5332006E; Fri, 6 Aug 2010 14:50:42 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 6 Aug 2010 11:50:42 -0700 (PDT) Date: Fri, 6 Aug 2010 11:50:42 -0700 (PDT) From: "Scott G. Kelly" To: "Chris Donley" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg> References: <1280871146.382928184@192.168.2.231> <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg> Message-ID: <1281120642.72688236@192.168.2.229> X-Mailer: webmail8 Cc: "draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org" , Ole Troan , "cpe-router@external.cisco.com" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router 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: , X-List-Received-Date: Fri, 06 Aug 2010 18:50:13 -0000 Hi Chris,=0A=0AI think your suggestions are reasonable.=0A=0A--Scott=0A=0A= =0AOn Thursday, August 5, 2010 8:00am, "Chris Donley" said:=0A=0A> Scott,=0A> =0A> If we were to make the following changes t= o the security section, would they=0A> address your concerns?=0A> =0A> It i= s considered a best practice to filter obviously malicious=0A> traffic (= e.g. spoofed packets, "martian" addresses, etc.). Thus, the=0A> IPv6 CE= router should ought to support basic stateless egress and ingress=0A> f= ilters. The CE router should is also expected to offer mechanisms to filte= r=0A> traffic entering the customer network; however, the method by whic= h=0A> vendors implement configurable packet filtering is beyond the scop= e=0A> of this document.=0A> =0A> Security requirements:=0A> =0A> S= -1: The IPv6 CE router SHOULD support=0A> [I-D.ietf-v6ops-cpe-sim= ple-security]. In particular, the IPv6 CE router=0A> SHOULD support functio= nality sufficient for implementing the set of=0A> recommendations in [I-D.i= etf-v6ops-cpe-simple-security] Section 4. This=0A> document takes no posit= ion on whether such functionality is enabled by=0A> default or mechanisms b= y which users would configure it.=0A> =0A> S-2: The IPv6 CE router MUST= support ingress filtering in accordance=0A> with [RFC2827] (BCP 3= 8)=0A> =0A> =0A> Also, since we're so late in the process, my preference wo= uld be to specify device=0A> security as part of our Phase 2 draft (schedul= ed to start work on 8/13). Would=0A> you have any issue with that?=0A> =0A= > Chris=0A> =0A> -----Original Message-----=0A> From: Scott G. Kelly [mailt= o:scott@hyperthought.com]=0A> Sent: Tuesday, August 03, 2010 3:32 PM=0A> To= : Ole Troan=0A> Cc: secdir@ietf.org; iesg@ietf.org;=0A> draft-ietf-v6ops-ip= v6-cpe-router.all@tools.ietf.org;=0A> cpe-router@external.cisco.com=0A> Sub= ject: Re: secdir review of draft-ietf-v6ops-ipv6-cpe-router=0A> =0A> Hi Ole= ,=0A> =0A> On Monday, August 2, 2010 5:58am, "Ole Troan" sai= d:=0A> =0A> =0A>>=0A>>> The security considerations section beg= ins with a paragraph stating that basic=0A>>> stateless egress and ingress = filters should be supported (lowercase "should"),=0A>>> and goes on to say = that the CE router should offer mechanisms to filter traffic=0A>>> entering= the customer network, but that how these are implemented is out of=0A>>> s= cope=0A>>> (lowercase "should").=0A>>=0A>> we tried to limit RFC2119 langua= ge to only the numbered requirements. the=0A>> initial=0A>> paragraph is on= ly to set the stage for the more detailed requirements below.=0A>> basicall= y just saying that the CPE should support a packet filtering capability.=0A= >> but from a security point of view I'm not sure if we can state this in v= ery much=0A>> more concrete terms?=0A> =0A> Okay, I guess it makes more sen= se when viewed as introductory text for the=0A> numbered requirements.=0A> = =0A>>> Then, it has the following statements:=0A>>>=0A>>> Security requir= ements:=0A>>>=0A>>> S-1: The IPv6 CE router SHOULD support=0A>>> = [I-D.ietf-v6ops-cpe-simple-security].=0A>>>=0A>>> S-2: The IPv6 CE rout= er MUST support ingress filtering in accordance=0A>>> with [RFC2827= ] (BCP 38)=0A>>>=0A>>> When I first read this, I thought the statements in = the first paragraph were=0A>>> somewhat weak and imprecise, as they don't u= se RFC2119 language. When I read=0A>>> draft-ietf-v6ops-cpe-simple-security= -12.txt, I thought that document gives a=0A>>> relatively thorough treatmen= t of security considerations, but I'm not sure what=0A>>> it means to say "= The IPv6 CE router SHOULD support" it.=0A>>=0A>> the intention was to state= the the CPE router should have the capability of=0A>> doing=0A>> the funct= ions described in the simple security draft. but we did not want to=0A>> ma= ke=0A>> any recommendation what the default should be. I believe recommendi= ng that=0A>> simple=0A>> security is enabled by default in a CPE routers wo= uld violate the Internet=0A>> architecture principles. would it help if we = changed the text to:=0A>>=0A>> S-1: The IPv6 CE router SHOULD support the [= I-D.ietf-v6ops-cpe-simple-security].=0A>> This functionality MUST be user c= onfigurable and this=0A>> specification makes no recommendation wha= t the default setting should=0A>> be.=0A> =0A> Since the referenced draft i= s informational and does not mandate any behavior (it=0A> only makes non-bi= nding recommendations), I'm still confused about what it means to=0A> "supp= ort" it - it seems very difficult to pin down. Do you mean that these devic= es=0A> MUST provide knobs for all capabilities defined there, or just some = of them (and=0A> if so, which ones)?=0A> =0A> Since both of these documents= are informational, perhaps it doesn't matter, but it=0A> seems like we'd b= e doing the user community a better service if we took a definite=0A> posit= ion on baseline security requirements for these devices.=0A> =0A> =0A>> while on the topic of security. we should perhaps have said s= omething more about=0A>> device security. as in requirements for access to = the device itself. today many=0A>> of=0A>> these routers allow telnet and h= ttp access, more often than not with default=0A>> password. where they also= make a distinction between 'inside' and 'outside',=0A>> which=0A>> some re= cent attacks have taken advantage of.=0A> =0A> The simple security document= does reference management applications (section 3.5),=0A> but only states = that they should not be accessible on the WAN interface by=0A> default. It = might be worthwhile to update it according to your thoughts above.=0A> =0A>= --Scott=0A> =0A> =0A> =0A> =0A From weiler@watson.org Sat Aug 7 05:55:55 2010 Return-Path: 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 9FFE73A67AE for ; Sat, 7 Aug 2010 05:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_20=-0.74] 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 4XFvZwTcXwGQ for ; Sat, 7 Aug 2010 05:55:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 475D33A635F for ; Sat, 7 Aug 2010 05:55:53 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o77CuPsk032539 for ; Sat, 7 Aug 2010 08:56:25 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o77CuPsA032535 for ; Sat, 7 Aug 2010 08:56:25 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 7 Aug 2010 08:56:25 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 07 Aug 2010 08:56:25 -0400 (EDT) Subject: [secdir] Assignments 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: , X-List-Received-Date: Sat, 07 Aug 2010 12:55:55 -0000 Eric Rescorla is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The assignment email format has changed to show last call end dates for all docs, even those scheduled for telechat. Special requests won't have one, nor will docs for which as LC has been requested but not yet issued. For telechat 2010-08-12 Reviewer LC end Draft Rob Austein T 2010-07-12 draft-ietf-forces-applicability-09 Alan DeKok T 2010-07-12 draft-ietf-forces-implementation-report-02 Shawn Emery T 2010-07-14 draft-ietf-ippm-twamp-reflect-octets-07 Tobias Gondrom T 2010-08-04 draft-davis-u-langtag-ext-03 Russ Mundy T 2010-08-05 draft-ietf-v6ops-isp-scenarios-00 Sandy Murphy T 2010-07-30 draft-ietf-softwire-ds-lite-tunnel-option-03 For telechat 2010-08-26 Reviewer LC end Draft Nico Williams T 2010-07-16 draft-turner-suiteb-cmc-03 Last calls and special requests: Reviewer LC end Draft Stephen Farrell - draft-baker-v6ops-greynet-04 Phillip Hallam-Baker 2010-07-23 draft-ietf-geopriv-arch-02 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-08 Jeffrey Hutzelman 2010-07-23 draft-ietf-pkix-ta-mgmt-reqs-05 Julien Laganier - draft-ietf-nsis-nslp-auth-06 Barry Leiba 2010-08-12 draft-saintandre-tls-server-id-check-09 Chris Lonvick 2010-08-05 draft-ietf-netmod-arch-07 David McGrew - draft-ietf-ecrit-framework-11 David McGrew 2010-08-05 draft-ietf-pce-manageability-requirements-10 Catherine Meadows - draft-ietf-tcpm-tcp-lcd-02 Chris Newman 2010-08-23 draft-azinger-additional-private-ipv4-space-issues-04 Magnus Nystrom - draft-ietf-isms-radius-vacm-09 Hilarie Orman - draft-ietf-calsify-rfc2447bis-10 Radia Perlman - draft-ietf-isis-genapp-03 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Brian Weis 2010-07-16 draft-daboo-srv-caldav-05 Larry Zhu 2010-08-12 draft-thaler-v6ops-teredo-extensions-07 Larry Zhu - draft-ietf-sip-domain-certs-07 Glen Zorn 2010-07-26 draft-cakulev-mikey-ibake-01 From stephen.farrell@cs.tcd.ie Sat Aug 7 11:28:18 2010 Return-Path: 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 B5D2E3A6842 for ; Sat, 7 Aug 2010 11:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 p8q+GskTK11j for ; Sat, 7 Aug 2010 11:28:17 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 9B6243A683A for ; Sat, 7 Aug 2010 11:28:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 50B733E4082; Sat, 7 Aug 2010 19:28:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1281205727; bh=zJI40hG+C1tl9wfrRe8yvW02 jH7Ao05h3xQtBkMyeZ4=; b=NsFg1wkfv1OOx7H7d99qxE4rj+Z/NWmFPdI2FR2E FmSXmzppTV/MltNf0q0HPZ2Zo5/AHRf36NNmUzs/7KKnzSnLdrBgqaybh2EWfFhk VbB6tmRRSVO4RKXiW8H09SXQu9MrLq/1hAtyW8L9P918oGiaA2H/rnDb8LsT5wmt Xv005iOd4weu+D0gbg/A72hIuOVXVaYfKsLmXND49QKYZkHuyaPW8xlUk6qDA6xk 1S3f2y5wYFZqKRdJoX27/f8cqp0f3OxLvGHlgxng2qZxBIOz5LH3gHzh/y/U7n6N sTER7n2WGQqRCi/P3/+KDx5wxaCATNO3xqz/06hjjUH2Tg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ciEG-xRBkmr7; Sat, 7 Aug 2010 19:28:47 +0100 (IST) Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 09CCD3E4080; Sat, 7 Aug 2010 19:28:45 +0100 (IST) Message-ID: <4C5DA5D6.1080900@cs.tcd.ie> Date: Sat, 07 Aug 2010 19:28:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: secdir@ietf.org, draft-baker-v6ops-greynet.all@tools.ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-baker-v6ops-greynet 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: , X-List-Received-Date: Sat, 07 Aug 2010 18:28:18 -0000 This document describes some ideas for sensors for unexpected traffic using otherwise-unused IPv4 and IPv6 addresses. The document seems fine to me. Stephen. PS: Sorry for the late review. From fred@cisco.com Sat Aug 7 13:11:36 2010 Return-Path: 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 208953A6924 for ; Sat, 7 Aug 2010 13:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.132 X-Spam-Level: X-Spam-Status: No, score=-110.132 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Wx5C75V6X6Nl for ; Sat, 7 Aug 2010 13:11:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AD4023A68FD for ; Sat, 7 Aug 2010 13:11:34 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACtbXUyrR7Hu/2dsb2JhbACgT3Gnb5pphToEiTs X-IronPort-AV: E=Sophos;i="4.55,335,1278288000"; d="scan'208";a="237157531" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 07 Aug 2010 20:12:07 +0000 Received: from vtctremolo.cisco.com (sjc-vpn3-1117.cisco.com [10.21.68.93]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o77KBv7Y000832; Sat, 7 Aug 2010 20:11:59 GMT Received: from [127.0.0.1] by vtctremolo.cisco.com (PGP Universal service); Sat, 07 Aug 2010 16:12:06 -0400 X-PGP-Universal: processed; by vtctremolo.cisco.com on Sat, 07 Aug 2010 16:12:06 -0400 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <4C5DA5D6.1080900@cs.tcd.ie> Date: Sat, 7 Aug 2010 16:11:50 -0400 Message-Id: References: <4C5DA5D6.1080900@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Ron Bonica , draft-baker-v6ops-greynet.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-baker-v6ops-greynet 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: , X-List-Received-Date: Sat, 07 Aug 2010 20:11:36 -0000 Thanks On Aug 7, 2010, at 2:28 PM, Stephen Farrell wrote: > > This document describes some ideas for sensors for > unexpected traffic using otherwise-unused IPv4 and > IPv6 addresses. > > The document seems fine to me. > > Stephen. > > PS: Sorry for the late review. http://www.ipinc.net/IPv4.GIF From shawn.emery@oracle.com Sat Aug 7 23:01:19 2010 Return-Path: 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 F2B783A67F4; Sat, 7 Aug 2010 23:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.618 X-Spam-Level: X-Spam-Status: No, score=-6.618 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 eyS0zkeiH75R; Sat, 7 Aug 2010 23:01:17 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 278493A66B4; Sat, 7 Aug 2010 23:01:15 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7861k1D008330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Aug 2010 06:01:47 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o782aEjL023308; Sun, 8 Aug 2010 06:01:46 GMT Received: from abhmt010.oracle.com by acsmt354.oracle.com with ESMTP id 476386761281247257; Sat, 07 Aug 2010 23:00:57 -0700 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 Aug 2010 23:00:57 -0700 Message-ID: <4C5E4818.5040308@oracle.com> Date: Sun, 08 Aug 2010 00:00:56 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100610 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ippm-twamp-reflect-octets.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-ippm-twamp-reflect-octets-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: , X-List-Received-Date: Sun, 08 Aug 2010 06:01:19 -0000 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 describes two optional features of the Two-Way Active Measurement Protocol (TWAMP): a. The ability of a controller host to tag packets to allow simplified identification. b. A sender packet format that allows test packets of equal size to be sent each way. The security considerations section does exist and I've followed the references to the One-way Active Measurement Protocol (OWAMP) security considerations section, which TWAMP extends. OWAMP has a nice write-up of the various attacks and how to mitigate such attacks. I don't believe the new TWAMP features discussed in this draft introduces any new vectors beyond what OWAMP/TWAMP already has. General comments: None. Editorial comments: Closing parentheses missing: (by the Server or Session-Reflector Shawn. -- From C.Donley@cablelabs.com Thu Aug 5 08:09:05 2010 Return-Path: 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 E83753A6814; Thu, 5 Aug 2010 08:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 QZxjjCWrbRmQ; Thu, 5 Aug 2010 08:09:04 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 465993A69A9; Thu, 5 Aug 2010 08:09:04 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o75F01RH016364; Thu, 5 Aug 2010 09:00:02 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 5 Aug 2010 09:00:02 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 5 Aug 2010 09:00:02 -0600 From: Chris Donley To: "Scott G. Kelly" , Ole Troan Date: Thu, 5 Aug 2010 09:00:00 -0600 Thread-Topic: secdir review of draft-ietf-v6ops-ipv6-cpe-router Thread-Index: AcszU2kVv4rZsYgkSqCTSEpWWYATVwBWvfNA Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg> References: <1280871146.382928184@192.168.2.231> In-Reply-To: <1280871146.382928184@192.168.2.231> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7CF5048723srvxchg_" MIME-Version: 1.0 X-Approved: ondar X-Mailman-Approved-At: Mon, 09 Aug 2010 05:52:02 -0700 Cc: "draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org" , "cpe-router@external.cisco.com" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router 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: , X-List-Received-Date: Thu, 05 Aug 2010 15:09:06 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7CF5048723srvxchg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2NvdHQsDQoNCklmIHdlIHdlcmUgdG8gbWFrZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMgdG8gdGhl IHNlY3VyaXR5IHNlY3Rpb24sIHdvdWxkIHRoZXkgYWRkcmVzcyB5b3VyIGNvbmNlcm5zPw0KDQpJ dCBpcyBjb25zaWRlcmVkIGEgYmVzdCBwcmFjdGljZSB0byBmaWx0ZXIgb2J2aW91c2x5IG1hbGlj aW91cw0KICAgdHJhZmZpYyAoZS5nLiBzcG9vZmVkIHBhY2tldHMsICJtYXJ0aWFuIiBhZGRyZXNz ZXMsIGV0Yy4pLiAgVGh1cywgdGhlDQogICBJUHY2IENFIHJvdXRlciBzaG91bGQgb3VnaHQgdG8g c3VwcG9ydCBiYXNpYyBzdGF0ZWxlc3MgZWdyZXNzIGFuZCBpbmdyZXNzDQogICBmaWx0ZXJzLiAg VGhlIENFIHJvdXRlciBzaG91bGQgaXMgYWxzbyBleHBlY3RlZCB0byBvZmZlciBtZWNoYW5pc21z IHRvIGZpbHRlcg0KICAgdHJhZmZpYyBlbnRlcmluZyB0aGUgY3VzdG9tZXIgbmV0d29yazsgaG93 ZXZlciwgdGhlIG1ldGhvZCBieSB3aGljaA0KICAgdmVuZG9ycyBpbXBsZW1lbnQgY29uZmlndXJh YmxlIHBhY2tldCBmaWx0ZXJpbmcgaXMgYmV5b25kIHRoZSBzY29wZQ0KICAgb2YgdGhpcyBkb2N1 bWVudC4NCg0KICAgU2VjdXJpdHkgcmVxdWlyZW1lbnRzOg0KDQogICBTLTE6ICBUaGUgSVB2NiBD RSByb3V0ZXIgU0hPVUxEIHN1cHBvcnQNCiAgICAgICAgIFtJLUQuaWV0Zi12Nm9wcy1jcGUtc2lt cGxlLXNlY3VyaXR5XS4gSW4gcGFydGljdWxhciwgdGhlIElQdjYgQ0Ugcm91dGVyIFNIT1VMRCBz dXBwb3J0IGZ1bmN0aW9uYWxpdHkgc3VmZmljaWVudCBmb3IgaW1wbGVtZW50aW5nIHRoZSBzZXQg b2YgcmVjb21tZW5kYXRpb25zIGluIFtJLUQuaWV0Zi12Nm9wcy1jcGUtc2ltcGxlLXNlY3VyaXR5 XSBTZWN0aW9uIDQuICBUaGlzIGRvY3VtZW50IHRha2VzIG5vIHBvc2l0aW9uIG9uIHdoZXRoZXIg c3VjaCBmdW5jdGlvbmFsaXR5IGlzIGVuYWJsZWQgYnkgZGVmYXVsdCBvciBtZWNoYW5pc21zIGJ5 IHdoaWNoIHVzZXJzIHdvdWxkIGNvbmZpZ3VyZSBpdC4NCg0KICAgUy0yOiAgVGhlIElQdjYgQ0Ug cm91dGVyIE1VU1Qgc3VwcG9ydCBpbmdyZXNzIGZpbHRlcmluZyBpbiBhY2NvcmRhbmNlDQogICAg ICAgICB3aXRoIFtSRkMyODI3XSAoQkNQIDM4KQ0KDQoNCkFsc28sIHNpbmNlIHdlJ3JlIHNvIGxh dGUgaW4gdGhlIHByb2Nlc3MsIG15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gc3BlY2lmeSBkZXZp Y2Ugc2VjdXJpdHkgYXMgcGFydCBvZiBvdXIgUGhhc2UgMiBkcmFmdCAoc2NoZWR1bGVkIHRvIHN0 YXJ0IHdvcmsgb24gOC8xMykuICBXb3VsZCB5b3UgaGF2ZSBhbnkgaXNzdWUgd2l0aCB0aGF0Pw0K DQpDaHJpcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2NvdHQgRy4gS2Vs bHkgW21haWx0bzpzY290dEBoeXBlcnRob3VnaHQuY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0 IDAzLCAyMDEwIDM6MzIgUE0NClRvOiBPbGUgVHJvYW4NCkNjOiBzZWNkaXJAaWV0Zi5vcmc7IGll c2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1jcGUtcm91dGVyLmFsbEB0b29scy5p ZXRmLm9yZzsgY3BlLXJvdXRlckBleHRlcm5hbC5jaXNjby5jb20NClN1YmplY3Q6IFJlOiBzZWNk aXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1jcGUtcm91dGVyDQoNCkhpIE9sZSwN Cg0KT24gTW9uZGF5LCBBdWd1c3QgMiwgMjAxMCA1OjU4YW0sICJPbGUgVHJvYW4iIDxvdEBjaXNj by5jb20+IHNhaWQ6DQoNCjx0cmltbWVkLi4uPg0KPg0KPj4gVGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNlY3Rpb24gYmVnaW5zIHdpdGggYSBwYXJhZ3JhcGggc3RhdGluZyB0aGF0IGJhc2lj DQo+PiBzdGF0ZWxlc3MgZWdyZXNzIGFuZCBpbmdyZXNzIGZpbHRlcnMgc2hvdWxkIGJlIHN1cHBv cnRlZCAobG93ZXJjYXNlICJzaG91bGQiKSwNCj4+IGFuZCBnb2VzIG9uIHRvIHNheSB0aGF0IHRo ZSBDRSByb3V0ZXIgc2hvdWxkIG9mZmVyIG1lY2hhbmlzbXMgdG8gZmlsdGVyIHRyYWZmaWMNCj4+ IGVudGVyaW5nIHRoZSBjdXN0b21lciBuZXR3b3JrLCBidXQgdGhhdCBob3cgdGhlc2UgYXJlIGlt cGxlbWVudGVkIGlzIG91dCBvZiBzY29wZQ0KPj4gKGxvd2VyY2FzZSAic2hvdWxkIikuDQo+DQo+ IHdlIHRyaWVkIHRvIGxpbWl0IFJGQzIxMTkgbGFuZ3VhZ2UgdG8gb25seSB0aGUgbnVtYmVyZWQg cmVxdWlyZW1lbnRzLiB0aGUgaW5pdGlhbA0KPiBwYXJhZ3JhcGggaXMgb25seSB0byBzZXQgdGhl IHN0YWdlIGZvciB0aGUgbW9yZSBkZXRhaWxlZCByZXF1aXJlbWVudHMgYmVsb3cuDQo+IGJhc2lj YWxseSBqdXN0IHNheWluZyB0aGF0IHRoZSBDUEUgc2hvdWxkIHN1cHBvcnQgYSBwYWNrZXQgZmls dGVyaW5nIGNhcGFiaWxpdHkuDQo+IGJ1dCBmcm9tIGEgc2VjdXJpdHkgcG9pbnQgb2YgdmlldyBJ J20gbm90IHN1cmUgaWYgd2UgY2FuIHN0YXRlIHRoaXMgaW4gdmVyeSBtdWNoDQo+IG1vcmUgY29u Y3JldGUgdGVybXM/DQoNCk9rYXksIEkgZ3Vlc3MgaXQgbWFrZXMgbW9yZSBzZW5zZSB3aGVuIHZp ZXdlZCBhcyBpbnRyb2R1Y3RvcnkgdGV4dCBmb3IgdGhlIG51bWJlcmVkIHJlcXVpcmVtZW50cy4N Cg0KPj4gVGhlbiwgaXQgaGFzIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50czoNCj4+DQo+PiAgIFNl Y3VyaXR5IHJlcXVpcmVtZW50czoNCj4+DQo+PiAgIFMtMTogIFRoZSBJUHY2IENFIHJvdXRlciBT SE9VTEQgc3VwcG9ydA0KPj4gICAgICAgICBbSS1ELmlldGYtdjZvcHMtY3BlLXNpbXBsZS1zZWN1 cml0eV0uDQo+Pg0KPj4gICBTLTI6ICBUaGUgSVB2NiBDRSByb3V0ZXIgTVVTVCBzdXBwb3J0IGlu Z3Jlc3MgZmlsdGVyaW5nIGluIGFjY29yZGFuY2UNCj4+ICAgICAgICAgd2l0aCBbUkZDMjgyN10g KEJDUCAzOCkNCj4+DQo+PiBXaGVuIEkgZmlyc3QgcmVhZCB0aGlzLCBJIHRob3VnaHQgdGhlIHN0 YXRlbWVudHMgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCB3ZXJlDQo+PiBzb21ld2hhdCB3ZWFrIGFu ZCBpbXByZWNpc2UsIGFzIHRoZXkgZG9uJ3QgdXNlIFJGQzIxMTkgbGFuZ3VhZ2UuIFdoZW4gSSBy ZWFkDQo+PiBkcmFmdC1pZXRmLXY2b3BzLWNwZS1zaW1wbGUtc2VjdXJpdHktMTIudHh0LCBJIHRo b3VnaHQgdGhhdCBkb2N1bWVudCBnaXZlcyBhDQo+PiByZWxhdGl2ZWx5IHRob3JvdWdoIHRyZWF0 bWVudCBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgYnV0IEknbSBub3Qgc3VyZSB3aGF0DQo+ PiBpdCBtZWFucyB0byBzYXkgIlRoZSBJUHY2IENFIHJvdXRlciBTSE9VTEQgc3VwcG9ydCIgaXQu DQo+DQo+IHRoZSBpbnRlbnRpb24gd2FzIHRvIHN0YXRlIHRoZSB0aGUgQ1BFIHJvdXRlciBzaG91 bGQgaGF2ZSB0aGUgY2FwYWJpbGl0eSBvZiBkb2luZw0KPiB0aGUgZnVuY3Rpb25zIGRlc2NyaWJl ZCBpbiB0aGUgc2ltcGxlIHNlY3VyaXR5IGRyYWZ0LiBidXQgd2UgZGlkIG5vdCB3YW50IHRvIG1h a2UNCj4gYW55IHJlY29tbWVuZGF0aW9uIHdoYXQgdGhlIGRlZmF1bHQgc2hvdWxkIGJlLiBJIGJl bGlldmUgcmVjb21tZW5kaW5nIHRoYXQgc2ltcGxlDQo+IHNlY3VyaXR5IGlzIGVuYWJsZWQgYnkg ZGVmYXVsdCBpbiBhIENQRSByb3V0ZXJzIHdvdWxkIHZpb2xhdGUgdGhlIEludGVybmV0DQo+IGFy Y2hpdGVjdHVyZSBwcmluY2lwbGVzLiB3b3VsZCBpdCBoZWxwIGlmIHdlIGNoYW5nZWQgdGhlIHRl eHQgdG86DQo+DQo+IFMtMTogVGhlIElQdjYgQ0Ugcm91dGVyIFNIT1VMRCBzdXBwb3J0IHRoZSBb SS1ELmlldGYtdjZvcHMtY3BlLXNpbXBsZS1zZWN1cml0eV0uDQo+IFRoaXMgZnVuY3Rpb25hbGl0 eSBNVVNUIGJlIHVzZXIgY29uZmlndXJhYmxlIGFuZCB0aGlzDQo+ICAgICAgICAgc3BlY2lmaWNh dGlvbiBtYWtlcyBubyByZWNvbW1lbmRhdGlvbiB3aGF0IHRoZSBkZWZhdWx0IHNldHRpbmcgc2hv dWxkIGJlLg0KDQpTaW5jZSB0aGUgcmVmZXJlbmNlZCBkcmFmdCBpcyBpbmZvcm1hdGlvbmFsIGFu ZCBkb2VzIG5vdCBtYW5kYXRlIGFueSBiZWhhdmlvciAoaXQgb25seSBtYWtlcyBub24tYmluZGlu ZyByZWNvbW1lbmRhdGlvbnMpLCBJJ20gc3RpbGwgY29uZnVzZWQgYWJvdXQgd2hhdCBpdCBtZWFu cyB0byAic3VwcG9ydCIgaXQgLSBpdCBzZWVtcyB2ZXJ5IGRpZmZpY3VsdCB0byBwaW4gZG93bi4g RG8geW91IG1lYW4gdGhhdCB0aGVzZSBkZXZpY2VzIE1VU1QgcHJvdmlkZSBrbm9icyBmb3IgYWxs IGNhcGFiaWxpdGllcyBkZWZpbmVkIHRoZXJlLCBvciBqdXN0IHNvbWUgb2YgdGhlbSAoYW5kIGlm IHNvLCB3aGljaCBvbmVzKT8NCg0KU2luY2UgYm90aCBvZiB0aGVzZSBkb2N1bWVudHMgYXJlIGlu Zm9ybWF0aW9uYWwsIHBlcmhhcHMgaXQgZG9lc24ndCBtYXR0ZXIsIGJ1dCBpdCBzZWVtcyBsaWtl IHdlJ2QgYmUgZG9pbmcgdGhlIHVzZXIgY29tbXVuaXR5IGEgYmV0dGVyIHNlcnZpY2UgaWYgd2Ug dG9vayBhIGRlZmluaXRlIHBvc2l0aW9uIG9uIGJhc2VsaW5lIHNlY3VyaXR5IHJlcXVpcmVtZW50 cyBmb3IgdGhlc2UgZGV2aWNlcy4NCg0KPG1vcmUgdHJpbW1lZC4uLj4NCj4gd2hpbGUgb24gdGhl IHRvcGljIG9mIHNlY3VyaXR5LiB3ZSBzaG91bGQgcGVyaGFwcyBoYXZlIHNhaWQgc29tZXRoaW5n IG1vcmUgYWJvdXQNCj4gZGV2aWNlIHNlY3VyaXR5LiBhcyBpbiByZXF1aXJlbWVudHMgZm9yIGFj Y2VzcyB0byB0aGUgZGV2aWNlIGl0c2VsZi4gdG9kYXkgbWFueSBvZg0KPiB0aGVzZSByb3V0ZXJz IGFsbG93IHRlbG5ldCBhbmQgaHR0cCBhY2Nlc3MsIG1vcmUgb2Z0ZW4gdGhhbiBub3Qgd2l0aCBk ZWZhdWx0DQo+IHBhc3N3b3JkLiB3aGVyZSB0aGV5IGFsc28gbWFrZSBhIGRpc3RpbmN0aW9uIGJl dHdlZW4gJ2luc2lkZScgYW5kICdvdXRzaWRlJywgd2hpY2gNCj4gc29tZSByZWNlbnQgYXR0YWNr cyBoYXZlIHRha2VuIGFkdmFudGFnZSBvZi4NCg0KVGhlIHNpbXBsZSBzZWN1cml0eSBkb2N1bWVu dCBkb2VzIHJlZmVyZW5jZSBtYW5hZ2VtZW50IGFwcGxpY2F0aW9ucyAoc2VjdGlvbiAzLjUpLCBi dXQgb25seSBzdGF0ZXMgdGhhdCB0aGV5IHNob3VsZCBub3QgYmUgYWNjZXNzaWJsZSBvbiB0aGUg V0FOIGludGVyZmFjZSBieSBkZWZhdWx0LiBJdCBtaWdodCBiZSB3b3J0aHdoaWxlIHRvIHVwZGF0 ZSBpdCBhY2NvcmRpbmcgdG8geW91ciB0aG91Z2h0cyBhYm92ZS4NCg0KLS1TY290dA0KDQoNCg0K --_000_76AC5FEF83F1E64491446437EA81A61F7CF5048723srvxchg_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDb25zb2xhcywgbW9ub3NwYWNlIiBzaXplPSIy Ij4NCjxkaXY+U2NvdHQsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JZiB3ZSB3ZXJl IHRvIG1ha2UgdGhlIGZvbGxvd2luZyBjaGFuZ2VzIHRvIHRoZSBzZWN1cml0eSBzZWN0aW9uLCB3 b3VsZCB0aGV5IGFkZHJlc3MgeW91ciBjb25jZXJucz88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHNpemU9IjIiPkl0IGlzIGNv bnNpZGVyZWQgYSBiZXN0IHByYWN0aWNlIHRvIGZpbHRlciBvYnZpb3VzbHkgbWFsaWNpb3VzPC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzaXplPSIy Ij4mbmJzcDsmbmJzcDsgdHJhZmZpYyAoZS5nLiBzcG9vZmVkIHBhY2tldHMsICZxdW90O21hcnRp YW4mcXVvdDsgYWRkcmVzc2VzLCBldGMuKS4mbmJzcDsgVGh1cywgdGhlPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzaXplPSIyIj4mbmJzcDsmbmJz cDsgSVB2NiBDRSByb3V0ZXIgPHN0cmlrZT5zaG91bGQ8L3N0cmlrZT4gPGZvbnQgY29sb3I9IiNG RjAwMDAiPm91Z2h0IHRvIDwvZm9udD5zdXBwb3J0IGJhc2ljIHN0YXRlbGVzcyBlZ3Jlc3MgYW5k IGluZ3Jlc3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2Vy aWYiIHNpemU9IjIiPiZuYnNwOyZuYnNwOyBmaWx0ZXJzLiZuYnNwOyBUaGUgQ0Ugcm91dGVyIDxz dHJpa2U+c2hvdWxkPC9zdHJpa2U+IDxmb250IGNvbG9yPSIjRkYwMDAwIj5pczwvZm9udD4gYWxz byA8Zm9udCBjb2xvcj0iI0ZGMDAwMCI+ZXhwZWN0ZWQgdG88L2ZvbnQ+IG9mZmVyIG1lY2hhbmlz bXMgdG8gZmlsdGVyPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5z LXNlcmlmIiBzaXplPSIyIj4mbmJzcDsmbmJzcDsgdHJhZmZpYyBlbnRlcmluZyB0aGUgY3VzdG9t ZXIgbmV0d29yazsgaG93ZXZlciwgdGhlIG1ldGhvZCBieSB3aGljaDwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+Jm5ic3A7Jm5ic3A7 IHZlbmRvcnMgaW1wbGVtZW50IGNvbmZpZ3VyYWJsZSBwYWNrZXQgZmlsdGVyaW5nIGlzIGJleW9u ZCB0aGUgc2NvcGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMt c2VyaWYiIHNpemU9IjIiPiZuYnNwOyZuYnNwOyBvZiB0aGlzIGRvY3VtZW50LjwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+Jm5ic3A7 PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzaXpl PSIyIj4mbmJzcDsmbmJzcDsgU2VjdXJpdHkgcmVxdWlyZW1lbnRzOjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+Jm5ic3A7PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzaXplPSIyIj4m bmJzcDsmbmJzcDsgUy0xOiZuYnNwOyBUaGUgSVB2NiBDRSByb3V0ZXIgU0hPVUxEIHN1cHBvcnQ8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHNpemU9 IjIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbSS1E LmlldGYtdjZvcHMtY3BlLXNpbXBsZS1zZWN1cml0eV0uIDxmb250IGNvbG9yPSIjRkYwMDAwIj5J biBwYXJ0aWN1bGFyLCB0aGUgSVB2NiBDRSByb3V0ZXIgU0hPVUxEIHN1cHBvcnQgZnVuY3Rpb25h bGl0eSBzdWZmaWNpZW50IGZvciBpbXBsZW1lbnRpbmcgdGhlIHNldCBvZiByZWNvbW1lbmRhdGlv bnMgaW4gW0ktRC5pZXRmLXY2b3BzLWNwZS1zaW1wbGUtc2VjdXJpdHldDQpTZWN0aW9uIDQuJm5i c3A7IFRoaXMgZG9jdW1lbnQgdGFrZXMgbm8gcG9zaXRpb24gb24gd2hldGhlciBzdWNoIGZ1bmN0 aW9uYWxpdHkgaXMgZW5hYmxlZCBieSBkZWZhdWx0IG9yIG1lY2hhbmlzbXMgYnkgd2hpY2ggdXNl cnMgd291bGQgY29uZmlndXJlIGl0LjwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHNpemU9IjIiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+Jm5ic3A7Jm5ic3A7 IFMtMjombmJzcDsgVGhlIElQdjYgQ0Ugcm91dGVyIE1VU1Qgc3VwcG9ydCBpbmdyZXNzIGZpbHRl cmluZyBpbiBhY2NvcmRhbmNlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp LCBzYW5zLXNlcmlmIiBzaXplPSIyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgd2l0aCBbUkZDMjgyN10gKEJDUCAzOCk8L2ZvbnQ+PC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QWxzbywgc2luY2Ugd2UncmUg c28gbGF0ZSBpbiB0aGUgcHJvY2VzcywgbXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBzcGVjaWZ5 IGRldmljZSBzZWN1cml0eSBhcyBwYXJ0IG9mIG91ciBQaGFzZSAyIGRyYWZ0IChzY2hlZHVsZWQg dG8gc3RhcnQgd29yayBvbiA4LzEzKS4mbmJzcDsgV291bGQgeW91IGhhdmUgYW55IGlzc3VlIHdp dGggdGhhdD88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkNocmlzPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCg0KRnJv bTogU2NvdHQgRy4gS2VsbHkgWzxhIGhyZWY9Im1haWx0bzpzY290dEBoeXBlcnRob3VnaHQuY29t Ij5tYWlsdG86c2NvdHRAaHlwZXJ0aG91Z2h0LmNvbTwvYT5dDQo8YnI+DQoNClNlbnQ6IFR1ZXNk YXksIEF1Z3VzdCAwMywgMjAxMCAzOjMyIFBNPGJyPg0KDQpUbzogT2xlIFRyb2FuPGJyPg0KDQpD Yzogc2VjZGlyQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBkcmFmdC1pZXRmLXY2b3BzLWlwdjYt Y3BlLXJvdXRlci5hbGxAdG9vbHMuaWV0Zi5vcmc7IGNwZS1yb3V0ZXJAZXh0ZXJuYWwuY2lzY28u Y29tPGJyPg0KDQpTdWJqZWN0OiBSZTogc2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXY2b3Bz LWlwdjYtY3BlLXJvdXRlcjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SGkgT2xlLDwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+T24gTW9uZGF5LCBBdWd1c3QgMiwgMjAxMCA1 OjU4YW0sICZxdW90O09sZSBUcm9hbiZxdW90OyAmbHQ7b3RAY2lzY28uY29tJmd0OyBzYWlkOjwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmx0O3RyaW1tZWQuLi4mZ3Q7PC9kaXY+DQo8 ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IHNlY3Rpb24gYmVnaW5zIHdpdGggYSBwYXJhZ3JhcGggc3RhdGluZyB0aGF0IGJhc2ljPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7IHN0YXRlbGVzcyBlZ3Jlc3MgYW5kIGluZ3Jlc3MgZmlsdGVycyBzaG91 bGQgYmUgc3VwcG9ydGVkIChsb3dlcmNhc2UgJnF1b3Q7c2hvdWxkJnF1b3Q7KSw8L2Rpdj4NCjxk aXY+Jmd0OyZndDsgYW5kIGdvZXMgb24gdG8gc2F5IHRoYXQgdGhlIENFIHJvdXRlciBzaG91bGQg b2ZmZXIgbWVjaGFuaXNtcyB0byBmaWx0ZXIgdHJhZmZpYzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBl bnRlcmluZyB0aGUgY3VzdG9tZXIgbmV0d29yaywgYnV0IHRoYXQgaG93IHRoZXNlIGFyZSBpbXBs ZW1lbnRlZCBpcyBvdXQgb2Ygc2NvcGU8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgKGxvd2VyY2FzZSAm cXVvdDtzaG91bGQmcXVvdDspLjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IHdl IHRyaWVkIHRvIGxpbWl0IFJGQzIxMTkgbGFuZ3VhZ2UgdG8gb25seSB0aGUgbnVtYmVyZWQgcmVx dWlyZW1lbnRzLiB0aGUgaW5pdGlhbDwvZGl2Pg0KPGRpdj4mZ3Q7IHBhcmFncmFwaCBpcyBvbmx5 IHRvIHNldCB0aGUgc3RhZ2UgZm9yIHRoZSBtb3JlIGRldGFpbGVkIHJlcXVpcmVtZW50cyBiZWxv dy48L2Rpdj4NCjxkaXY+Jmd0OyBiYXNpY2FsbHkganVzdCBzYXlpbmcgdGhhdCB0aGUgQ1BFIHNo b3VsZCBzdXBwb3J0IGEgcGFja2V0IGZpbHRlcmluZyBjYXBhYmlsaXR5LjwvZGl2Pg0KPGRpdj4m Z3Q7IGJ1dCBmcm9tIGEgc2VjdXJpdHkgcG9pbnQgb2YgdmlldyBJJ20gbm90IHN1cmUgaWYgd2Ug Y2FuIHN0YXRlIHRoaXMgaW4gdmVyeSBtdWNoPC9kaXY+DQo8ZGl2PiZndDsgbW9yZSBjb25jcmV0 ZSB0ZXJtcz88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk9rYXksIEkgZ3Vlc3MgaXQg bWFrZXMgbW9yZSBzZW5zZSB3aGVuIHZpZXdlZCBhcyBpbnRyb2R1Y3RvcnkgdGV4dCBmb3IgdGhl IG51bWJlcmVkIHJlcXVpcmVtZW50cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7IFRoZW4sIGl0IGhhcyB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHM6PC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IFNlY3VyaXR5IHJlcXVp cmVtZW50czo8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsm bmJzcDsgUy0xOiZuYnNwOyBUaGUgSVB2NiBDRSByb3V0ZXIgU0hPVUxEIHN1cHBvcnQ8L2Rpdj4N CjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgW0ktRC5pZXRmLXY2b3BzLWNwZS1zaW1wbGUtc2VjdXJpdHldLjwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBTLTI6Jm5ic3A7IFRoZSBJ UHY2IENFIHJvdXRlciBNVVNUIHN1cHBvcnQgaW5ncmVzcyBmaWx0ZXJpbmcgaW4gYWNjb3JkYW5j ZTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB3aXRoIFtSRkMyODI3XSAoQkNQIDM4KTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBXaGVuIEkgZmlyc3QgcmVhZCB0aGlzLCBJIHRob3VnaHQg dGhlIHN0YXRlbWVudHMgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCB3ZXJlPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7IHNvbWV3aGF0IHdlYWsgYW5kIGltcHJlY2lzZSwgYXMgdGhleSBkb24ndCB1c2UgUkZD MjExOSBsYW5ndWFnZS4gV2hlbiBJIHJlYWQ8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgZHJhZnQtaWV0 Zi12Nm9wcy1jcGUtc2ltcGxlLXNlY3VyaXR5LTEyLnR4dCwgSSB0aG91Z2h0IHRoYXQgZG9jdW1l bnQgZ2l2ZXMgYTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyByZWxhdGl2ZWx5IHRob3JvdWdoIHRyZWF0 bWVudCBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgYnV0IEknbSBub3Qgc3VyZSB3aGF0PC9k aXY+DQo8ZGl2PiZndDsmZ3Q7IGl0IG1lYW5zIHRvIHNheSAmcXVvdDtUaGUgSVB2NiBDRSByb3V0 ZXIgU0hPVUxEIHN1cHBvcnQmcXVvdDsgaXQuPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2 PiZndDsgdGhlIGludGVudGlvbiB3YXMgdG8gc3RhdGUgdGhlIHRoZSBDUEUgcm91dGVyIHNob3Vs ZCBoYXZlIHRoZSBjYXBhYmlsaXR5IG9mIGRvaW5nPC9kaXY+DQo8ZGl2PiZndDsgdGhlIGZ1bmN0 aW9ucyBkZXNjcmliZWQgaW4gdGhlIHNpbXBsZSBzZWN1cml0eSBkcmFmdC4gYnV0IHdlIGRpZCBu b3Qgd2FudCB0byBtYWtlPC9kaXY+DQo8ZGl2PiZndDsgYW55IHJlY29tbWVuZGF0aW9uIHdoYXQg dGhlIGRlZmF1bHQgc2hvdWxkIGJlLiBJIGJlbGlldmUgcmVjb21tZW5kaW5nIHRoYXQgc2ltcGxl PC9kaXY+DQo8ZGl2PiZndDsgc2VjdXJpdHkgaXMgZW5hYmxlZCBieSBkZWZhdWx0IGluIGEgQ1BF IHJvdXRlcnMgd291bGQgdmlvbGF0ZSB0aGUgSW50ZXJuZXQ8L2Rpdj4NCjxkaXY+Jmd0OyBhcmNo aXRlY3R1cmUgcHJpbmNpcGxlcy4gd291bGQgaXQgaGVscCBpZiB3ZSBjaGFuZ2VkIHRoZSB0ZXh0 IHRvOjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IFMtMTogVGhlIElQdjYgQ0Ug cm91dGVyIFNIT1VMRCBzdXBwb3J0IHRoZSBbSS1ELmlldGYtdjZvcHMtY3BlLXNpbXBsZS1zZWN1 cml0eV0uPC9kaXY+DQo8ZGl2PiZndDsgVGhpcyBmdW5jdGlvbmFsaXR5IE1VU1QgYmUgdXNlciBj b25maWd1cmFibGUgYW5kIHRoaXM8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpY2F0aW9uIG1ha2VzIG5vIHJlY29t bWVuZGF0aW9uIHdoYXQgdGhlIGRlZmF1bHQgc2V0dGluZyBzaG91bGQgYmUuPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5TaW5jZSB0aGUgcmVmZXJlbmNlZCBkcmFmdCBpcyBpbmZvcm1h dGlvbmFsIGFuZCBkb2VzIG5vdCBtYW5kYXRlIGFueSBiZWhhdmlvciAoaXQgb25seSBtYWtlcyBu b24tYmluZGluZyByZWNvbW1lbmRhdGlvbnMpLCBJJ20gc3RpbGwgY29uZnVzZWQgYWJvdXQgd2hh dCBpdCBtZWFucyB0byAmcXVvdDtzdXBwb3J0JnF1b3Q7IGl0IC0gaXQgc2VlbXMgdmVyeSBkaWZm aWN1bHQgdG8gcGluIGRvd24uIERvIHlvdSBtZWFuIHRoYXQgdGhlc2UgZGV2aWNlcyBNVVNUDQpw cm92aWRlIGtub2JzIGZvciBhbGwgY2FwYWJpbGl0aWVzIGRlZmluZWQgdGhlcmUsIG9yIGp1c3Qg c29tZSBvZiB0aGVtIChhbmQgaWYgc28sIHdoaWNoIG9uZXMpPyA8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PlNpbmNlIGJvdGggb2YgdGhlc2UgZG9jdW1lbnRzIGFyZSBpbmZvcm1hdGlv bmFsLCBwZXJoYXBzIGl0IGRvZXNuJ3QgbWF0dGVyLCBidXQgaXQgc2VlbXMgbGlrZSB3ZSdkIGJl IGRvaW5nIHRoZSB1c2VyIGNvbW11bml0eSBhIGJldHRlciBzZXJ2aWNlIGlmIHdlIHRvb2sgYSBk ZWZpbml0ZSBwb3NpdGlvbiBvbiBiYXNlbGluZSBzZWN1cml0eSByZXF1aXJlbWVudHMgZm9yIHRo ZXNlIGRldmljZXMuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbHQ7bW9yZSB0cmlt bWVkLi4uJmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyB3aGlsZSBvbiB0aGUgdG9waWMgb2Ygc2VjdXJp dHkuIHdlIHNob3VsZCBwZXJoYXBzIGhhdmUgc2FpZCBzb21ldGhpbmcgbW9yZSBhYm91dDwvZGl2 Pg0KPGRpdj4mZ3Q7IGRldmljZSBzZWN1cml0eS4gYXMgaW4gcmVxdWlyZW1lbnRzIGZvciBhY2Nl c3MgdG8gdGhlIGRldmljZSBpdHNlbGYuIHRvZGF5IG1hbnkgb2Y8L2Rpdj4NCjxkaXY+Jmd0OyB0 aGVzZSByb3V0ZXJzIGFsbG93IHRlbG5ldCBhbmQgaHR0cCBhY2Nlc3MsIG1vcmUgb2Z0ZW4gdGhh biBub3Qgd2l0aCBkZWZhdWx0PC9kaXY+DQo8ZGl2PiZndDsgcGFzc3dvcmQuIHdoZXJlIHRoZXkg YWxzbyBtYWtlIGEgZGlzdGluY3Rpb24gYmV0d2VlbiAnaW5zaWRlJyBhbmQgJ291dHNpZGUnLCB3 aGljaDwvZGl2Pg0KPGRpdj4mZ3Q7IHNvbWUgcmVjZW50IGF0dGFja3MgaGF2ZSB0YWtlbiBhZHZh bnRhZ2Ugb2YuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGUgc2ltcGxlIHNlY3Vy aXR5IGRvY3VtZW50IGRvZXMgcmVmZXJlbmNlIG1hbmFnZW1lbnQgYXBwbGljYXRpb25zIChzZWN0 aW9uIDMuNSksIGJ1dCBvbmx5IHN0YXRlcyB0aGF0IHRoZXkgc2hvdWxkIG5vdCBiZSBhY2Nlc3Np YmxlIG9uIHRoZSBXQU4gaW50ZXJmYWNlIGJ5IGRlZmF1bHQuIEl0IG1pZ2h0IGJlIHdvcnRod2hp bGUgdG8gdXBkYXRlIGl0IGFjY29yZGluZyB0byB5b3VyIHRob3VnaHRzIGFib3ZlLiA8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tU2NvdHQ8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZm9udD4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_76AC5FEF83F1E64491446437EA81A61F7CF5048723srvxchg_-- From eran@hueniverse.com Sat Aug 7 23:14:49 2010 Return-Path: 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 920BA3A68F5 for ; Sat, 7 Aug 2010 23:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, SARE_RMML_Stock10=0.13, WEIRD_PORT=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 uKG6cXrXGMXN for ; Sat, 7 Aug 2010 23:14:48 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 848213A684B for ; Sat, 7 Aug 2010 23:14:47 -0700 (PDT) Received: (qmail 4393 invoked from network); 8 Aug 2010 06:15:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Aug 2010 06:15:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 7 Aug 2010 23:15:19 -0700 From: Eran Hammer-Lahav To: Kurt Zeilenga , IETF Date: Sat, 7 Aug 2010 23:15:27 -0700 Thread-Topic: SECDIR review: draft-hammer-hostmeta Thread-Index: Acsk8bDUux3bXYWtQ52nlD8uOJnntgRzwNEg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F12411A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <19622F34-F03E-4DE6-AB8F-711B99CCAECE@Isode.com> In-Reply-To: <19622F34-F03E-4DE6-AB8F-711B99CCAECE@Isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Aug 2010 05:52:02 -0700 Cc: "draft-hammer-hostmeta@tools.ietf.org" , IESG IESG , Security Area Directorate Subject: Re: [secdir] SECDIR review: draft-hammer-hostmeta 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: , X-List-Received-Date: Sun, 08 Aug 2010 06:14:49 -0000 Thanks for the review. I will add these points to the security consideration section, but will kee= p it as a host level document, not service level. This well-known document = is appropriate when looking for host metadata, and application choosing to = use it, must consider the implications. By itself, host-meta means very lit= tle. Applications need to "buy-into" the document (and spell out how to use= it) in order for it to have meaning. When doing so, they must consider its= implications. EHL > -----Original Message----- > From: Kurt Zeilenga [mailto:Kurt.Zeilenga@Isode.com] > Sent: Friday, July 16, 2010 7:18 AM > To: IETF > Cc: draft-hammer-hostmeta@tools.ietf.org; Security Area Directorate; IESG > IESG > Subject: SECDIR review: draft-hammer-hostmeta >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > 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 should treat these comments just like any ot= her > last call comments. >=20 > I have a number of security-related concerns with this specification. >=20 > First, I'm concerned by assumptions in the document that each of: > http://example.com > http://example.com:8080 > https://example.com > https://example.com:8443 >=20 > identify resources under the control of same entity. It is fairly commo= n to > there to be multiple http/https services running on a single host, each s= ervice > possibly operated by different entities as delegated by the "host" > administrator. I think it would be better (from a security perspective) = to > have "service"-level metadata, not "host" level meta data. That is, make= no > assumption that the above URIs are under control of the same entity, or > even if so, that it desirable to a single policy/metadata covering multip= le > services. >=20 > And I think it very important to always fetch the meta data from the serv= ice > one is accessing. The document calls for client to fetch > https://example.com/.well-known/host-meta even when > https://example.com:8443 is URI wants policy for. >=20 > Even worse, the document calls for the client to, if the above fetch does= not > produce a "valid" hostmeta document, for the client to fetch > http://example.com/.well-known/host-meta. An attacker could easily cause > https://example.com/.well-known/host-meta to fail to produce a "valid" > hostmeta document, and serve its own hostmeta document in response to > the client's http://example.com/.well-known/host-meta, without > supplanting the https://example.com:8443 service. >=20 > The document fails to discuss such attacks. >=20 > I recommend reworking this document to provide service-level, not host- > level, metadata. In particular, the metadata document should always be > retrieved through the service the client is interested in using, such as = by > fetching "/.well-known/metadata". >=20 > If the authors rather continue pursuing a "host-based" solution, the secu= rity > considerations should include a discussion of the above issues. >=20 > Regards, Kurt From kent@bbn.com Mon Aug 9 13:54:10 2010 Return-Path: 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 DC9BD3A69B8; Mon, 9 Aug 2010 13:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.229 X-Spam-Level: X-Spam-Status: No, score=-101.229 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 w2NStG+BcTK5; Mon, 9 Aug 2010 13:54:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D1D003A6969; Mon, 9 Aug 2010 13:54:09 -0700 (PDT) Received: from dhcp89-089-110.bbn.com ([128.89.89.110]:49206) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OiZMk-000IME-2r; Mon, 09 Aug 2010 16:54:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 9 Aug 2010 16:54:31 -0400 To: Sam Hartman From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-930735219==_ma============" Cc: "Laganier, Julien" , Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] [saag] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? 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: , X-List-Received-Date: Mon, 09 Aug 2010 20:54:11 -0000 --============_-930735219==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 4:14 AM -0400 7/29/10, Sam Hartman wrote: > >>>>> "Stephen" == Stephen Kent writes: > > Stephen> I agree that the primary motivation for CGAs arose in the > Stephen> SeND context, and that privacy is an independent > Stephen> feature. But, the context in which CGAs were intended to > Stephen> provide an ability to establish a binding to an IPv6 > Stephen> address was local. When one moves beyond this local > Stephen> context, and one advocates having more distant nodes > Stephen> challenge a host, this creates privacy questions. > >I think we've been looking at CGAs that have non-local scope for a >while. Section 7.4 of RFC 3972 seems to anticipate CGAs used with other >protocols. It's my understanding that shim6 supports both HBAs and CGAs >for non-local contexts. I also believe the MIP6 context for CGA use is >non-local. I don't know about MIP6, but when I read the second paragraph of section 7.4 in the CGA RFC, I get a different impression. The fact that the paragraph begins with "Finally, a strong cautionary note has to be made about using CGA signatures for purposes other than SEND." suggests to me that the authors anticipated that others might want to use CGAs elsewhere. They provided a list of comments about why CGAs were designed for and well-suited to the SeND context (which is local), and warnings about the limitations that arise if one tries to use CGAs elsewhere. Steve --============_-930735219==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] [secdir] Interest in draft-dong-savi-cga-heade
At 4:14 AM -0400 7/29/10, Sam Hartman wrote:
>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:

    Stephen> I agree that the primary motivation for CGAs arose in the
    Stephen> SeND context, and that privacy is an independent
    Stephen> feature. But, the context in which CGAs were intended to
    Stephen> provide an ability to establish a binding to an IPv6
    Stephen> address was local. When one moves beyond this local
    Stephen> context, and one advocates having more distant nodes
    Stephen> challenge a host, this creates privacy questions.

I think we've been looking at CGAs that have non-local scope for a
while.  Section 7.4 of RFC 3972 seems to anticipate CGAs used with other
protocols.  It's my understanding that shim6 supports both HBAs and CGAs
for non-local contexts.  I also believe the MIP6 context for CGA use is
non-local.

I don't know about MIP6, but when I read the second paragraph of section 7.4 in the CGA RFC, I get a different impression. The fact that the paragraph begins with "Finally, a strong cautionary note has to be made about using CGA signatures for purposes other than SEND." suggests to me that the authors anticipated that others might want to use CGAs elsewhere. They provided a list of comments about why CGAs were designed for and well-suited to the SeND context (which is local), and warnings about the limitations that arise if one tries to use CGAs elsewhere.

Steve
--============_-930735219==_ma============-- From radiaperlman@gmail.com Mon Aug 9 14:57:51 2010 Return-Path: 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 B69603A68D9; Mon, 9 Aug 2010 14:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, GB_I_LETTER=-2] 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 PqUYCNUlzMXX; Mon, 9 Aug 2010 14:57:50 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 752143A67D0; Mon, 9 Aug 2010 14:57:50 -0700 (PDT) Received: by ewy22 with SMTP id 22so4133313ewy.31 for ; Mon, 09 Aug 2010 14:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=iE2rIeJt6l+OzJLW4nxTDPDFvaWMmujYZNowIbuRUJQ=; b=RUX1xMMhsmQnH91HFpZR0ltxudXTYQ4JLdeUi/fSQOOQ7kZXrR49+scjy/kPpZcBmT jHK2l6kDPDh5vtWNPZsAwFPhGgLskOMmB2/l8f8GGIkPJ58YDHQQlwypmaeBcL0AmO2k opey2/75QyjAK70n2IRNy3sKxaDTWt1ZZ8lzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JNAipVEEBpiVIJ+b1UBMgUe5Hc7Bho/i1CkoAvCOfdkHaU4OtZeoKX6HTgLVXnS/HF wVyzUrs5T6Jx4wG1DIt/DcZkDKX/7S8MQkTVx9LrDR0KPBVPpZrICwWnPkOHjJrytLqN 7e7kftKULLSTJh8MUqxddv0YRA2gdCqt3W8lY= MIME-Version: 1.0 Received: by 10.213.13.137 with SMTP id c9mr10206127eba.41.1281391104477; Mon, 09 Aug 2010 14:58:24 -0700 (PDT) Received: by 10.213.21.25 with HTTP; Mon, 9 Aug 2010 14:58:24 -0700 (PDT) Date: Mon, 9 Aug 2010 14:58:24 -0700 Message-ID: From: Radia Perlman To: draft-ietf-isis-genapp@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] secdir review of draft-ietf-isis-genapp 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: , X-List-Received-Date: Mon, 09 Aug 2010 21:57:51 -0000 This document is about using the reliable flooding mechanism of IS-IS to advertise information for applications unrelated to IS-IS in a way that doesn't use up "T" values in the TLV encoding. So, since it's just syntax, there really aren't any security considerations. It would have been nice if the authors explained what "V" "I" "D" and "S" mean in the context of the flags, as in, what word is "V" the first letter of, what word is "I" the first letter of... Unless I missed it in the spec, the authors just give rules like: D bit (0x02): When the GENINFO TLV is leaked from level-2 to level-1, the D bit MUST be set. Otherwise this bit MUST be clear. GENINFO TLVs with the D bit set MUST NOT be leaked from level-1 to level-2. This is to prevent TLV looping. I bit (0x04): When the I bit is set the 4 octet IPv4 address associated with the application immediately follows the Application ID. Radia From radiaperlman@gmail.com Mon Aug 9 16:34:17 2010 Return-Path: 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 B15933A68AF; Mon, 9 Aug 2010 16:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, GB_I_LETTER=-2] 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 tjku5cmlAUuR; Mon, 9 Aug 2010 16:34:16 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 3CB013A68AC; Mon, 9 Aug 2010 16:34:16 -0700 (PDT) Received: by ewy22 with SMTP id 22so4154565ewy.31 for ; Mon, 09 Aug 2010 16:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H2HUnSw/Zj2dM0YLa8n7tCfYnV4323aRd2YGJa6Vr04=; b=skM7A88151H+BD58sh1z5gaIXib+yevsxEDoGEqYTSPHafE8qO+PayL2N5sc6poyFA O16obZdgC8N8bSdzaB91EqFM5W1F7/T70qMa1jsR8xG16E7oCwBLRtqzfAdxjOuD03RA DD+6XhcG/JOWXFNgYo5wBKXusxZuhW0a9t9XI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Jt/XVGO226N5lZoUtEtMCPgY6X6GJkpOSdaetm9VKIHtsOzWCuoXPubafxZglDO5lQ CHT8sfuHnjWyr+7PnRH339Imv6S/yPZasBaPLCUkk5A5/8atSqKvNc4u7QaRzUWqgmQh IXFOFWkNojaJ5zij1/ioGI23ZDQPyTCMZF/Sk= MIME-Version: 1.0 Received: by 10.213.32.141 with SMTP id c13mr3522664ebd.75.1281396890315; Mon, 09 Aug 2010 16:34:50 -0700 (PDT) Received: by 10.213.21.25 with HTTP; Mon, 9 Aug 2010 16:34:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Aug 2010 16:34:50 -0700 Message-ID: From: Radia Perlman To: "Les Ginsberg (ginsberg)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: secdir@ietf.org, draft-ietf-isis-genapp@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-isis-genapp 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: , X-List-Received-Date: Mon, 09 Aug 2010 23:34:17 -0000 Well, I think it would be good to repeat saying "Scope"and "Down" in this document, and try to think of some words that start with "I" and "V" that make some sense in the context of how those flags are used,. Radia On Mon, Aug 9, 2010 at 4:15 PM, Les Ginsberg (ginsberg) wrote: > Radia - > > The use of "D" and "S" is copied from RFCs 4971/5305. The initials were > not further identified there and we used identical text in describing > them. (That's my excuse anyway) > > As a point of information: > > "S" - flooding "Scope" > "D" - Indicates the TLV has been leaked "Down" from Level2 to level1 > > The choice of the letters "I" and "V" was arbitrary. > > =A0 Les > >> -----Original Message----- >> From: Radia Perlman [mailto:radiaperlman@gmail.com] >> Sent: Monday, August 09, 2010 2:58 PM >> To: draft-ietf-isis-genapp@tools.ietf.org; iesg@ietf.org; >> secdir@ietf.org >> Subject: secdir review of draft-ietf-isis-genapp >> >> This document is about using the reliable flooding mechanism of IS-IS >> to advertise information for applications unrelated to IS-IS in a way >> that doesn't use up "T" values in the TLV encoding. >> >> So, since it's just syntax, there really aren't any security >> considerations. >> >> It would have been nice if the authors explained what "V" "I" "D" and >> "S" mean in the context of the flags, as in, what word is "V" the >> first letter of, what word is "I" the first letter of... >> >> Unless I missed it in the spec, the authors just give rules like: >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0D bit (0x02): When the GENINFO TLV is= leaked from >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0level-2 to level-1, the D bit MUST be= set. Otherwise >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this bit MUST be clear. GENINFO TLVs = with the D bit >> set >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MUST NOT be leaked from level-1 to le= vel-2. This is > to >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prevent TLV looping. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I bit (0x04): When the I bit is set t= he 4 octet IPv4 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0address associated with the applicati= on immediately >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0follows the Application ID. >> >> Radia > From acmorton@att.com Tue Aug 10 09:33:54 2010 Return-Path: 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 5A3843A68F3; Tue, 10 Aug 2010 09:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.584 X-Spam-Level: X-Spam-Status: No, score=-105.584 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 5FMXXIZewh4A; Tue, 10 Aug 2010 09:33:48 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 68E9F3A6984; Tue, 10 Aug 2010 09:33:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-3.tower-161.messagelabs.com!1281458060!34279332!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 22588 invoked from network); 10 Aug 2010 16:34:21 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Aug 2010 16:34:21 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7AGXqMO010087; Tue, 10 Aug 2010 12:33:52 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7AGXlZf009989; Tue, 10 Aug 2010 12:33:47 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o7AGYENK031020; Tue, 10 Aug 2010 11:34:15 -0500 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o7AGY87w030909; Tue, 10 Aug 2010 11:34:08 -0500 Message-Id: <201008101634.o7AGY87w030909@klpd017.kcdc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100810163408gw100s4pqhe>; Tue, 10 Aug 2010 16:34:08 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Aug 2010 12:34:25 -0400 To: Shawn Emery , secdir@ietf.org From: Al Morton In-Reply-To: <4C5E4818.5040308@oracle.com> References: <4C5E4818.5040308@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-ippm-twamp-reflect-octets.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Review of draft-ietf-ippm-twamp-reflect-octets-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: , X-List-Received-Date: Tue, 10 Aug 2010 16:33:54 -0000 Thanks, we'll correct this in the next version. Al At 02:00 AM 8/8/2010, Shawn Emery wrote: >...Editorial comments: > >Closing parentheses missing: >(by the Server or >Session-Reflector > >Shawn. >-- From ginsberg@cisco.com Mon Aug 9 16:15:25 2010 Return-Path: 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 310633A6831; Mon, 9 Aug 2010 16:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.339 X-Spam-Level: X-Spam-Status: No, score=-11.339 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, GB_I_LETTER=-2, 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 7RICqa3vFVIP; Mon, 9 Aug 2010 16:15:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8C3843A67B2; Mon, 9 Aug 2010 16:15:17 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABEpYEyrR7Hu/2dsb2JhbACgUXGoD5tfhToEhCaHYw X-IronPort-AV: E=Sophos;i="4.55,345,1278288000"; d="scan'208";a="570996643" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2010 23:15:52 +0000 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.14.3) with ESMTP id o79NFqcW018172; Mon, 9 Aug 2010 23:15:52 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 16:15:52 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Aug 2010 16:15:51 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-isis-genapp Thread-Index: Acs4EcJ8WEGiy6h+QxS6qTqD+UZDIgABR6Vg References: From: "Les Ginsberg (ginsberg)" To: "Radia Perlman" , , , X-OriginalArrivalTime: 09 Aug 2010 23:15:52.0147 (UTC) FILETIME=[CF7A7230:01CB3818] X-Mailman-Approved-At: Wed, 11 Aug 2010 08:03:59 -0700 Subject: Re: [secdir] secdir review of draft-ietf-isis-genapp 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: , X-List-Received-Date: Mon, 09 Aug 2010 23:15:25 -0000 Radia - The use of "D" and "S" is copied from RFCs 4971/5305. The initials were not further identified there and we used identical text in describing them. (That's my excuse anyway) As a point of information: "S" - flooding "Scope" "D" - Indicates the TLV has been leaked "Down" from Level2 to level1 The choice of the letters "I" and "V" was arbitrary. Les > -----Original Message----- > From: Radia Perlman [mailto:radiaperlman@gmail.com] > Sent: Monday, August 09, 2010 2:58 PM > To: draft-ietf-isis-genapp@tools.ietf.org; iesg@ietf.org; > secdir@ietf.org > Subject: secdir review of draft-ietf-isis-genapp >=20 > This document is about using the reliable flooding mechanism of IS-IS > to advertise information for applications unrelated to IS-IS in a way > that doesn't use up "T" values in the TLV encoding. >=20 > So, since it's just syntax, there really aren't any security > considerations. >=20 > It would have been nice if the authors explained what "V" "I" "D" and > "S" mean in the context of the flags, as in, what word is "V" the > first letter of, what word is "I" the first letter of... >=20 > Unless I missed it in the spec, the authors just give rules like: >=20 > D bit (0x02): When the GENINFO TLV is leaked from > level-2 to level-1, the D bit MUST be set. Otherwise > this bit MUST be clear. GENINFO TLVs with the D bit > set > MUST NOT be leaked from level-1 to level-2. This is to > prevent TLV looping. >=20 > I bit (0x04): When the I bit is set the 4 octet IPv4 > address associated with the application immediately > follows the Application ID. >=20 > Radia From ot@cisco.com Wed Aug 11 04:59:37 2010 Return-Path: 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 C6CEA3A68F8; Wed, 11 Aug 2010 04:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.648 X-Spam-Level: X-Spam-Status: No, score=-9.648 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, 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 PDjDn04+U4CQ; Wed, 11 Aug 2010 04:59:36 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2A26A3A6807; Wed, 11 Aug 2010 04:59:36 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG4tYkxAZnwN/2dsb2JhbACgPHGfRJtZgxCCKgSJUA X-IronPort-AV: E=Sophos;i="4.55,352,1278288000"; d="scan'208";a="146384118" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2010 12:00:11 +0000 Received: from [10.0.0.8] (ams3-vpn-dhcp6343.cisco.com [10.61.88.198]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7BC09wL005013; Wed, 11 Aug 2010 12:00:10 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ole Troan X-Priority: 3 (Normal) In-Reply-To: <1281120642.72688236@192.168.2.229> Date: Wed, 11 Aug 2010 13:26:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1280871146.382928184@192.168.2.231> <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg> <1281120642.72688236@192.168.2.229> To: iesg@ietf.org X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Wed, 11 Aug 2010 08:03:59 -0700 Cc: cpe-router@external.cisco.com, Chris Donley , draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router 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: , X-List-Received-Date: Wed, 11 Aug 2010 11:59:37 -0000 Scott et al, I'm not entirely sure what the process here is. do you want to see a new revision of the draft incorporating Scott's = comments as well as the feedback we have received from the DHC WG review = before we proceed to the IESG review? cheers, Ole > Hi Chris, >=20 > I think your suggestions are reasonable. >=20 > --Scott >=20 >=20 > On Thursday, August 5, 2010 8:00am, "Chris Donley" = said: >=20 >> Scott, >>=20 >> If we were to make the following changes to the security section, = would they >> address your concerns? >>=20 >> It is considered a best practice to filter obviously malicious >> traffic (e.g. spoofed packets, "martian" addresses, etc.). Thus, = the >> IPv6 CE router should ought to support basic stateless egress and = ingress >> filters. The CE router should is also expected to offer mechanisms = to filter >> traffic entering the customer network; however, the method by which >> vendors implement configurable packet filtering is beyond the scope >> of this document. >>=20 >> Security requirements: >>=20 >> S-1: The IPv6 CE router SHOULD support >> [I-D.ietf-v6ops-cpe-simple-security]. In particular, the IPv6 = CE router >> SHOULD support functionality sufficient for implementing the set of >> recommendations in [I-D.ietf-v6ops-cpe-simple-security] Section 4. = This >> document takes no position on whether such functionality is enabled = by >> default or mechanisms by which users would configure it. >>=20 >> S-2: The IPv6 CE router MUST support ingress filtering in = accordance >> with [RFC2827] (BCP 38) >>=20 >>=20 >> Also, since we're so late in the process, my preference would be to = specify device >> security as part of our Phase 2 draft (scheduled to start work on = 8/13). Would >> you have any issue with that? >>=20 >> Chris >>=20 >> -----Original Message----- >> From: Scott G. Kelly [mailto:scott@hyperthought.com] >> Sent: Tuesday, August 03, 2010 3:32 PM >> To: Ole Troan >> Cc: secdir@ietf.org; iesg@ietf.org; >> draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org; >> cpe-router@external.cisco.com >> Subject: Re: secdir review of draft-ietf-v6ops-ipv6-cpe-router >>=20 >> Hi Ole, >>=20 >> On Monday, August 2, 2010 5:58am, "Ole Troan" said: >>=20 >> >>>=20 >>>> The security considerations section begins with a paragraph stating = that basic >>>> stateless egress and ingress filters should be supported (lowercase = "should"), >>>> and goes on to say that the CE router should offer mechanisms to = filter traffic >>>> entering the customer network, but that how these are implemented = is out of >>>> scope >>>> (lowercase "should"). >>>=20 >>> we tried to limit RFC2119 language to only the numbered = requirements. the >>> initial >>> paragraph is only to set the stage for the more detailed = requirements below. >>> basically just saying that the CPE should support a packet filtering = capability. >>> but from a security point of view I'm not sure if we can state this = in very much >>> more concrete terms? >>=20 >> Okay, I guess it makes more sense when viewed as introductory text = for the >> numbered requirements. >>=20 >>>> Then, it has the following statements: >>>>=20 >>>> Security requirements: >>>>=20 >>>> S-1: The IPv6 CE router SHOULD support >>>> [I-D.ietf-v6ops-cpe-simple-security]. >>>>=20 >>>> S-2: The IPv6 CE router MUST support ingress filtering in = accordance >>>> with [RFC2827] (BCP 38) >>>>=20 >>>> When I first read this, I thought the statements in the first = paragraph were >>>> somewhat weak and imprecise, as they don't use RFC2119 language. = When I read >>>> draft-ietf-v6ops-cpe-simple-security-12.txt, I thought that = document gives a >>>> relatively thorough treatment of security considerations, but I'm = not sure what >>>> it means to say "The IPv6 CE router SHOULD support" it. >>>=20 >>> the intention was to state the the CPE router should have the = capability of >>> doing >>> the functions described in the simple security draft. but we did not = want to >>> make >>> any recommendation what the default should be. I believe = recommending that >>> simple >>> security is enabled by default in a CPE routers would violate the = Internet >>> architecture principles. would it help if we changed the text to: >>>=20 >>> S-1: The IPv6 CE router SHOULD support the = [I-D.ietf-v6ops-cpe-simple-security]. >>> This functionality MUST be user configurable and this >>> specification makes no recommendation what the default = setting should >>> be. >>=20 >> Since the referenced draft is informational and does not mandate any = behavior (it >> only makes non-binding recommendations), I'm still confused about = what it means to >> "support" it - it seems very difficult to pin down. Do you mean that = these devices >> MUST provide knobs for all capabilities defined there, or just some = of them (and >> if so, which ones)? >>=20 >> Since both of these documents are informational, perhaps it doesn't = matter, but it >> seems like we'd be doing the user community a better service if we = took a definite >> position on baseline security requirements for these devices. >>=20 >> >>> while on the topic of security. we should perhaps have said = something more about >>> device security. as in requirements for access to the device itself. = today many >>> of >>> these routers allow telnet and http access, more often than not with = default >>> password. where they also make a distinction between 'inside' and = 'outside', >>> which >>> some recent attacks have taken advantage of. >>=20 >> The simple security document does reference management applications = (section 3.5), >> but only states that they should not be accessible on the WAN = interface by >> default. It might be worthwhile to update it according to your = thoughts above. >>=20 >> --Scott >>=20 >>=20 >>=20 >>=20 >=20 >=20 From fred@cisco.com Wed Aug 11 08:32:07 2010 Return-Path: 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 3C1023A693D; Wed, 11 Aug 2010 08:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.063 X-Spam-Level: X-Spam-Status: No, score=-110.063 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 YpK3g-WvrifO; Wed, 11 Aug 2010 08:32:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8BCAA3A687A; Wed, 11 Aug 2010 08:32:05 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,353,1278288000"; d="scan'208";a="571925336" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2010 15:32:41 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o7BFWYS5027333; Wed, 11 Aug 2010 15:32:36 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 11 Aug 2010 08:32:41 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 11 Aug 2010 08:32:41 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 11 Aug 2010 08:32:28 -0700 Message-Id: <00A6D384-5CD8-4E7A-A342-C19CA8C640FA@cisco.com> References: <1280871146.382928184@192.168.2.231> <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg> <1281120642.72688236@192.168.2.229> To: Ole Troan , Ron Bonica X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Chris Donley , secdir@ietf.org, draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org, cpe-router@external.cisco.com, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router 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: , X-List-Received-Date: Wed, 11 Aug 2010 15:32:07 -0000 Note from the document shepherd... The process is that the IESG expects an updated draft in response to = comments. However, they usually consider the draft for a while and then = TELL you that they want it. It is on the telechat for approval Thursday, = and per = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/ has = no "discuss" ballots and "enough positions to pass", which appears to be = two "no objection" ballots. Tell me: what is required to address Scott's comments? Is this a big = change or a small one? If it is a small enough change, I would suggest = that you address it, address Stewart's comment ("expand acronym MLD on = first usage"), and pick up three idnits points that have crept in since = the draft was last posted: Checking references for intended status: Informational = --------------------------------------------------------------------------= -- =3D=3D Outdated reference: draft-ietf-6man-ipv6-subnet-model has been = published as RFC 5942 =3D=3D Outdated reference: A later version (-05) exists of draft-ietf-6man-node-req-bis-04 =3D=3D Outdated reference: A later version (-12) exists of draft-ietf-v6ops-cpe-simple-security-11 And then post it and send a URL to the diffs to the IESG so they can see = what you did. That would allow them to send it on tomorrow. If doing = that in the next few hours isn't reasonable, then wait for the IESG = remarks, which I would expect will sound a lot like what I just said but = with a different date. Ron, your thoughts? On Aug 11, 2010, at 4:26 AM, Ole Troan wrote: > Scott et al, >=20 > I'm not entirely sure what the process here is. > do you want to see a new revision of the draft incorporating Scott's = comments as well as the feedback we have received from the DHC WG review = before we proceed to the IESG review? >=20 > cheers, > Ole >=20 >=20 >> Hi Chris, >>=20 >> I think your suggestions are reasonable. >>=20 >> --Scott >>=20 >>=20 >> On Thursday, August 5, 2010 8:00am, "Chris Donley" = said: >>=20 >>> Scott, >>>=20 >>> If we were to make the following changes to the security section, = would they >>> address your concerns? >>>=20 >>> It is considered a best practice to filter obviously malicious >>> traffic (e.g. spoofed packets, "martian" addresses, etc.). Thus, = the >>> IPv6 CE router should ought to support basic stateless egress and = ingress >>> filters. The CE router should is also expected to offer mechanisms = to filter >>> traffic entering the customer network; however, the method by which >>> vendors implement configurable packet filtering is beyond the scope >>> of this document. >>>=20 >>> Security requirements: >>>=20 >>> S-1: The IPv6 CE router SHOULD support >>> [I-D.ietf-v6ops-cpe-simple-security]. In particular, the IPv6 = CE router >>> SHOULD support functionality sufficient for implementing the set of >>> recommendations in [I-D.ietf-v6ops-cpe-simple-security] Section 4. = This >>> document takes no position on whether such functionality is enabled = by >>> default or mechanisms by which users would configure it. >>>=20 >>> S-2: The IPv6 CE router MUST support ingress filtering in = accordance >>> with [RFC2827] (BCP 38) >>>=20 >>>=20 >>> Also, since we're so late in the process, my preference would be to = specify device >>> security as part of our Phase 2 draft (scheduled to start work on = 8/13). Would >>> you have any issue with that? >>>=20 >>> Chris >>>=20 >>> -----Original Message----- >>> From: Scott G. Kelly [mailto:scott@hyperthought.com] >>> Sent: Tuesday, August 03, 2010 3:32 PM >>> To: Ole Troan >>> Cc: secdir@ietf.org; iesg@ietf.org; >>> draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org; >>> cpe-router@external.cisco.com >>> Subject: Re: secdir review of draft-ietf-v6ops-ipv6-cpe-router >>>=20 >>> Hi Ole, >>>=20 >>> On Monday, August 2, 2010 5:58am, "Ole Troan" said: >>>=20 >>> >>>>=20 >>>>> The security considerations section begins with a paragraph = stating that basic >>>>> stateless egress and ingress filters should be supported = (lowercase "should"), >>>>> and goes on to say that the CE router should offer mechanisms to = filter traffic >>>>> entering the customer network, but that how these are implemented = is out of >>>>> scope >>>>> (lowercase "should"). >>>>=20 >>>> we tried to limit RFC2119 language to only the numbered = requirements. the >>>> initial >>>> paragraph is only to set the stage for the more detailed = requirements below. >>>> basically just saying that the CPE should support a packet = filtering capability. >>>> but from a security point of view I'm not sure if we can state this = in very much >>>> more concrete terms? >>>=20 >>> Okay, I guess it makes more sense when viewed as introductory text = for the >>> numbered requirements. >>>=20 >>>>> Then, it has the following statements: >>>>>=20 >>>>> Security requirements: >>>>>=20 >>>>> S-1: The IPv6 CE router SHOULD support >>>>> [I-D.ietf-v6ops-cpe-simple-security]. >>>>>=20 >>>>> S-2: The IPv6 CE router MUST support ingress filtering in = accordance >>>>> with [RFC2827] (BCP 38) >>>>>=20 >>>>> When I first read this, I thought the statements in the first = paragraph were >>>>> somewhat weak and imprecise, as they don't use RFC2119 language. = When I read >>>>> draft-ietf-v6ops-cpe-simple-security-12.txt, I thought that = document gives a >>>>> relatively thorough treatment of security considerations, but I'm = not sure what >>>>> it means to say "The IPv6 CE router SHOULD support" it. >>>>=20 >>>> the intention was to state the the CPE router should have the = capability of >>>> doing >>>> the functions described in the simple security draft. but we did = not want to >>>> make >>>> any recommendation what the default should be. I believe = recommending that >>>> simple >>>> security is enabled by default in a CPE routers would violate the = Internet >>>> architecture principles. would it help if we changed the text to: >>>>=20 >>>> S-1: The IPv6 CE router SHOULD support the = [I-D.ietf-v6ops-cpe-simple-security]. >>>> This functionality MUST be user configurable and this >>>> specification makes no recommendation what the default = setting should >>>> be. >>>=20 >>> Since the referenced draft is informational and does not mandate any = behavior (it >>> only makes non-binding recommendations), I'm still confused about = what it means to >>> "support" it - it seems very difficult to pin down. Do you mean that = these devices >>> MUST provide knobs for all capabilities defined there, or just some = of them (and >>> if so, which ones)? >>>=20 >>> Since both of these documents are informational, perhaps it doesn't = matter, but it >>> seems like we'd be doing the user community a better service if we = took a definite >>> position on baseline security requirements for these devices. >>>=20 >>> >>>> while on the topic of security. we should perhaps have said = something more about >>>> device security. as in requirements for access to the device = itself. today many >>>> of >>>> these routers allow telnet and http access, more often than not = with default >>>> password. where they also make a distinction between 'inside' and = 'outside', >>>> which >>>> some recent attacks have taken advantage of. >>>=20 >>> The simple security document does reference management applications = (section 3.5), >>> but only states that they should not be accessible on the WAN = interface by >>> default. It might be worthwhile to update it according to your = thoughts above. >>>=20 >>> --Scott >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 http://www.ipinc.net/IPv4.GIF From fred@cisco.com Wed Aug 11 09:29:42 2010 Return-Path: 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 A89E63A6A50; Wed, 11 Aug 2010 09:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.223 X-Spam-Level: X-Spam-Status: No, score=-110.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 0Jp-ShJZZl9s; Wed, 11 Aug 2010 09:29:41 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 17C383A6A33; Wed, 11 Aug 2010 09:29:41 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,354,1278288000"; d="scan'208";a="238860035" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 11 Aug 2010 16:30:17 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7BGUAK7027760; Wed, 11 Aug 2010 16:30:11 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 11 Aug 2010 09:30:17 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 11 Aug 2010 09:30:17 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker X-Priority: 3 (Normal) In-Reply-To: <65E2BBE0-0BF0-4695-A46F-05BFB9E666F8@cisco.com> Date: Wed, 11 Aug 2010 09:30:03 -0700 Message-Id: <9909FF61-A552-4DEB-BB64-728B22605E7D@cisco.com> References: <1280871146.382928184@192.168.2.231> <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg> <1281120642.72688236@192.168.2.229> <00A6D384-5CD8-4E7A-A342-C19CA8C640FA@cisco.com> <65E2BBE0-0BF0-4695-A46F-05BFB9E666F8@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Chris Donley , secdir@ietf.org, Ron Bonica , draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org, cpe-router@external.cisco.com, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router 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: , X-List-Received-Date: Wed, 11 Aug 2010 16:29:42 -0000 Ack. Pick up the other two changes, which are minute, post it, and give = the IESG the diffs URL. Thanks. On Aug 11, 2010, at 9:02 AM, Ole Troan wrote: > Fred, >=20 >> Note from the document shepherd... >>=20 >> The process is that the IESG expects an updated draft in response to = comments. However, they usually consider the draft for a while and then = TELL you that they want it. It is on the telechat for approval Thursday, = and per = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/ has = no "discuss" ballots and "enough positions to pass", which appears to be = two "no objection" ballots. >>=20 >> Tell me: what is required to address Scott's comments? Is this a big = change or a small one? If it is a small enough change, I would suggest = that you address it, address Stewart's comment ("expand acronym MLD on = first usage"), and pick up three idnits points that have crept in since = the draft was last posted: >>=20 >> Checking references for intended status: Informational >> = --------------------------------------------------------------------------= -- >>=20 >> =3D=3D Outdated reference: draft-ietf-6man-ipv6-subnet-model has been = published >> as RFC 5942 >>=20 >> =3D=3D Outdated reference: A later version (-05) exists of >> draft-ietf-6man-node-req-bis-04 >>=20 >> =3D=3D Outdated reference: A later version (-12) exists of >> draft-ietf-v6ops-cpe-simple-security-11 >>=20 >> And then post it and send a URL to the diffs to the IESG so they can = see what you did. That would allow them to send it on tomorrow. If doing = that in the next few hours isn't reasonable, then wait for the IESG = remarks, which I would expect will sound a lot like what I just said but = with a different date. >=20 > thanks for the clarification, the changes are in my opinion small. >=20 > the security considerations are limited to tightening up language and = make it clear what we "expect" from the CPE simple security draft: >=20 >
> It is considered a best practice to filter obviously = malicious > traffic (e.g. spoofed packets, "martian" addresses, etc.). = Thus, the > - IPv6 CE router should support basic stateless egress and = ingress > - filters. The CE router should also offer mechanisms to = filter > + IPv6 CE router ought to support basic stateless egress and = ingress > + filters. The CE router is also expected to offer mechanisms = to filter > traffic entering the customer network; however, the method by = which > vendors implement configurable packet filtering is beyond the = scope of > this document. >=20 > Security requirements: > - The IPv6 CE router SHOULD support > - . > + The IPv6 CE router SHOULD support + target=3D"I-D.ietf-v6ops-cpe-simple-security">. In > + particular, the IPv6 CE router SHOULD support > + functionality sufficient for implementing the set of > + recommendations in + target=3D"I-D.ietf-v6ops-cpe-simple-security"> > + section 4. Ths document takes no position on whether such > + functionality is enabled by default or mechanisms by = which > + users would configure it. >=20 > in addition we have on the advice from the DHC WG removed the last = part of this requirement: > If the IPv6 CE router requests both an IA_NA and an IA_PD > in DHCPv6, it MUST accept an IA_PD in DHCPv6 Advertise/Reply > - messages, even if the message does not contain any addresses > - (IA_NA options with status code equal to NoAddrsAvail). > + messages, even if the message does not contain any > + addresses. >=20 > cheers, > Ole >=20 >=20 http://www.ipinc.net/IPv4.GIF From ot@cisco.com Wed Aug 11 09:02:18 2010 Return-Path: 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 C935E3A69B9; Wed, 11 Aug 2010 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.886 X-Spam-Level: X-Spam-Status: No, score=-9.886 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, 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 IPdNcoQ5pAd6; Wed, 11 Aug 2010 09:02:17 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1D7253A68D4; Wed, 11 Aug 2010 09:02:17 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,353,1278288000"; d="scan'208";a="146484741" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2010 16:02:53 +0000 Received: from [10.0.0.8] (ams3-vpn-dhcp6343.cisco.com [10.61.88.198]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7BG2o9w015318; Wed, 11 Aug 2010 16:02:51 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ole Troan X-Priority: 3 (Normal) In-Reply-To: <00A6D384-5CD8-4E7A-A342-C19CA8C640FA@cisco.com> Date: Wed, 11 Aug 2010 18:02:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65E2BBE0-0BF0-4695-A46F-05BFB9E666F8@cisco.com> References: <1280871146.382928184@192.168.2.231> <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg> <1281120642.72688236@192.168.2.229> <00A6D384-5CD8-4E7A-A342-C19CA8C640FA@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Wed, 11 Aug 2010 10:33:03 -0700 Cc: Chris Donley , secdir@ietf.org, Ron Bonica , draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org, cpe-router@external.cisco.com, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router 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: , X-List-Received-Date: Wed, 11 Aug 2010 16:02:18 -0000 Fred, > Note from the document shepherd... >=20 > The process is that the IESG expects an updated draft in response to = comments. However, they usually consider the draft for a while and then = TELL you that they want it. It is on the telechat for approval Thursday, = and per = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/ has = no "discuss" ballots and "enough positions to pass", which appears to be = two "no objection" ballots. >=20 > Tell me: what is required to address Scott's comments? Is this a big = change or a small one? If it is a small enough change, I would suggest = that you address it, address Stewart's comment ("expand acronym MLD on = first usage"), and pick up three idnits points that have crept in since = the draft was last posted: >=20 > Checking references for intended status: Informational > = --------------------------------------------------------------------------= -- >=20 > =3D=3D Outdated reference: draft-ietf-6man-ipv6-subnet-model has been = published > as RFC 5942 >=20 > =3D=3D Outdated reference: A later version (-05) exists of > draft-ietf-6man-node-req-bis-04 >=20 > =3D=3D Outdated reference: A later version (-12) exists of > draft-ietf-v6ops-cpe-simple-security-11 >=20 > And then post it and send a URL to the diffs to the IESG so they can = see what you did. That would allow them to send it on tomorrow. If doing = that in the next few hours isn't reasonable, then wait for the IESG = remarks, which I would expect will sound a lot like what I just said but = with a different date. thanks for the clarification, the changes are in my opinion small. the security considerations are limited to tightening up language and = make it clear what we "expect" from the CPE simple security draft:
It is considered a best practice to filter obviously = malicious traffic (e.g. spoofed packets, "martian" addresses, etc.). = Thus, the - IPv6 CE router should support basic stateless egress and = ingress - filters. The CE router should also offer mechanisms to filter + IPv6 CE router ought to support basic stateless egress and = ingress + filters. The CE router is also expected to offer mechanisms to = filter traffic entering the customer network; however, the method by = which vendors implement configurable packet filtering is beyond the = scope of this document. =20 Security requirements: - The IPv6 CE router SHOULD support - . + The IPv6 CE router SHOULD support . In + particular, the IPv6 CE router SHOULD support + functionality sufficient for implementing the set of + recommendations in + section 4. Ths document takes no position on whether such + functionality is enabled by default or mechanisms by which + users would configure it. in addition we have on the advice from the DHC WG removed the last part = of this requirement: If the IPv6 CE router requests both an IA_NA and an IA_PD in DHCPv6, it MUST accept an IA_PD in DHCPv6 Advertise/Reply - messages, even if the message does not contain any addresses - (IA_NA options with status code equal to NoAddrsAvail). + messages, even if the message does not contain any + addresses. cheers, Ole From ot@cisco.com Wed Aug 11 09:57:03 2010 Return-Path: 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 A13473A6968; Wed, 11 Aug 2010 09:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.028 X-Spam-Level: X-Spam-Status: No, score=-10.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, 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 iTrJhtmdbuzI; Wed, 11 Aug 2010 09:57:02 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0A6443A6A74; Wed, 11 Aug 2010 09:57:01 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,354,1278288000"; d="scan'208";a="146506373" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2010 16:57:38 +0000 Received: from [10.0.0.8] (ams3-vpn-dhcp6343.cisco.com [10.61.88.198]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7BGvZRU028148; Wed, 11 Aug 2010 16:57:36 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ole Troan X-Priority: 3 (Normal) In-Reply-To: <9909FF61-A552-4DEB-BB64-728B22605E7D@cisco.com> Date: Wed, 11 Aug 2010 18:57:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81DD3B0D-072D-4563-BBFE-89DA96912902@cisco.com> References: <1280871146.382928184@192.168.2.231> <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg> <1281120642.72688236@192.168.2.229> <00A6D384-5CD8-4E7A-A342-C19CA8C640FA@cisco.com> <65E2BBE0-0BF0-4695-A46F-05BFB9E666F8@cisco.com> <9909FF61-A552-4DEB-BB64-728B22605E7D@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Wed, 11 Aug 2010 10:33:03 -0700 Cc: Chris Donley , secdir@ietf.org, Ron Bonica , draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org, cpe-router@external.cisco.com, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router 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: , X-List-Received-Date: Wed, 11 Aug 2010 16:57:03 -0000 Fred, > Ack. Pick up the other two changes, which are minute, post it, and = give the IESG the diffs URL. Thanks. thanks again. posted. the diffs are at: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6-cpe-router-07.t= xt (also the previously discussed L-16/W-6 changes are included.) cheers, Ole >=20 >> Fred, >>=20 >>> Note from the document shepherd... >>>=20 >>> The process is that the IESG expects an updated draft in response to = comments. However, they usually consider the draft for a while and then = TELL you that they want it. It is on the telechat for approval Thursday, = and per = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/ has = no "discuss" ballots and "enough positions to pass", which appears to be = two "no objection" ballots. >>>=20 >>> Tell me: what is required to address Scott's comments? Is this a big = change or a small one? If it is a small enough change, I would suggest = that you address it, address Stewart's comment ("expand acronym MLD on = first usage"), and pick up three idnits points that have crept in since = the draft was last posted: >>>=20 >>> Checking references for intended status: Informational >>> = --------------------------------------------------------------------------= -- >>>=20 >>> =3D=3D Outdated reference: draft-ietf-6man-ipv6-subnet-model has = been published >>> as RFC 5942 >>>=20 >>> =3D=3D Outdated reference: A later version (-05) exists of >>> draft-ietf-6man-node-req-bis-04 >>>=20 >>> =3D=3D Outdated reference: A later version (-12) exists of >>> draft-ietf-v6ops-cpe-simple-security-11 >>>=20 >>> And then post it and send a URL to the diffs to the IESG so they can = see what you did. That would allow them to send it on tomorrow. If doing = that in the next few hours isn't reasonable, then wait for the IESG = remarks, which I would expect will sound a lot like what I just said but = with a different date. >>=20 >> thanks for the clarification, the changes are in my opinion small. >>=20 >> the security considerations are limited to tightening up language and = make it clear what we "expect" from the CPE simple security draft: >>=20 >>
>> It is considered a best practice to filter obviously = malicious >> traffic (e.g. spoofed packets, "martian" addresses, etc.). = Thus, the >> - IPv6 CE router should support basic stateless egress and = ingress >> - filters. The CE router should also offer mechanisms to = filter >> + IPv6 CE router ought to support basic stateless egress and = ingress >> + filters. The CE router is also expected to offer mechanisms = to filter >> traffic entering the customer network; however, the method by = which >> vendors implement configurable packet filtering is beyond the = scope of >> this document. >>=20 >> Security requirements: >> - The IPv6 CE router SHOULD support >> - . >> + The IPv6 CE router SHOULD support > + target=3D"I-D.ietf-v6ops-cpe-simple-security">. = In >> + particular, the IPv6 CE router SHOULD support >> + functionality sufficient for implementing the set of >> + recommendations in > + target=3D"I-D.ietf-v6ops-cpe-simple-security"> >> + section 4. Ths document takes no position on whether = such >> + functionality is enabled by default or mechanisms by = which >> + users would configure it. >>=20 >> in addition we have on the advice from the DHC WG removed the last = part of this requirement: >> If the IPv6 CE router requests both an IA_NA and an IA_PD >> in DHCPv6, it MUST accept an IA_PD in DHCPv6 Advertise/Reply >> - messages, even if the message does not contain any = addresses >> - (IA_NA options with status code equal to NoAddrsAvail). >> + messages, even if the message does not contain any >> + addresses. >>=20 >> cheers, >> Ole >>=20 >>=20 >=20 > http://www.ipinc.net/IPv4.GIF >=20 From mundy@sparta.com Wed Aug 11 21:03:40 2010 Return-Path: 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 D157A3A68CE; Wed, 11 Aug 2010 21:03:40 -0700 (PDT) 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 rlxUG01QRKg6; Wed, 11 Aug 2010 21:03:40 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id D90843A689E; Wed, 11 Aug 2010 21:03:39 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o7C44Ftu010485; Wed, 11 Aug 2010 23:04:16 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o7C44Fs0024467; Wed, 11 Aug 2010 23:04:15 -0500 Received: from garfield.home.tislabs.com ([68.33.140.25]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 00:04:14 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by garfield.home.tislabs.com (Postfix) with ESMTP id 65EB4A3B1B6; Thu, 12 Aug 2010 00:04:14 -0400 (EDT) Date: Thu, 12 Aug 2010 00:04:14 -0400 From: mundy@sparta.com To: secdir@ietf.org Message-ID: <20100812000414356621.7dfd1394@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.9 X-OriginalArrivalTime: 12 Aug 2010 04:04:14.0933 (UTC) FILETIME=[6D919050:01CB39D3] Cc: iesg@ietf.org, draft-ietf-v6ops-isp-scenarios.all@tools.ietf.org, mundy@sparta.com Subject: [secdir] Review of draft-ietf-v6ops-isp-scenarios-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: , X-List-Received-Date: Thu, 12 Aug 2010 04:03:40 -0000 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 provides the results of a technical survey of several ISPs about their actual or planned IPv6 deployment strategies. The document has an appropriate Security Considerations section which, essentially says, the document has no security impacts. Russ Mundy From weiler+ietf@watson.org Sun Aug 15 22:41:18 2010 Return-Path: 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 481553A694D for ; Sun, 15 Aug 2010 22:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.081 X-Spam-Level: X-Spam-Status: No, score=-1.081 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_50=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 v1gVSR5zYVhH for ; Sun, 15 Aug 2010 22:41:16 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 5064B3A6822 for ; Sun, 15 Aug 2010 22:41:16 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o7G5fpb0049837 for ; Mon, 16 Aug 2010 01:41:51 -0400 (EDT) (envelope-from weiler+ietf@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o7G5fp4F049834 for ; Mon, 16 Aug 2010 01:41:51 -0400 (EDT) (envelope-from weiler+ietf@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 16 Aug 2010 01:41:51 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 16 Aug 2010 01:41:51 -0400 (EDT) Subject: [secdir] Assignments 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: , X-List-Received-Date: Mon, 16 Aug 2010 05:41:22 -0000 Juergen Schoenwaelder is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The assignment email format has changed to show last call end dates for all docs, even those scheduled for telechat. Special requests won't have one, nor will docs for which as LC has been requested but not yet issued. -- Sam For telechat 2010-08-26 Reviewer LC end Draft Steve Hanna TR2010-07-06 draft-ietf-tsvwg-ecn-tunnel-09 Jeffrey Hutzelman T 2010-07-23 draft-ietf-pkix-ta-mgmt-reqs-05 Catherine Meadows T - draft-ietf-tcpm-tcp-lcd-02 Magnus Nystrom T - draft-ietf-isms-radius-vacm-09 Eric Rescorla T 2010-09-06 draft-das-mipshop-andsf-dhcp-options-04 Joe Salowey T 2010-08-23 draft-ietf-mif-problem-statement-07 Stefan Santesson T 2010-08-23 draft-ietf-mipshop-transient-bce-pmipv6-06 Brian Weis TR2010-05-19 draft-sheffer-emu-eap-eke-07 Nico Williams T 2010-07-16 draft-turner-suiteb-cmc-03 Larry Zhu T 2010-08-12 draft-thaler-v6ops-teredo-extensions-07 Last calls and special requests: Reviewer LC end Draft Phillip Hallam-Baker 2010-07-23 draft-ietf-geopriv-arch-02 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-08 Julien Laganier - draft-ietf-nsis-nslp-auth-06 Barry Leiba 2010-08-12 draft-saintandre-tls-server-id-check-09 Chris Lonvick 2010-08-05 draft-ietf-netmod-arch-07 David McGrew - draft-ietf-ecrit-framework-11 David McGrew 2010-08-05 draft-ietf-pce-manageability-requirements-10 Chris Newman 2010-08-23 draft-azinger-additional-private-ipv4-space-issues-04 Hilarie Orman 2010-08-16 draft-ietf-calsify-rfc2447bis-10 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Vincent Roca 2010-08-23 draft-ietf-fecframe-framework-09 Brian Weis 2010-07-16 draft-daboo-srv-caldav-05 Larry Zhu - draft-ietf-sip-domain-certs-07 Glen Zorn 2010-07-26 draft-cakulev-mikey-ibake-02 From kivinen@iki.fi Mon Aug 16 04:59:20 2010 Return-Path: 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 0F33A3A680E; Mon, 16 Aug 2010 04:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 SCr5aI-mN-O0; Mon, 16 Aug 2010 04:59:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C891E3A67B4; Mon, 16 Aug 2010 04:59:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o7GBxdjc025652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 14:59:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o7GBxbmN025918; Mon, 16 Aug 2010 14:59:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19561.10281.349168.728229@fireball.kivinen.iki.fi> Date: Mon, 16 Aug 2010 14:59:37 +0300 From: Tero Kivinen To: Xing Li In-Reply-To: <4C62CD51.60401@cernet.edu.cn> References: <19474.9888.922292.408395@fireball.kivinen.iki.fi> <4C62CD51.60401@cernet.edu.cn> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: draft-ietf-behave-v6v4-xlate.all@tools.ietf.org, congxiao , Fred Baker , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-behave-v6v4-xlate-20 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: , X-List-Received-Date: Mon, 16 Aug 2010 11:59:20 -0000 Xing Li writes: > Thank you very much for the comments. With the help of the behave > chairs, we have updated the security session of xlate draft, the text reads New version of security considerations section looks good for me. > 7. Security Considerations > > The use of stateless IP/ICMP translators does not introduce any new > security issues beyond the security issues that are already present > in the IPv4 and IPv6 protocols and in the routing protocols that are > used to make the packets reach the translator. > > There are potential issues that might arise by deriving an IPv4 > address from an IPv6 address - particularly addresses like broadcast > or loopback addresses and the non IPv4-translatable IPv6 addresses, > etc. The [I-D.ietf-behave-address-format] addresses these issues. > > As with network address translation of IPv4 to IPv4, the IPsec > Authentication Header [RFC4302] cannot be used across an IPv6 to IPv4 > translator. > > As with network address translation of IPv4 to IPv4, packets with > tunnel mode ESP can be translated since tunnel mode ESP does not > depend on header fields prior to the ESP header. Similarly, > transport mode ESP will fail with IPv6 to IPv4 translation unless > checksum neutral addresses are used. In both cases, the IPsec ESP > endpoints will normally detect the presence of the translator and > encapsulate ESP in UDP packets [RFC3948]. -- kivinen@iki.fi From bew@cisco.com Mon Aug 16 20:52:08 2010 Return-Path: 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 CDFEE3A6843; Mon, 16 Aug 2010 20:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Bn5EQiAHN+Kb; Mon, 16 Aug 2010 20:52:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EF4863A6842; Mon, 16 Aug 2010 20:52:07 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD+kaUyrRN+J/2dsb2JhbACgS3GibpwYgxGCKgSELYU1 X-IronPort-AV: E=Sophos;i="4.55,380,1278288000"; d="scan'208";a="574426966" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 17 Aug 2010 03:52:43 +0000 Received: from stealth-10-32-244-213.cisco.com (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7H3qhKl020142; Tue, 17 Aug 2010 03:52:43 GMT Message-Id: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> From: Brian Weis To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Aug 2010 20:52:42 -0700 X-Mailer: Apple Mail (2.936) Cc: draft-sheffer-emu-eap-eke@tools.ietf.org Subject: [secdir] Secdir review of draft-sheffer-emu-eap-eke-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: , X-List-Received-Date: Tue, 17 Aug 2010 03:52:08 -0000 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 review comments. I previously reviewed -06 of this I-D and made a number of suggestions. The current version has addressed those as well as other last call comments. I have just one concern and one comment regarding the changes regarding encrypting DHComponent_S and DHComponent_P in on- the-wire payloads. This is described in Sections 5.1, 5.2, and 6.1. I'm going to discuss DHComponent_S, but DHComponent_P is similarly changed. 1. In -06, DHComponent_S was protected with an IKEv2-style prf+(): DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), y_s), In -07, DHComponent_S is now protected with a "keyed MAC": DHComponent_S = Encr(kmac+(password), y_s) where kmac+() is defined as: kmac+(P) = T1 | T2 | ... where each Ti is an application of the keyed MAC with a fixed key: T1 = kmac("S"+, P | 0x01) T2 = kmac("S"+, T1 | P | 0x02) T3 = kmac("S"+, T2 | P | 0x03) Dan Harkins suggested an "extractor and expander" KDF, which I believe motivated this change. I think the use of a constant "salt" value used as a key in kmac+ approximates only the "extractor" function described in RFC 5869, and the output of an "extractor" is not intended to be the final KDF output. An "expander" function is necessary to follow the "extractor" function, and prf+ fits that description. So unless I'm mistaken, these section should define two calls: one to kmac() to to create an intermediate value of the appropriate size, and the another that uses the intermediate value as the key to a prf+ call. I think it might be convenient to require the kmac+ and prf+ algorithms be the same. 2. As far as I can tell, the definition of "kmac" is new to this I-D, which I found a bit confusing. It's really just a MAC, so I think it would be clearer to just call it a mac(). Brian From magnusn@gmail.com Mon Aug 16 22:32:01 2010 Return-Path: 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 F1D293A6927; Mon, 16 Aug 2010 22:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 5XMh5Qt1TNq2; Mon, 16 Aug 2010 22:31:40 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 00E723A6924; Mon, 16 Aug 2010 22:31:30 -0700 (PDT) Received: by gyg8 with SMTP id 8so2657136gyg.31 for ; Mon, 16 Aug 2010 22:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=beK+8opxGl2BhamekfX3Oq9FFpNatS0ZVFdvoDRsfTA=; b=bWhGm0xauhAEyMwVyXisZzBYFLRH2acSZgn+iy0D+GpscXbeGdjw26SNAdN8yorKtY K0Y8nIGe2pd56mTOFy0lTgAwP7/Kp92f3UtR6RTtP8y1577tzMS2AisjscpnkJMD7Dbz 411ezXxTAPoDsKZG7Jz6uOVn+3I+8zvDTYcRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wdCx8UF0jXJB0PcEnx3A5a5HrW9Pj4jPZLIKwMq7cc/nltUDRlZsaA1GyYA3Q8rKsW rhyjzEp3wgFhJUpBQ9ETJpTNtfZ10plGEE2SjlaClrMLY/eAYpEd0t+R8sm/shS5mlsJ FE9sehtQ385Sw/9wcC/DIHKXh0peQLsJ+tugE= MIME-Version: 1.0 Received: by 10.231.191.16 with SMTP id dk16mr1095713ibb.161.1282023118736; Mon, 16 Aug 2010 22:31:58 -0700 (PDT) Received: by 10.231.145.67 with HTTP; Mon, 16 Aug 2010 22:31:58 -0700 (PDT) Date: Mon, 16 Aug 2010 22:31:58 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: secdir@ietf.org, iesg@ietf.org, draft-ietf-isms-radius-vacm@tools.ietf.org Content-Type: multipart/alternative; boundary=0016367d6d4296118b048dfe44fd Subject: [secdir] Secdir review of draft-ietf-isms-radius-vacm-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: , X-List-Received-Date: Tue, 17 Aug 2010 05:32:06 -0000 --0016367d6d4296118b048dfe44fd Content-Type: text/plain; charset=ISO-8859-1 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 "the use of information provided by [AAA] services ... to dynamically update user-to-group mappings in [VACM]." - it does this by adding a module to the MIB and defining elements of procedure for the new object types in this MIB. The document reads well and has a good security considerations section. I only have a couple of comments on Section 7: 1. (Editorial:) Suggest letting the first paragraph form a new sub-subsection 7.2.1: "Required Information". Easier to reference. 2. In the current subsection 7.2, please clarify if all items are required for "further processing" or not. The current text just states that User-Name and Management-Policy-ID are. 3. Current sub-subsection 7.2.1 seems to indicate that neither the User-Name nor the Management-Policy-ID are required (says "or equivalent"). Please clarify if this is inconsistent with the text in 7.2 or not (maybe I'm missing something here). 4. In Section 7.2.3, how many groups can a user be a member of for a given securityModel in this design? Only one? -- Magnus --0016367d6d4296118b048dfe44fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dir= ectorate's ongoing effort to review all IETF documents being processed by the IESG. =A0These comments were written primarily fo= r the benefit of the security area directors. =A0Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines "the use of information provided by [AAA] servic= es ... to dynamically update user-to-group mappings in [VACM]." - it d= oes this by adding a module to the MIB and defining elements of procedure f= or the new object types in this MIB.
=A0
The document reads well and has a good security considerations section.= I only have a couple of comments on Section 7:

1. (Editorial:) Sugg= est letting the first paragraph form a new sub-subsection 7.2.1: "Requ= ired Information". Easier to reference.
2. In the current subsection 7.2, please clarify if all items are required = for "further processing" or not. The current text just states tha= t User-Name and Management-Policy-ID are.
3. Current sub-subsection 7.2.= 1 seems to indicate that neither the User-Name nor the Management-Policy-ID= are required (says "or equivalent"). Please clarify if this is i= nconsistent with the text in 7.2 or not (maybe I'm missing something he= re).
4. In Section 7.2.3, how many groups can a user be a member of for a given = securityModel in this design? Only one?

-- Magnus

--0016367d6d4296118b048dfe44fd-- From d.b.nelson@comcast.net Tue Aug 17 04:52:38 2010 Return-Path: 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 337E63A6955 for ; Tue, 17 Aug 2010 04:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.81 X-Spam-Level: X-Spam-Status: No, score=-100.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, 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 RFtYG3ONXv1c for ; Tue, 17 Aug 2010 04:52:37 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 4813E3A6951 for ; Tue, 17 Aug 2010 04:52:37 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta06.westchester.pa.mail.comcast.net with comcast id vPNn1e0091wpRvQ56PtD9K; Tue, 17 Aug 2010 11:53:13 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta18.westchester.pa.mail.comcast.net with comcast id vPtD1e00A0yip6Y3ePtDCu; Tue, 17 Aug 2010 11:53:13 +0000 From: "Dave Nelson" To: =?iso-8859-1?Q?'Magnus_Nystr=F6m'?= , , , References: Date: Tue, 17 Aug 2010 07:53:22 -0400 Message-ID: <7105B213EC2849C18053B4A2A2D79E24@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: Acs9ztU4KJSZdzpxR+KgJaBq41QpigAMrMEg Subject: Re: [secdir] Secdir review of draft-ietf-isms-radius-vacm-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: , X-List-Received-Date: Tue, 17 Aug 2010 11:52:38 -0000 Magnus Nystr=F6m writes... > 3. Current sub-subsection 7.2.1 seems to indicate that neither > the User-Name nor the Management-Policy-ID are required (says > "or equivalent"). Please clarify if this is inconsistent with > the text in 7.2 or not (maybe I'm missing something here). Use of the term "or equivalent" is intended to cover the use of other = AAA protocols besides RADIUS. For use with RADIUS, the User-Name and Management-Policy-Id are required to use mechanism described in this document. For some other, hypothetical, AAA service the equivalent attributes may have other names. This is just a bit of editorial future-proofing. The other IETF standard AAA protocol, Diameter, = inherits the RADIUS attribute space, so these attributes are also available via Diamter. > 4. In Section 7.2.3, how many groups can a user be a member of > for a given securityModel in this design? Only one? RFC 5607 allows zero or one instance of the Management-Policy-Id to = occur in any RADIUS Access-Accept message, so for RADIUS usage it would be only = one. From new-work-bounces@ietf.org Tue Aug 17 10:30:57 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C353A6AED; Tue, 17 Aug 2010 10:30:57 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9877D3A6A3C; Tue, 17 Aug 2010 10:30:11 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100817173022.9877D3A6A3C@core3.amsl.com> Date: Tue, 17 Aug 2010 10:30:12 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 17 Aug 2010 10:41:18 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Mobility EXTensions for IPv6 (mext) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 17:30:57 -0000 A modified charter has been submitted for the Mobility EXTensions for IPv6 (mext) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, August 24, 2010. Mobility EXTensions for IPv6 (mext) --------------------------------------------- Status: Active Working Group Last updated: 2010-07-28 Chairs: Marcelo Bagnulo Julien Laganier Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) o RFC 5555 (Dual Stack Mobile IPv6) o RFC 5648 (Multiple Care-of Addresses Registration) o RFC 5846 (Binding Revocation) o RFC-to-be (Flow Binding Policy Transport and Flow Binding Policy Format) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. The MEXT WG will also explore experimental alternative security mechanisms. The security mechanism specified in the existing standard track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement mechanism that guarantees interoperability between different implementations. The MEXT WG is chartered to deliver one or more experimental alternative mechanisms. All the alternative solutions will be published as experimental RFCs. In addition, the working group will bring to completion earlier work on prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6 operation with firewalls, and home agent reliability specifications. Work items related to base specification maintenance include: Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. Goals and Milestones: Dec 2010 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Jun 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Jan 2010 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Dec 2010 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Jan 2011 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Aug 2011 Submit I-Ds on alternative security mechanisms to the IESG for publication as experimental _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From randy_presuhn@mindspring.com Tue Aug 17 12:43:13 2010 Return-Path: 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 595D73A6889; Tue, 17 Aug 2010 12:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.699 X-Spam-Level: X-Spam-Status: No, score=-99.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, 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 4WrGERaL6l63; Tue, 17 Aug 2010 12:43:12 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 6B6D43A685C; Tue, 17 Aug 2010 12:43:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jcO/GsT51yrq7fFWwNtOJiFepgkDV5wIsbm5W7PWqTzWlikmWbpvWq2BzN8BRyQV; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.48.100] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlS4Y-0004Gw-O9; Tue, 17 Aug 2010 15:43:47 -0400 Message-ID: <005601cb3e44$82ffede0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Dave Nelson" , =?iso-8859-1?Q?'Magnus_Nystr=F6m'?= , , , References: <7105B213EC2849C18053B4A2A2D79E24@NEWTON603> Date: Tue, 17 Aug 2010 12:43:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe235317df358a8a85429d7493dd29a37a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.48.100 Subject: Re: [secdir] Secdir review of draft-ietf-isms-radius-vacm-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: , X-List-Received-Date: Tue, 17 Aug 2010 19:43:13 -0000 Hi - > From: "Dave Nelson" > To: "'Magnus Nyström'" ; ; ; > Sent: Tuesday, August 17, 2010 4:53 AM > Subject: RE: Secdir review of draft-ietf-isms-radius-vacm-09 > > Magnus Nyström writes... ... > > 4. In Section 7.2.3, how many groups can a user be a member of > > for a given securityModel in this design? Only one? > > RFC 5607 allows zero or one instance of the Management-Policy-Id to occur in > any RADIUS Access-Accept message, so for RADIUS usage it would be only one. Likewise, the design of VACM (RFC 3415) maps a (securityModel, securityName) tuple to a single group. If multiple (different) pairings were received from RADIUS, (or from the security administrator) only the most recent would be in effect. I think this makes both operational and security sense. Randy From randy_presuhn@mindspring.com Tue Aug 17 14:03:07 2010 Return-Path: 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 2CE933A6A3F; Tue, 17 Aug 2010 14:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 BAaSTTLOHl8S; Tue, 17 Aug 2010 14:03:06 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2C8773A6A2E; Tue, 17 Aug 2010 14:03:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bLfHqafPdK8TAigm2PahAM2NP+vXapH4123kaWV2hYoyt+yhiYy5q7199LBQwyRr; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.48.100] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlTJt-00047S-4Q; Tue, 17 Aug 2010 17:03:41 -0400 Message-ID: <00d501cb3e4f$ad1ba640$6801a8c0@oemcomputer> From: "Randy Presuhn" To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= , , , References: Date: Tue, 17 Aug 2010 14:03:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fec4a90bd2698274c7c120a740f9361f35350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.48.100 Subject: Re: [secdir] Secdir review of draft-ietf-isms-radius-vacm-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: , X-List-Received-Date: Tue, 17 Aug 2010 21:03:07 -0000 Hi - Thanks for the detailed comments. Responses in-line below. > From: "Magnus Nyström" > To: ; ; > Sent: Monday, August 16, 2010 10:31 PM > Subject: Secdir review of draft-ietf-isms-radius-vacm-09 > > 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 "the use of information provided by [AAA] services ... > to dynamically update user-to-group mappings in [VACM]." - it does this by > adding a module to the MIB and defining elements of procedure for the new > object types in this MIB. > > The document reads well and has a good security considerations section. I > only have a couple of comments on Section 7: > > 1. (Editorial:) Suggest letting the first paragraph form a new > sub-subsection 7.2.1: "Required Information". Easier to reference. Ok. I just hope we don't get an objection to using the 2119 keyword :-). > 2. In the current subsection 7.2, please clarify if all items are required > for "further processing" or not. The current text just states that User-Name > and Management-Policy-ID are. Ok. I'll add "All four of these pieces of information are REQUIRED." The issue we're trying to address in that last sentence are that one of those (externally provided parameters) might be present but invalid. > 3. Current sub-subsection 7.2.1 seems to indicate that neither the User-Name > nor the Management-Policy-ID are required (says "or equivalent"). Please > clarify if this is inconsistent with the text in 7.2 or not (maybe I'm > missing something here). Given Dave Nelson's explanation, do you still think a change is needed here? > 4. In Section 7.2.3, how many groups can a user be a member of for a given > securityModel in this design? Only one? Would it help to add this sentence at the end of 7.2.3? The structure of the vacmSecurityToGroupTable makes it impossible for a vacmSecurityModel, vacmSecurityName tuple to map to more than one group. > -- Magnus > Randy From clonvick@cisco.com Wed Aug 18 14:14:57 2010 Return-Path: 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 DB6BC3A6A20; Wed, 18 Aug 2010 14:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 t3OZyqd7L1B7; Wed, 18 Aug 2010 14:14:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E1FB33A6A1A; Wed, 18 Aug 2010 14:14:56 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAKvqa0yrR7Hu/2dsb2JhbACTOgGNG3GlWZtxhTcEhDE X-IronPort-AV: E=Sophos;i="4.56,229,1280707200"; d="scan'208";a="273299580" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2010 21:15:32 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7ILFWe3026789; Wed, 18 Aug 2010 21:15:32 GMT Date: Wed, 18 Aug 2010 14:15:31 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-netmod-arch.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: secdir-secretary@mit.edu Subject: [secdir] SECDIR review of draft-ietf-netmod-arch-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: , X-List-Received-Date: Wed, 18 Aug 2010 21:14:58 -0000 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. Honestly, the thing looks good and I don't have anything to add. Good job. Regards, Chris From weiler@watson.org Fri Aug 20 08:07:29 2010 Return-Path: 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 75A473A6AB4 for ; Fri, 20 Aug 2010 08:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_40=-0.185] 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 MAy+J+sglYpv for ; Fri, 20 Aug 2010 08:07:27 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 296993A68BC for ; Fri, 20 Aug 2010 08:07:27 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o7KF80O3012997 for ; Fri, 20 Aug 2010 11:08:00 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o7KF80An012994 for ; Fri, 20 Aug 2010 11:08:00 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 20 Aug 2010 11:08:00 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 20 Aug 2010 11:08:00 -0400 (EDT) Subject: [secdir] Assignments 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: , X-List-Received-Date: Fri, 20 Aug 2010 15:07:29 -0000 Sam Weiler is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The assignment email format has changed to show last call end dates for all docs, even those scheduled for telechat. Special requests won't have one, nor will docs for which a LC has been requested but not yet issued. -- Sam For telechat 2010-08-26 Reviewer LC end Draft Steve Hanna TR2010-07-06 draft-ietf-tsvwg-ecn-tunnel-09 Jeffrey Hutzelman T 2010-07-23 draft-ietf-pkix-ta-mgmt-reqs-05 Catherine Meadows T - draft-ietf-tcpm-tcp-lcd-02 Joe Salowey T 2010-08-23 draft-ietf-mif-problem-statement-07 Stefan Santesson T 2010-08-23 draft-ietf-mipshop-transient-bce-pmipv6-06 Nico Williams T 2010-07-16 draft-turner-suiteb-cmc-03 Larry Zhu T 2010-08-12 draft-thaler-v6ops-teredo-extensions-07 Glen Zorn T 2010-07-26 draft-cakulev-mikey-ibake-02 For telechat 2010-09-09 Reviewer LC end Draft Julien Laganier T 2010-08-31 draft-ietf-nsis-nslp-auth-06 Hilarie Orman T 2010-08-16 draft-ietf-calsify-rfc2447bis-10 Eric Rescorla T 2010-09-06 draft-das-mipshop-andsf-dhcp-options-04 Juergen Schoenwaelder T 2010-09-01 draft-ietf-ccamp-gmpls-ethernet-pbb-te-05 Tina TSOU T 2010-09-01 draft-ietf-roll-rpl-11 Last calls and special requests: Reviewer LC end Draft Phillip Hallam-Baker 2010-07-23 draft-ietf-geopriv-arch-02 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-08 Barry Leiba 2010-08-12 draft-saintandre-tls-server-id-check-09 David McGrew - draft-ietf-ecrit-framework-11 David McGrew 2010-08-05 draft-ietf-pce-manageability-requirements-10 Chris Newman 2010-08-23 draft-azinger-additional-private-ipv4-space-issues-04 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Vincent Roca 2010-08-23 draft-ietf-fecframe-framework-09 Yaron Sheffer 2010-09-14 draft-cridland-acap-vendor-registry-01 Carl Wallace 2010-09-13 draft-josefsson-pbkdf2-test-vectors-05 Brian Weis 2010-07-16 draft-daboo-srv-caldav-05 From yaronf.ietf@gmail.com Sat Aug 21 13:41:46 2010 Return-Path: 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 0D8CC3A67FE; Sat, 21 Aug 2010 13:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 pMaQUnaoihSm; Sat, 21 Aug 2010 13:41:44 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 2E92F3A659C; Sat, 21 Aug 2010 13:41:44 -0700 (PDT) Received: by ewy22 with SMTP id 22so2995859ewy.31 for ; Sat, 21 Aug 2010 13:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=9lsajh9qa1vwayBZQzHRktVc+lJ+ksOGWRWWXIZH0bQ=; b=m/gFArWaiJ98sRaUa7pFCZL+cZlIZ5YjjzALWGqnMqNfOyA+laz402k6GXBWlgPekR RBkCzv+edHUke1QGq1O5At7CF+FrAmfLmGiYDy1/7ZDGM492sgz1VILGHDwfiZr7jvFH vOop863Wxn6e+rJqC4PY2UDoveeSj4ZDX4GXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=McNTqrv1hIrZZDNKIlJMDOADhE2CFYO9KsjTdvnJygsZe2ssuCQ7yGKu86pXk95Sd2 bUZ7baEalbP9GJ9NnY3jZVcF1vYqqjcwZNmSaBf4w4D5KaEs2Db235E1q9sxZwUk/CQh jKQChZuLNiwz5RiPHOYI4Z8wVj955LeKZKnMA= Received: by 10.213.2.74 with SMTP id 10mr1811432ebi.45.1282423337682; Sat, 21 Aug 2010 13:42:17 -0700 (PDT) Received: from [10.0.0.3] (bzq-109-67-32-214.red.bezeqint.net [109.67.32.214]) by mx.google.com with ESMTPS id z55sm7534566eeh.21.2010.08.21.13.42.14 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Aug 2010 13:42:16 -0700 (PDT) Message-ID: <4C703A24.4030805@gmail.com> Date: Sat, 21 Aug 2010 23:42:12 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-cridland-acap-vendor-registry.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-cridland-acap-vendor-registry-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: , X-List-Received-Date: Sat, 21 Aug 2010 20:41:46 -0000 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 (re-)defines the ACAP vendor registry. I believe the current very thin security considerations are completely appropriate. Thanks, Yaron From new-work-bounces@ietf.org Mon Aug 23 12:15:53 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9470E3A6AC1; Mon, 23 Aug 2010 12:15:53 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 68FC53A6AC6; Mon, 23 Aug 2010 12:15:51 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100823191551.68FC53A6AC6@core3.amsl.com> Date: Mon, 23 Aug 2010 12:15:51 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 23 Aug 2010 12:25:53 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:15:53 -0000 A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Monday, August 30, 2010. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- v9, 2010-08-23 Current Status: Active Working Group Chairs: Dan Wing Dave Thaler Transport Area Director(s): David Harrington Lars Eggert Transport Area Advisor: David Harrington Mailing Lists: General Discussion: behave@ietf.org To Subscribe: behave-request@ietf.org In Body: In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The working group creates documents to enable NATs to function in as deterministic a fashion as possible. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. BEHAVE will adopt additional work items to finish four scenarios: An IPv6 network to IPv4 Internet, IPv6 Internet to an IPv4 network, An IPv6 network to an IPv4 network, and An IPv4 network to an IPv6 network. These additional work items include suggestions to application developers to improve application interactions with those translation scenarios. The following scenario remains in scope for discussion, and new milestones can be created to address this scenario: * An IPv4 application running on an IPv6-only connected host to the IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is embedded in the IPv4 host. The following scenarios remain in scope for discussion, but creating new milestones will require re-chartering: * An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. * IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. * multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requireents for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Done Determine relative prioritization of the four translation cases. Documented in IETF74 minutes. Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done Submit to IESG: relaying of a TCP bytestream (std) Done Submit to IESG: relay protocol (std) Done Submit to IESG: TURN-URI document (std) Done Submit to IESG: IPv6 relay protocol (std) Done Submit to IESG: framework for IPv6/IPv4 translation (info) Done Submit to IESG: stateless IPv6/IPv4 translation (std) Done Submit to IESG: stateful IPv6/IPv4 translation (std) Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Done Determine need and scope of multicast 6/4 translation Aug 2010 Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Dec 2010 Submit to IESG: large scale NAT requirements (BCP) Apr 2011 Submit to IESG: SCTP NAT behavior (BCP) Dec 2010 Submit to IESG: Analysis of NAT-PT considerations with IPv6/ IPv4 translation (info) Dec 2010 Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std) Apr 2011 Submit to IESG: NAT64 load balancing (std/info) Apr 2011 Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From jsalowey@cisco.com Mon Aug 23 13:09:35 2010 Return-Path: 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 CC4013A6AE9; Mon, 23 Aug 2010 13:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.188 X-Spam-Level: X-Spam-Status: No, score=-110.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 7vlUpQsM2+Zr; Mon, 23 Aug 2010 13:09:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 13A463A6AD2; Mon, 23 Aug 2010 13:09:34 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALNyckyrR7H+/2dsb2JhbACgOnGiG5t+hTcEhDWILg X-IronPort-AV: E=Sophos;i="4.56,259,1280707200"; d="scan'208";a="244074475" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2010 20:10:07 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NKA375017025; Mon, 23 Aug 2010 20:10:07 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 13:10:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Aug 2010 13:10:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-mif-problem-statement-07 Thread-Index: ActC/yvgoazSCrxeTxmIJOll6YW/jQ== From: "Joseph Salowey (jsalowey)" To: , , X-OriginalArrivalTime: 23 Aug 2010 20:10:05.0092 (UTC) FILETIME=[2D195640:01CB42FF] Subject: [secdir] Secdir review of draft-ietf-mif-problem-statement-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: , X-List-Received-Date: Mon, 23 Aug 2010 20:09:36 -0000 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 discusses a problem statement about a single host supporting multiple interfaces and configuration associated with those interfaces. The document does have a security considerations section, however I think it could benefit from more security discussion. Here are a few suggestions: 1) Lower layer authentication and encryption It's possible that some interfaces may have link layer or IP layer encryption and authentication. Its possible that this characteristic might be used in determining how configuration parameters are processed. Some connection managers may already do this to a certain extent. I think this should be listed as a consideration in the appropriate sections of the document (3.1, 3.6,5) 2) I think the security considerations can be expanded It discusses that information may be leaked from one network to another which seems to be talking about generic data. This is true, but it seems that would be worthwhile to talk specifically about the information discussed in the document. For example it seems that it is at least possible for one interface to send configuration parameters that will cause a denial of service on another interface. It may also be possible for one host to set configuration parameters which cause certain traffic to be forwarded to an attacker. =20 The last paragraph is also not very clear. What I think you are trying to say is that the information that is used by the connection manager may be vulnerable to spoofing and forgery if it is unprotected. In general its not possible to protect this information in all cases, so it is not clear what you are recommending. =20 Cheers, Joe From jhutz@cmu.edu Mon Aug 23 14:17:14 2010 Return-Path: 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 9DBF33A6AFF; Mon, 23 Aug 2010 14:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 Es6thihdxx9L; Mon, 23 Aug 2010 14:17:13 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 6AA513A68B1; Mon, 23 Aug 2010 14:17:13 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o7NLHjSU025507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 17:17:45 -0400 (EDT) Date: Mon, 23 Aug 2010 17:17:45 -0400 From: Jeffrey Hutzelman To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pkix-ta-mgmt-reqs.all@tools.ietf.org Message-ID: <77FA72B2BB70374598E2AA84@lysithea.fac.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Subject: [secdir] secdir review of draft-ietf-pkix-ta-mgmt-reqs-05.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: , X-List-Received-Date: Mon, 23 Aug 2010 21:17:14 -0000 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 appears to be the requirements document that led to the just- published RFC5934 (TAMP). It seems pointless to review the requirements document at this late stage, when the protocol itself was completed so long ago that it is already a published RFC. However, I gave it a brief skim and found nothing profoundly concerning. -- Jerff From catherine.meadows@nrl.navy.mil Mon Aug 23 15:23:27 2010 Return-Path: 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 F1A3A3A6AF2; Mon, 23 Aug 2010 15:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, 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 AG9BDGsLWSTE; Mon, 23 Aug 2010 15:23:24 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id A52B23A6960; Mon, 23 Aug 2010 15:23:23 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id o7NMNu4i020084; Mon, 23 Aug 2010 18:23:56 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id o7NMNt0h009510; Mon, 23 Aug 2010 18:23:55 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010082318235401822 ; Mon, 23 Aug 2010 18:23:54 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-12--647387733 Date: Mon, 23 Aug 2010 18:28:10 -0400 Message-Id: To: secdir@ietf.org, iesg@ietf.org, draft-ietf-tcpm-tcp-lcd.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [secdir] Secdir review of draft-ietf-tcpm-tcp-lcd-02 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: , X-List-Received-Date: Mon, 23 Aug 2010 22:23:27 -0000 --Apple-Mail-12--647387733 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 proposes an algorithm to make TCP more robust to long = connectivity disruptions. Currently TCP has no way of distinguishing disruptions due = to connectivity loss from disruptions due to congestion. Thus, TCP will back off when = faced with connectivity loss, which will lead to further delays. The proposed algorithm uses = the ICMP destination unreachable messages as indications of a connectivity disruption, and alters the = behavior of TCP accordingly. My impression from reading this draft is that the behavior and utility = of this algorithm will depend on further research and experimentation. There are a number of situations = in which it will still be possible to confuse congestion and long connectivity disruptions that may need = further exploration. The authors of the document do a good job of = pointing these out, but I would have liked to have seen more evidence that the = solutions recommended are the optimal ones, and under what situations. This is especially the case for the = security issues, although it is not limited to those. For example, in the discussion of probing frequency = in Section 5.4 the authors make a claim that in their belief the approach of their algorithm is preferable to = others that would give higher probing frequency, but they need to provide more evidence to back this up. The security considerations section itself is rather sketchy, and = doesn't support that authors' assertions that the algorithm is "considered to be secure." The greatest security = threat posed by this algorithm is that an attacker could exploit it to persuade a TCP sender = that communication problems due to congestion are actually due to a connectivity problem, leading = the sender to further contribute to the congestion. However, the authors mention only one possible attack: = forging ICMP destination unreachable messages, which they present only as an "example" of an attack. I = would recommend a more complete discussion, considering each of the potential ambiguity cases discussed = in the document, and discussing how an attacker could exploit them and how such exploitation could be = prevented or mitigated. You might also want to discuss the opposite problem: how an attacker could = convince a sender that a connectivity problem is a congestion problem. This is less serious, at least for the = moment, since in the current situation that is exactly what happens, but it could be more of a threat = further down the line if people come to rely more on this ability to disambiguate. =20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-12--647387733 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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 proposes an = algorithm to make TCP more robust to long = connectivity
disruptions.  Currently TCP has no way of = distinguishing disruptions due to connectivity
loss from = disruptions due to congestion.   Thus, TCP will back off when faced = with connectivity
loss, which will lead to further delays. =  The proposed algorithm uses the ICMP destination = unreachable
messages as indications of a connectivity = disruption, and alters the behavior of TCP = accordingly.

My impression from reading this = draft is that the behavior and utility of this algorithm will depend = on
further research and experimentation.  There are a = number of situations in which it will still be possible
to = confuse congestion and long connectivity disruptions that may need = further exploration.  The authors of the document do a good job of = pointing
these out, but I would have liked to have seen more = evidence that the solutions recommended are the optimal
ones, = and under what situations.  This is especially the case for the = security issues, although it is not
limited to those. =  For example, in the discussion of probing frequency in Section 5.4 = the authors make a claim
that in their belief the approach of = their algorithm is preferable to others that would give higher = probing
frequency, but they need to provide more evidence to = back this up.

The security considerations = section itself is rather sketchy, and doesn't support that authors' = assertions
that the algorithm is "considered to be secure." =  The greatest security threat posed by this
algorithm is = that an attacker could exploit it to persuade a TCP sender that = communication problems
due to congestion are actually due to a = connectivity problem, leading the sender to further contribute to = the
congestion.  However, the authors mention only one = possible attack: forging ICMP destination = unreachable
messages, which they present only as an "example" = of an attack.   I would recommend a more = complete
discussion, considering each of the potential = ambiguity cases discussed in the document, and discussing
how = an attacker could exploit them and how such exploitation could be = prevented or mitigated.  You might
also want to discuss = the opposite problem: how an attacker could convince a sender that a = connectivity
problem is a congestion problem.  This is = less serious, at least for the moment, since in the = current
situation that is exactly what happens, but it could = be more of a threat further down the line if people come
to = rely more on this ability to disambiguate. =  


Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail-12--647387733-- From secdir-bounces@mit.edu Wed Aug 25 07:44:04 2010 Return-Path: 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 2BF313A6ADC for ; Wed, 25 Aug 2010 07:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.051 X-Spam-Level: X-Spam-Status: No, score=-104.051 tagged_above=-999 required=5 tests=[AWL=2.548, 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 nztTkcrp+eCL for ; Wed, 25 Aug 2010 07:44:02 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id B555C3A6A47 for ; Wed, 25 Aug 2010 07:44:02 -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 o7PEiZmN023171 for ; Wed, 25 Aug 2010 10:44:35 -0400 Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o7PEiW5D023152 for ; Wed, 25 Aug 2010 10:44:33 -0400 Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o7PEhPnk028536 for ; Wed, 25 Aug 2010 10:44:32 -0400 X-AuditID: 12074425-b7cccae000005f17-da-4c752c472e88 Received: from hermes.jacobs-university.de ( [212.201.44.23]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id F0.0D.24343.84C257C4; Wed, 25 Aug 2010 10:44:24 -0400 (EDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C07F9C0011; Wed, 25 Aug 2010 16:44:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id crPJTk89XJV8; Wed, 25 Aug 2010 16:44:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C42BC0009; Wed, 25 Aug 2010 16:44:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E2521463693; Wed, 25 Aug 2010 16:44:02 +0200 (CEST) Date: Wed, 25 Aug 2010 16:44:02 +0200 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@mit.edu, draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.all@tools.ietf.org Message-ID: <20100825144402.GA1786@elstar.local> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Brightmail-Tracker: AAAAAA== X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.txt X-BeenThere: secdir@ietf.org Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 14:44:04 -0000 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 document describes how GMPLS can be used to manage Ethernet Switched Paths and TE (traffic engineering) Service Instances. As you will see below, I am not at all familiar with the terminology and the technology and all the acronyms used in the document. Security wise, this document essentially refers to other documents, namely RFC 4872 amd RFC 4873. These documents again refer to other documents and ultimately to IPsec as a security solution. If this is correct, perhaps this could be made clearer so people like me do not have to recursively resolve security considerations to find out how things are protected. The security considerations of this document also refer to 802.1AE Media Access Control Security for the protection of "transport" Ethernet. It is not clear what "transport" Ethernet is, perhaps it is the Ethernet traffic carried over the paths. If my interpretation is correct, I would argue that this pointer does not really belong into the security considerations of this document since this specification deals with a part of the signaling plane, not the data plane. Section 5 states that "configuration should be consistent". What happens security wise if configuration is not consistent? This might deserve some discussion in the security considerations. Editorial nits: - Expland the acronym PBB-TE in the title - Explain somewhere what I and B components are; what das I and B stand for? - Explain what the TE in TESI stands for - dangling ] in item 2) on page 11 (also make it clear that the RFC editor may need to adjust the value pending IANA's assignment action) - It seems that several of the informative references are in fact normative; the citations in the document should all be carefully checked - Can a reference be provided where the IEEE defines the set of reserved MAC addresses discussed in section 5.2? /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 From turners@ieca.com Wed Aug 25 11:17:20 2010 Return-Path: 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 C47E93A694E for ; Wed, 25 Aug 2010 11:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 lBlBPsjhjrmX for ; Wed, 25 Aug 2010 11:17:19 -0700 (PDT) Received: from smtp115.biz.mail.mud.yahoo.com (smtp115.biz.mail.mud.yahoo.com [209.191.68.75]) by core3.amsl.com (Postfix) with SMTP id 738453A68EF for ; Wed, 25 Aug 2010 11:17:19 -0700 (PDT) Received: (qmail 40371 invoked from network); 25 Aug 2010 18:17:49 -0000 Received: from thunderfish.local (turners@71.191.1.7 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 25 Aug 2010 11:17:49 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: asUk4.8VM1k899dccudK_0DkrisORsbMztYHrGjPufDYpql xur5N2mcuFYaZfYDFK_Ly2WnWfBAwXLtZlziF8lDqHY.YIYfucAY0ubFGlLJ ILN.RUwTIZo3RpdtmIFccyYsXchv7.2DpZmPPCmkXN94nU6fNLkWbIdLDUtF J3oO0_X4ybBLyjah_SBbGynvQSdYO_aUBK.bYXvGbzt64kWip.m6184H_x4c q5WLMkQJ7eQI7V8rKGGY3nIMUaJVBui4RJjSbGfZ03NgcacfcIhoCSBA1vML wkvCa6Kq3HxkJZdaT5iWx0g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C755E4C.3060907@ieca.com> Date: Wed, 25 Aug 2010 14:17:48 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Brian Weis References: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> In-Reply-To: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-sheffer-emu-eap-eke@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-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: , X-List-Received-Date: Wed, 25 Aug 2010 18:17:21 -0000 Brian Weis wrote: snip > 2. As far as I can tell, the definition of "kmac" is new to this I-D, > which I found a bit confusing. It's really just a MAC, so I think it > would be clearer to just call it a mac(). Maybe it should just be hmac instead? spt From yaronf.ietf@gmail.com Wed Aug 25 11:30:25 2010 Return-Path: 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 6599C3A6971; Wed, 25 Aug 2010 11:30:24 -0700 (PDT) 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 rNZkjfc+aLsz; Wed, 25 Aug 2010 11:30:21 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 0CE253A6948; Wed, 25 Aug 2010 11:30:19 -0700 (PDT) Received: by fxm18 with SMTP id 18so629786fxm.31 for ; Wed, 25 Aug 2010 11:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QUMsEZCs7bCLXfkKtFeccqAHJjt/MXkM9hsJXjBXabw=; b=aUAAL7kGu961UOAC+piIsNymBCFjqsQpgqXLCQykAXLhChZI04p059WOp2hhwUIioJ QRuRw4RhKxPKTd+9LnWxkLzwUM8jy1nrikLALBf78Rlkfm/G2o04mf2ln0hnQDPJfn5y tkyPqsyx4t653Sw1bY7lsSlgKcibuCXP0CK0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=RTFZL4DmrsCp9mZ8FLbmSLtLZNBFURz9dNLlKUkQRWVPcuypbgQAMLAZz0fJPXcLK2 xn1eTq/ZPlN6opIj5nsm+1Cj5r6oJA5V0XyO/aqd9xFbHa0jhwz0cW0hYpqY/+GjNHQV mRzFCcBa1RgFq+B4kBjcBU21lmwKEf1IcKi1Q= Received: by 10.223.107.211 with SMTP id c19mr8033993fap.20.1282761052005; Wed, 25 Aug 2010 11:30:52 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-177-17-31.red.bezeqint.net [79.177.17.31]) by mx.google.com with ESMTPS id r8sm847833faq.10.2010.08.25.11.30.48 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Aug 2010 11:30:49 -0700 (PDT) Message-ID: <4C756156.3060700@gmail.com> Date: Wed, 25 Aug 2010 21:30:46 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Sean Turner References: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> <4C755E4C.3060907@ieca.com> In-Reply-To: <4C755E4C.3060907@ieca.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-sheffer-emu-eap-eke@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-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: , X-List-Received-Date: Wed, 25 Aug 2010 18:30:25 -0000 It should in fact be MAC. But this issue depends on Brian's (and Dan Harkins's) bigger issue, which we haven't resolved yet. Thanks, Yaron On 08/25/2010 09:17 PM, Sean Turner wrote: > Brian Weis wrote: > > snip > >> 2. As far as I can tell, the definition of "kmac" is new to this I-D, >> which I found a bit confusing. It's really just a MAC, so I think it >> would be clearer to just call it a mac(). > > Maybe it should just be hmac instead? > > spt > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From jari.arkko@piuha.net Wed Aug 25 22:20:25 2010 Return-Path: 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 6E22C3A6A6A; Wed, 25 Aug 2010 22:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 gCinq8452Nql; Wed, 25 Aug 2010 22:20:23 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 92FD83A690D; Wed, 25 Aug 2010 22:20:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 208E22CC34; Thu, 26 Aug 2010 08:20:51 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aePgvxTtXmfv; Thu, 26 Aug 2010 08:20:50 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 81D442CC32; Thu, 26 Aug 2010 08:20:48 +0300 (EEST) Message-ID: <4C75F9B2.4070201@piuha.net> Date: Thu, 26 Aug 2010 01:20:50 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, draft-ietf-mif-problem-statement.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mif-problem-statement-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: , X-List-Received-Date: Thu, 26 Aug 2010 05:20:25 -0000 Joe, Thanks for your review! > 1) Lower layer authentication and encryption > > It's possible that some interfaces may have link layer or IP layer > encryption and authentication. Its possible that this characteristic > might be used in determining how configuration parameters are processed. > Some connection managers may already do this to a certain extent. I > think this should be listed as a consideration in the appropriate > sections of the document (3.1, 3.6,5) > This seems reasonable. Authors, can you suggest some text and update the draft? > 2) I think the security considerations can be expanded > > It discusses that information may be leaked from one network to another > which seems to be talking about generic data. This is true, but it > seems that would be worthwhile to talk specifically about the > information discussed in the document. For example it seems that it is > at least possible for one interface to send configuration parameters > that will cause a denial of service on another interface. It may also > be possible for one host to set configuration parameters which cause > certain traffic to be forwarded to an attacker. > OK. > The last paragraph is also not very clear. What I think you are trying > to say is that the information that is used by the connection manager > may be vulnerable to spoofing and forgery if it is unprotected. In > general its not possible to protect this information in all cases, so it > is not clear what you are recommending. > I agree that configuration information is unlikely to be fully secured, at least if "secured" means communications security or authentication. Here's what I would say in that paragraph: Additional security concerns raise up when information is provided to the host so that it could make a more intelligent decision (e.g. provide selection policies to the connection manager). This additional information should be protected in some manner. => Additional security concerns are raised by possible future mechanisms that provide additional information to the host so that it can make a more intelligent decision with regards to the issues discussed in this document. Such future mechanisms may themselves be vulnerable and may not be easy to protect in the general case. Jari From lars.eggert@nokia.com Thu Aug 26 10:16:59 2010 Return-Path: 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 F0F9A3A68DA; Thu, 26 Aug 2010 10:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=-2.144, BAYES_20=-0.74, 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 tWzNQhln7FSo; Thu, 26 Aug 2010 10:16:56 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 5256A3A6ACE; Thu, 26 Aug 2010 10:16:56 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7QHDEnf021025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 20:13:14 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-38--406847850; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Thu, 26 Aug 2010 20:17:09 +0300 Message-Id: <8B3DD996-10E8-431A-90A6-222804931E08@nokia.com> References: To: Catherine Meadows X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Cc: "draft-ietf-tcpm-tcp-lcd.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-lcd-02 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: , X-List-Received-Date: Thu, 26 Aug 2010 17:16:59 -0000 --Apple-Mail-38--406847850 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, authors, please respond to the point Catherine raises. (Catherine, a few comments from my side are included below.) On 2010-8-24, at 1:28, Catherine Meadows 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. >=20 > This document proposes an algorithm to make TCP more robust to long = connectivity > disruptions. Currently TCP has no way of distinguishing disruptions = due to connectivity > loss from disruptions due to congestion. Thus, TCP will back off = when faced with connectivity > loss, which will lead to further delays. The proposed algorithm uses = the ICMP destination unreachable > messages as indications of a connectivity disruption, and alters the = behavior of TCP accordingly. >=20 > My impression from reading this draft is that the behavior and utility = of this algorithm will depend on > further research and experimentation. There are a number of = situations in which it will still be possible > to confuse congestion and long connectivity disruptions that may need = further exploration. The authors of the document do a good job of = pointing > these out, but I would have liked to have seen more evidence that the = solutions recommended are the optimal > ones, and under what situations. The goal of this mechanism is not to be optimal (TCP as a whole is not = trying to be optimal). The goal is to improve things in many cases and = not cause harm in realistic all cases. > This is especially the case for the security issues, although it is = not > limited to those. For example, in the discussion of probing frequency = in Section 5.4 the authors make a claim > that in their belief the approach of their algorithm is preferable to = others that would give higher probing > frequency, but they need to provide more evidence to back this up. I think it is fine for an Experimental document to state a belief and = ask people to verify it with experiments. For a standards-track = document, yes, we'd absolutely like to see which one is the one to pick. > The security considerations section itself is rather sketchy, and = doesn't support that authors' assertions > that the algorithm is "considered to be secure." The greatest = security threat posed by this > algorithm is that an attacker could exploit it to persuade a TCP = sender that communication problems > due to congestion are actually due to a connectivity problem, leading = the sender to further contribute to the > congestion. Remember that this mechanism only makes a difference during = timeout-based loss recovery, i.e., when TCP at most sends a packet or = two over often many seconds. And even when it fires, it doesn't result = in a flood of packets, all it results in is that a slow-start restart = will be attempted earlier than without this mechanism. So the potential = for harm is really low. > However, the authors mention only one possible attack: forging ICMP = destination unreachable > messages, which they present only as an "example" of an attack. It's presented of an example where even if the attacked could pull it = off, the mechanism is still unaffected.=20 > I would recommend a more complete > discussion, considering each of the potential ambiguity cases = discussed in the document, and discussing > how an attacker could exploit them and how such exploitation could be = prevented or mitigated. You might > also want to discuss the opposite problem: how an attacker could = convince a sender that a connectivity > problem is a congestion problem. This is less serious, at least for = the moment, since in the current > situation that is exactly what happens, but it could be more of a = threat further down the line if people come > to rely more on this ability to disambiguate. If the authors can think of any other attacks, they should absolutely = include them, but since ICMPs are the only signal the mechanism reacts = to, generating fake ones or suppressing real ones are pretty much the = only attack angles I can think of. Lars >=20 >=20 > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: = catherine.meadows@nrl.navy.mil >=20 Lars --Apple-Mail-38--406847850 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNjE3 MTcxMFowIwYJKoZIhvcNAQkEMRYEFPRmwBC5P6fqZSmAntDVzPFUQyAhMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAC172m1JeK2JDjAI1lZ87nQ0yeGO+lJd81NLAp/l8JCuXb5VtdWj CeW3rNWef3cruMvQoisLmHa3GPj8y9bx+eCselq/1p3PMBJkDWQYSX6xRTlgVG3cJg69GbLCkMOE SkxYGmq+g7n9K3O8U0GcC2MgLxqaL2SdtuMfDnyvzrED/AbeRpRMwuiIToDA3L9t6YarZybfYdU8 4Kr73qZzU13VstopLXipzR2AIKYt8017WR+fJ7g+92oD69W+KSiJ3JZzz+uoO6gAHCh+vf17yaKP oa2a7YQEsMd23knDuOqVqbUWTdEzjIFoHKgDvM//OCbArVv54/bg4PqIjZaF8U8AAAAAAAA= --Apple-Mail-38--406847850-- From new-work-bounces@ietf.org Wed Aug 25 12:04:19 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5283A68C7; Wed, 25 Aug 2010 12:04:19 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDB83A68F6 for ; Wed, 25 Aug 2010 12:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=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 HYdK5qgGwvN3 for ; Wed, 25 Aug 2010 12:04:17 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id C9C173A68C7 for ; Wed, 25 Aug 2010 12:04:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OoLHF-00071j-Vj; Wed, 25 Aug 2010 15:04:50 -0400 Message-Id: <34FF0B74-77F7-40E9-9F25-42A8E366FB86@w3.org> From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 14:04:49 -0500 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 27 Aug 2010 11:05:47 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Touch Interface Working Group (until 2010-09-23) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 19:04:19 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Touch Interface Working Group: http://www.w3.org/2010/07/touchinterface-charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2010-09-23 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Doug Schepers, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2006/rwc/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Thu Aug 26 11:34:43 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688A03A68BF; Thu, 26 Aug 2010 11:34:43 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319693A68BF for ; Thu, 26 Aug 2010 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.092 X-Spam-Level: X-Spam-Status: No, score=-8.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 B0S12UX6STC3 for ; Thu, 26 Aug 2010 11:34:39 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 8B3313A6826 for ; Thu, 26 Aug 2010 11:34:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OohI6-0007k5-3n; Thu, 26 Aug 2010 14:35:10 -0400 Message-Id: <82C464B0-4ADB-4A2C-8CAD-615F8B048904@w3.org> From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Aug 2010 13:35:09 -0500 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 27 Aug 2010 11:05:47 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Points of Interest Working Group (until 2010-09-24) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 18:34:43 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Ubiquitous Web Applications Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Points of Interest Working Group: http://www.w3.org/2010/POI/charter/ As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2010-09-24 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Matt Womer, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2007/uwa/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From catherine.meadows@nrl.navy.mil Fri Aug 27 13:01:57 2010 Return-Path: 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 9EA383A687B; Fri, 27 Aug 2010 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, 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 0Z7ugrgqVqzQ; Fri, 27 Aug 2010 13:01:55 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id BFE223A6857; Fri, 27 Aug 2010 13:01:55 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id o7RK2Pfg014419; Fri, 27 Aug 2010 16:02:26 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id o7RK2Ld5005439; Fri, 27 Aug 2010 16:02:25 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010082716022408406 ; Fri, 27 Aug 2010 16:02:24 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-2--310168919 From: Catherine Meadows In-Reply-To: <8B3DD996-10E8-431A-90A6-222804931E08@nokia.com> Date: Fri, 27 Aug 2010 16:08:28 -0400 Message-Id: References: <8B3DD996-10E8-431A-90A6-222804931E08@nokia.com> To: Lars Eggert X-Mailer: Apple Mail (2.1081) Cc: "draft-ietf-tcpm-tcp-lcd.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-lcd-02 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: , X-List-Received-Date: Fri, 27 Aug 2010 20:01:57 -0000 --Apple-Mail-2--310168919 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Lars: Thanks for your comments. I perhaps did not appreciate completely the = significance of this being an experimental ID. Still, I think that the security considerations section could use some = improving. Simply presenting one example of an attack without adequate motivation = as to why this attack is the most relevant one merely confuses the reader (or at least = that was the effect on me). I would suggest that the authors add more motivation such as you give in = your email, namely that the only behavior change required by this protocol is in the = response to ICMP messages, and thus that the only way an attacker could cause a = change in behavior of the protocol is by either causing more or few ICMP messages to be = generated than would have occurred otherwise. Then you could discuss the goals of the attacker; = I think it is reasonable to assume, as the authors do, that the only possible goal is denial of service, = since the ICMP messages are not used for authentication or to control access to sensitive information. But = it wouldn't hurt to point this out. Then you could discuss the contribution of spurious or suppressed ICMP = messages to a denial of service attack (minimal). You could then discuss the problem of spoofing or suppressing ICMP = messages, although this may not be necessary if the effect is minimal. At any case, this would give you a more = convincing argument that the protocol does not introduce any security vulnerabilities, and it doesn't require much more than = bringing forward and tying together information that is already in the ID. Cathy On Aug 26, 2010, at 1:17 PM, Lars Eggert wrote: > Hi, authors, >=20 > please respond to the point Catherine raises. >=20 > (Catherine, a few comments from my side are included below.) >=20 >=20 > On 2010-8-24, at 1:28, Catherine Meadows 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. >>=20 >> This document proposes an algorithm to make TCP more robust to long = connectivity >> disruptions. Currently TCP has no way of distinguishing disruptions = due to connectivity >> loss from disruptions due to congestion. Thus, TCP will back off = when faced with connectivity >> loss, which will lead to further delays. The proposed algorithm uses = the ICMP destination unreachable >> messages as indications of a connectivity disruption, and alters the = behavior of TCP accordingly. >>=20 >> My impression from reading this draft is that the behavior and = utility of this algorithm will depend on >> further research and experimentation. There are a number of = situations in which it will still be possible >> to confuse congestion and long connectivity disruptions that may need = further exploration. The authors of the document do a good job of = pointing >> these out, but I would have liked to have seen more evidence that the = solutions recommended are the optimal >> ones, and under what situations. >=20 > The goal of this mechanism is not to be optimal (TCP as a whole is not = trying to be optimal). The goal is to improve things in many cases and = not cause harm in realistic all cases. >=20 >> This is especially the case for the security issues, although it is = not >> limited to those. For example, in the discussion of probing = frequency in Section 5.4 the authors make a claim >> that in their belief the approach of their algorithm is preferable to = others that would give higher probing >> frequency, but they need to provide more evidence to back this up. >=20 > I think it is fine for an Experimental document to state a belief and = ask people to verify it with experiments. For a standards-track = document, yes, we'd absolutely like to see which one is the one to pick. >=20 >> The security considerations section itself is rather sketchy, and = doesn't support that authors' assertions >> that the algorithm is "considered to be secure." The greatest = security threat posed by this >> algorithm is that an attacker could exploit it to persuade a TCP = sender that communication problems >> due to congestion are actually due to a connectivity problem, leading = the sender to further contribute to the >> congestion. >=20 > Remember that this mechanism only makes a difference during = timeout-based loss recovery, i.e., when TCP at most sends a packet or = two over often many seconds. And even when it fires, it doesn't result = in a flood of packets, all it results in is that a slow-start restart = will be attempted earlier than without this mechanism. So the potential = for harm is really low. >=20 >> However, the authors mention only one possible attack: forging ICMP = destination unreachable >> messages, which they present only as an "example" of an attack. >=20 > It's presented of an example where even if the attacked could pull it = off, the mechanism is still unaffected.=20 >=20 >> I would recommend a more complete >> discussion, considering each of the potential ambiguity cases = discussed in the document, and discussing >> how an attacker could exploit them and how such exploitation could be = prevented or mitigated. You might >> also want to discuss the opposite problem: how an attacker could = convince a sender that a connectivity >> problem is a congestion problem. This is less serious, at least for = the moment, since in the current >> situation that is exactly what happens, but it could be more of a = threat further down the line if people come >> to rely more on this ability to disambiguate. >=20 > If the authors can think of any other attacks, they should absolutely = include them, but since ICMPs are the only signal the mechanism reacts = to, generating fake ones or suppressing real ones are pretty much the = only attack angles I can think of. >=20 > Lars >=20 >=20 >=20 >>=20 >>=20 >> Catherine Meadows >> Naval Research Laboratory >> Code 5543 >> 4555 Overlook Ave., S.W. >> Washington DC, 20375 >> phone: 202-767-3490 >> fax: 202-404-7942 >> email: = catherine.meadows@nrl.navy.mil >>=20 >=20 > Lars Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-2--310168919 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Lars:

Thanks for your comments.  I perhaps did = not appreciate completely the significance of this being an experimental = ID.

Still, I think that the security = considerations section could use some improving.
Simply = presenting one example of an attack without adequate motivation as to = why this
attack is the most relevant one merely confuses the = reader (or at least that was the effect on me).
I would = suggest that the authors add more motivation such as you give in your = email,
namely that the only behavior change required by this = protocol is in the response
to ICMP messages, and thus that = the only way an attacker could cause a change in behavior
of = the protocol is by either causing more or few ICMP messages to be = generated than would have
occurred otherwise.  Then you = could discuss the goals of the attacker;  I think it is reasonable = to assume,
as the authors do, that the only possible goal is = denial of service, since the ICMP messages are not used
for = authentication or to control access to sensitive information.  But = it wouldn't hurt to point this out.
Then you could discuss the = contribution of spurious or suppressed ICMP messages to a denial of = service attack (minimal).
You could then discuss the problem = of spoofing or suppressing ICMP messages, although this may not be = necessary
if the effect is minimal.   At any case, =  this would give you a more convincing argument that the protocol = does not introduce
any security vulnerabilities, and it = doesn't require much more than bringing forward and tying together = information that is
already in the = ID.

Cathy

On = Aug 26, 2010, at 1:17 PM, Lars Eggert wrote:

Hi, = authors,

please respond to the point Catherine = raises.

(Catherine, a few comments from my side are included = below.)


On 2010-8-24, at 1:28, Catherine Meadows = 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.

This document = proposes an algorithm to make TCP more robust to long = connectivity
disruptions. =  Currently TCP has no way of distinguishing disruptions due to = connectivity
loss from = disruptions due to congestion.   Thus, TCP will back off when = faced with connectivity
loss, = which will lead to further delays.  The proposed algorithm uses the = ICMP destination unreachable
messages as indications of a connectivity disruption, and = alters the behavior of TCP accordingly.

My impression = from reading this draft is that the behavior and utility of this = algorithm will depend on
further= research and experimentation.  There are a number of situations in = which it will still be possible
to confuse congestion and long connectivity disruptions = that may need further exploration.  The authors of the document do = a good job of pointing
these = out, but I would have liked to have seen more evidence that the = solutions recommended are the optimal
ones, and under what situations.

The = goal of this mechanism is not to be optimal (TCP as a whole is not = trying to be optimal). The goal is to improve things in many cases and = not cause harm in realistic all cases.

= This is especially the case for the security issues, although it is = not
limited to those. =  For example, in the discussion of probing frequency in Section 5.4 = the authors make a claim
that = in their belief the approach of their algorithm is preferable to others = that would give higher probing
frequency, but they need to provide more evidence to back = this up.

I think it is fine for an Experimental = document to state a belief and ask people to verify it with experiments. = For a standards-track document, yes, we'd absolutely like to see which = one is the one to pick.

The security = considerations section itself is rather sketchy, and doesn't support = that authors' assertions
that = the algorithm is "considered to be secure."  The greatest security = threat posed by this
algorithm = is that an attacker could exploit it to persuade a TCP sender that = communication problems
due to = congestion are actually due to a connectivity problem, leading the = sender to further contribute to the
congestion.

Remember that this = mechanism only makes a difference during timeout-based loss recovery, = i.e., when TCP at most sends a packet or two over often many seconds. = And even when it fires, it doesn't result in a flood of packets, all it = results in is that a slow-start restart will be attempted earlier than = without this mechanism. So the potential for harm is really = low.

However, the authors mention only = one possible attack: forging ICMP destination = unreachable
messages, which = they present only as an "example" of an attack.

It's = presented of an example where even if the attacked could pull it off, = the mechanism is still unaffected.

=  I would recommend a more complete
discussion, considering each of the potential ambiguity = cases discussed in the document, and = discussing
how an attacker = could exploit them and how such exploitation could be prevented or = mitigated.  You might
also = want to discuss the opposite problem: how an attacker could convince a = sender that a connectivity
problem is a congestion problem.  This is less = serious, at least for the moment, since in the = current
situation that is = exactly what happens, but it could be more of a threat further down the = line if people come
to rely = more on this ability to disambiguate.

If the authors = can think of any other attacks, they should absolutely include them, but = since ICMPs are the only signal the mechanism reacts to, generating fake = ones or suppressing real ones are pretty much the only attack angles I = can think of.

Lars





Catherine = Meadows
Naval Research = Laboratory
Code = 5543
4555 Overlook Ave., = S.W.
Washington DC, = 20375
phone: = 202-767-3490
fax: = 202-404-7942
email: = catherine.meadows@nrl.navy.mil<mailto:catherine.meadows@nr= l.navy.mil>


Lars

Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail-2--310168919-- From hallam@gmail.com Sat Aug 28 19:41:12 2010 Return-Path: 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 D4C743A6922 for ; Sat, 28 Aug 2010 19:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_05=-1.11] 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 O9AF0iVIfcTe for ; Sat, 28 Aug 2010 19:41:11 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8BC203A68F8 for ; Sat, 28 Aug 2010 19:41:11 -0700 (PDT) Received: by iwn3 with SMTP id 3so4193111iwn.31 for ; Sat, 28 Aug 2010 19:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=sH18ho8JFsdokY1AnSY4K8FxKnTx7scAQ0m9cX8Bbrk=; b=pZiWw2rhYV4McYL1bigpRg3492eyQLjufTk51OxesW2XCsHMvdGwZpIJT6Ohj5QOEK Y8+v0/uGTHEifEUrvvv2Lx7pczm7CeWbsNDXe2a5LgDcXKoaaHMnswslsEw3ndXi1R29 yw7Cso/oIelOdZ6gpxth9i8RCmCVHWFRzj180= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RTx4BwcUG64FLI4zFYJNFMH2+GgMEmrEi7UogoM9FHaBq+Fi/hvcrPnEu3ou6gPOsx XWXasuA8w0TNDuNv6eLY25d2kCM//slg54qtoXSGnrBEwm5oOBGF9Zo5RajZXk9wa9vd jGithATAu8k+HKPfai8oH9UkWgaEGhIOvxa10= MIME-Version: 1.0 Received: by 10.231.145.16 with SMTP id b16mr3160171ibv.198.1283049703018; Sat, 28 Aug 2010 19:41:43 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Sat, 28 Aug 2010 19:41:42 -0700 (PDT) Date: Sat, 28 Aug 2010 22:41:42 -0400 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, Richard Barnes , mlepinski@bbn.com, acooper@cdt.org, jmorris@cdt.org, Hannes Tschofenig , Henning Schulzrinne Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR Review of draft-ietf-geopriv-arch-02 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: , X-List-Received-Date: Sun, 29 Aug 2010 02:41:13 -0000 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 sets out architectural considerations for location and location privacy systems. As such it is essentially an extended set of security considerations. The document is very thorough and describes both the problem and generalized approaches addressing requirements that arise. In my opinion it is suitable for publication in its current form. I have no particular issues with the document except to note the following: 1) Legal risks of collecting location information. You can't lose what you don't have. Sites that collect and store credit card numbers expose themselves to the risk of penalties should they be compromised. Sites that collect location information they don't need may be opening themselves to unnecessary liability. Implementing privacy architectures is thus not merely a matter of compliance, it is potentially a means of mitigating liability risk. 2) Unintended location information GPS and similar devices are designed to collect location information, but many Internet technologies leak information that has a high correlation with position. Even an IP address can be tracked down to a street level address in many instances. The issues raised in this document are thus of wider application than technologies intended to provide location information. -- Website: http://hallambaker.com/ From weiler+secdir@watson.org Mon Aug 30 11:04:31 2010 Return-Path: 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 B8D363A6A14 for ; Mon, 30 Aug 2010 11:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 44HtaNafBFZM for ; Mon, 30 Aug 2010 11:04:30 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id AA35D3A6A13 for ; Mon, 30 Aug 2010 11:04:30 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o7UI50Ip052894 for ; Mon, 30 Aug 2010 14:05:00 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o7UI507L052891 for ; Mon, 30 Aug 2010 14:05:00 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 30 Aug 2010 14:05:00 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 30 Aug 2010 14:05:00 -0400 (EDT) Subject: [secdir] Assignments 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: , X-List-Received-Date: Mon, 30 Aug 2010 18:04:31 -0000 Kurt Zeilenga is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2010-09-09 Reviewer LC end Draft Derek Atkins TR2010-07-09 draft-ietf-avt-forward-shifted-red-06 Julien Laganier T 2010-08-31 draft-ietf-nsis-nslp-auth-06 Hilarie Orman T 2010-08-16 draft-ietf-calsify-rfc2447bis-10 Eric Rescorla T 2010-09-06 draft-das-mipshop-andsf-dhcp-options-04 Brian Weis T 2010-07-16 draft-daboo-srv-caldav-07 Glen Zorn T 2010-07-26 draft-cakulev-mikey-ibake-02 For telechat 2010-09-23 Reviewer LC end Draft Tina TSOU T 2010-09-01 draft-ietf-roll-rpl-11 Last calls and special requests: Reviewer LC end Draft Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-08 Barry Leiba 2010-08-12 draft-saintandre-tls-server-id-check-09 David McGrew - draft-ietf-ecrit-framework-11 David McGrew 2010-08-05 draft-ietf-pce-manageability-requirements-10 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Vincent Roca 2010-08-23 draft-ietf-fecframe-framework-09 Carl Wallace 2010-09-13 draft-josefsson-pbkdf2-test-vectors-05 Sam Weiler 2010-09-03 draft-ietf-opsec-igp-crypto-requirements-00 Brian Weis 2010-09-07 draft-ietf-netmod-dsdl-map-07 Nico Williams 2010-09-10 draft-ietf-fecframe-sdp-elements-08 Tom Yu 2010-09-27 draft-gundavelli-v6ops-l2-unicast-04 From lars.eggert@nokia.com Tue Aug 31 01:57:01 2010 Return-Path: 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 735713A69F3; Tue, 31 Aug 2010 01:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=-2.366, BAYES_40=-0.185, 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 KE9-31i9bnTD; Tue, 31 Aug 2010 01:57:00 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 58A383A69FE; Tue, 31 Aug 2010 01:56:58 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7V8vRLN000494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2010 11:57:27 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-50--4842855; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Tue, 31 Aug 2010 11:57:14 +0300 Message-Id: <4FE24FB3-14CA-40A4-A902-531176B36950@nokia.com> References: <8B3DD996-10E8-431A-90A6-222804931E08@nokia.com> To: Catherine Meadows X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Cc: "draft-ietf-tcpm-tcp-lcd.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-lcd-02 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: , X-List-Received-Date: Tue, 31 Aug 2010 08:57:01 -0000 --Apple-Mail-50--4842855 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, this is a good suggestion. Authors, would you work this into the text? Lars On 2010-8-27, at 23:08, Catherine Meadows wrote: > Hi Lars: >=20 > Thanks for your comments. I perhaps did not appreciate completely the = significance of this being an experimental ID. >=20 > Still, I think that the security considerations section could use some = improving. > Simply presenting one example of an attack without adequate motivation = as to why this > attack is the most relevant one merely confuses the reader (or at = least that was the effect on me). > I would suggest that the authors add more motivation such as you give = in your email, > namely that the only behavior change required by this protocol is in = the response > to ICMP messages, and thus that the only way an attacker could cause a = change in behavior > of the protocol is by either causing more or few ICMP messages to be = generated than would have > occurred otherwise. Then you could discuss the goals of the attacker; = I think it is reasonable to assume, > as the authors do, that the only possible goal is denial of service, = since the ICMP messages are not used > for authentication or to control access to sensitive information. But = it wouldn't hurt to point this out. > Then you could discuss the contribution of spurious or suppressed ICMP = messages to a denial of service attack (minimal). > You could then discuss the problem of spoofing or suppressing ICMP = messages, although this may not be necessary > if the effect is minimal. At any case, this would give you a more = convincing argument that the protocol does not introduce > any security vulnerabilities, and it doesn't require much more than = bringing forward and tying together information that is > already in the ID. >=20 > Cathy >=20 > On Aug 26, 2010, at 1:17 PM, Lars Eggert wrote: >=20 >> Hi, authors, >>=20 >> please respond to the point Catherine raises. >>=20 >> (Catherine, a few comments from my side are included below.) >>=20 >>=20 >> On 2010-8-24, at 1:28, Catherine Meadows 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. >>>=20 >>> This document proposes an algorithm to make TCP more robust to long = connectivity >>> disruptions. Currently TCP has no way of distinguishing disruptions = due to connectivity >>> loss from disruptions due to congestion. Thus, TCP will back off = when faced with connectivity >>> loss, which will lead to further delays. The proposed algorithm = uses the ICMP destination unreachable >>> messages as indications of a connectivity disruption, and alters the = behavior of TCP accordingly. >>>=20 >>> My impression from reading this draft is that the behavior and = utility of this algorithm will depend on >>> further research and experimentation. There are a number of = situations in which it will still be possible >>> to confuse congestion and long connectivity disruptions that may = need further exploration. The authors of the document do a good job of = pointing >>> these out, but I would have liked to have seen more evidence that = the solutions recommended are the optimal >>> ones, and under what situations. >>=20 >> The goal of this mechanism is not to be optimal (TCP as a whole is = not trying to be optimal). The goal is to improve things in many cases = and not cause harm in realistic all cases. >>=20 >>> This is especially the case for the security issues, although it is = not >>> limited to those. For example, in the discussion of probing = frequency in Section 5.4 the authors make a claim >>> that in their belief the approach of their algorithm is preferable = to others that would give higher probing >>> frequency, but they need to provide more evidence to back this up. >>=20 >> I think it is fine for an Experimental document to state a belief and = ask people to verify it with experiments. For a standards-track = document, yes, we'd absolutely like to see which one is the one to pick. >>=20 >>> The security considerations section itself is rather sketchy, and = doesn't support that authors' assertions >>> that the algorithm is "considered to be secure." The greatest = security threat posed by this >>> algorithm is that an attacker could exploit it to persuade a TCP = sender that communication problems >>> due to congestion are actually due to a connectivity problem, = leading the sender to further contribute to the >>> congestion. >>=20 >> Remember that this mechanism only makes a difference during = timeout-based loss recovery, i.e., when TCP at most sends a packet or = two over often many seconds. And even when it fires, it doesn't result = in a flood of packets, all it results in is that a slow-start restart = will be attempted earlier than without this mechanism. So the potential = for harm is really low. >>=20 >>> However, the authors mention only one possible attack: forging ICMP = destination unreachable >>> messages, which they present only as an "example" of an attack. >>=20 >> It's presented of an example where even if the attacked could pull it = off, the mechanism is still unaffected.=20 >>=20 >>> I would recommend a more complete >>> discussion, considering each of the potential ambiguity cases = discussed in the document, and discussing >>> how an attacker could exploit them and how such exploitation could = be prevented or mitigated. You might >>> also want to discuss the opposite problem: how an attacker could = convince a sender that a connectivity >>> problem is a congestion problem. This is less serious, at least for = the moment, since in the current >>> situation that is exactly what happens, but it could be more of a = threat further down the line if people come >>> to rely more on this ability to disambiguate. >>=20 >> If the authors can think of any other attacks, they should absolutely = include them, but since ICMPs are the only signal the mechanism reacts = to, generating fake ones or suppressing real ones are pretty much the = only attack angles I can think of. >>=20 >> Lars >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> Catherine Meadows >>> Naval Research Laboratory >>> Code 5543 >>> 4555 Overlook Ave., S.W. >>> Washington DC, 20375 >>> phone: 202-767-3490 >>> fax: 202-404-7942 >>> email: = catherine.meadows@nrl.navy.mil >>>=20 >>=20 >> Lars >=20 > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil >=20 --Apple-Mail-50--4842855 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgzMTA4 NTcxNVowIwYJKoZIhvcNAQkEMRYEFDgM892t+Q/QwKDtRhD05tRkPGcCMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAGrnVtuigfcDVvtMNSGdzPAqqc7HvooH2DuMVpKOW2T38kfwq36N LL1ibsl0fSY03TtSHQaVcOSCtzq7k3+M6LyOhf3FwbEhsMAqrD7uHxTwT/EmQJ27bY84vT8WZItC Wf4WlLeb17bv6IdniLcdXMotHv42I7YimDEufXnBxRX+nJs0P8DBjLd6LBpjw9z5Vzl7XfS25rmr zaVjZZZJvwasOPI8PXw0f6QpGWSr8RTDjXnGdsXYTuvYY3YtKhUZ2f63W8kv1zdqwa/jpyvQGVHa XnQu+uvesz+/BSt35J1f5Lf+9Go0UrJ4iFQwCZZ2cG9JM3i9v7gbJWYV24v+yc0AAAAAAAA= --Apple-Mail-50--4842855-- From christer.holmberg@ericsson.com Tue Aug 31 10:38:53 2010 Return-Path: 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 97AE83A6A49; Tue, 31 Aug 2010 10:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-2.389, BAYES_50=0.001, J_CHICKENPOX_14=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 4gB3fgi2P+0q; Tue, 31 Aug 2010 10:38:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4FE603A699A; Tue, 31 Aug 2010 10:38:50 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-72-4c7d3e482612 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 05.79.06895.84E3D7C4; Tue, 31 Aug 2010 19:39:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 31 Aug 2010 19:39:19 +0200 From: Christer Holmberg To: Ted Hardie , "Richard L. Barnes" , "secdir@ietf.org" , "iesg@ietf.org" , The IETF , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" Date: Tue, 31 Aug 2010 19:39:19 +0200 Thread-Topic: secdir review of draft-ietf-simple-msrp-sessmatch Thread-Index: AQHLSTNw/bFzewQQNEaEXcgAxxQKEQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ben@estacado.net" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch 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: , X-List-Received-Date: Tue, 31 Aug 2010 17:38:53 -0000 Hi, The purpose of this e-mail is to address the secdir comments given by Richa= rd Barnes and Ted Hardie. Due to summer vacations, standardization meetings etc it took a while to put the e-mail together, and we appologise for that. GENERAL =3D=3D=3D=3D=3D=3D=3D First, the draft does NOT propose any changes to the TLS authentication procedures =96 that will be clarified. The changes are only related to the procedure for matching an incoming MSRP message to an MSRP session that has been negotiated using SDP =96 once any TLS authentication procedure has already taken place. So, in case of TLS and name based authentication, if an SBC/ALG modifies the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is the curren= t behavior, and sessmatch doesn=92t change that. We understand that this fact needs to be clearly indicated in the draft. Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs and SIP aware firewalls can be in the SIP signaling path without acting as MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP relays the SBC/ALG needs to act as MSRP B2BUA, as today. Sessmatch aims to extend the usability of MSRP peer to peer communication t= o scenarios where simple ALGs/SBCs are used, and at least in our experience customer interest for standard MSRP has grown (from more or less zero) dramatically due to sessmatch. And, OMA, which previously used a *non-stand= ard* version of MSRP (with no interoperability with standard MSRP), has also agr= eed to switch to sessmatch (even if it required a number of changes in their specifications). Second, the intention of sessmatch is not to modify the MSRP URI matching r= ules, but rather to not use MSRP URI matching for session matching. Please also note that when we talk about SBCs/ALGs, we refer to entities th= at normally do NOT have the capability to act as MSRP B2BUAs. We will comment the individual comments based on the assumptions above. Comments from Richard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >I have reviewed this document as part of the security directorate's ongoin= g >effort to review all IETF documents being processed by the IESG. These >comments were written primarily for the benefit of the security area direc= tors. >Document editors and WG chairs should treat these comments just like any o= ther >last call comments. > >This document changes the URI matching algorithm used in MSRP. MSRP sessi= ons >are typically initiated using SDP bodies in SIP. These SDP >bodies contain MSRP URIs that the peers use to contact each other. >When one peer receives a request to initiate a session, he verifies that t= he >URI being requested is one that he initiated in SDP, thereby using the URI= as a >shared secret to authenticate that the originator of the session actually >received the SDP body in question. > >According to the current SDP specification, this comparison is performed o= ver >the whole URI; this document restricts the comparison to the "session-id" >component, omitting the host, port, and transport components. The goal of= the >document is to facilitate a certain class of man-in-the-middle attack, nam= ely >to allow a signaling intermediary to insert a media intermediary. The >restriction on the URI comparison is needed in order for the media interme= diary >not to have to modify URIs in MSRP packets to reflect the modifications to= URIs >in SDP bodies performed to redirect traffic through the media intermediary= . When an MSRP UA receives an MSRP packet it performs msrp session matching i= n order to verify that the msrp packet belongs to an existing SDP negotiated msrp s= ession at the UA. RFC4975 prescribes that URI matching should be used for session = matching. We argue that the namespace scoping of the session-id values that use of UR= I matching brings is unnecessary. The 80-bit randomness of the session-id and the fact= that it was the UA itself that decided on the session-id value and can ensure that = it is unique within the UA makes the session-id sufficiently unique for session m= atching. Sessmatch is not changing the MSRP URI matching algorithm, it is changing t= he session matching algorithm not to use MSRP URI matching. >I have a few significant reservations about this document: > >1) This extension makes it more difficult for MSRP entities to secure thei= r >communications against attackers in the signaling path. The current model >provides a basic integrity protection, in that signaling intermediaries ca= nnot >redirect traffic to an arbitrary third party; they must at least advise th= e >third party about how to modify MSRP packets. The proposed modification wo= uld >remove even this cost. If we do not introduce the sessmatch change then the only alternative for M= SRP connections to be able to be set up when SBCs or SIP aware firewalls are in= the SIP signaling path is for these to introduce MSRP B2BUA support. This is pr= obably not feasible for most SBCs and SIP aware firewalls, and if it actually were feasible then it would mean as big a security problem, or even bigger, than sessmatch. The choice is thus to not use MSRP at all in presence of such de= vices or to introduce sessmatch. Not to fix this probably would mean that use of = MSRP will be marginalized. >2) Moreover, it raises the cost of providing integrity protection to messa= ges, >since Alice must now employ both integrity and confidentiality protections= on >an end-to-end basis; if her messages are only integrity-protected, then a = proxy >can remove the integrity protection and redirect traffic without it being >observable to Alice. > >The document needs to clarify what the impacts are for authentication in s= ecure >modes of MSRP. In particular: >-- The distinction between "self-signed" and "public" certificates is >inappropriate. The proper distinction is between the name-based authentic= ation >in Section 14.2 of RFC 4975 and the fingerprint-based authentication in Se= ction >14.4. We cannot find the terminology =93name-based=94 authentication in RFC 4975.= The RFC talks about TLS authentication using either certificates from well-known certific= ate authorities, or using self-signed certificates together with certificate fi= ngerprints. Having said that, however, we DO agree that the terminology you suggest is = more appropriate than what we have used and we will introduce this terminology a= nd explain it in the Convention section of the sessmatch draft. >-- In either case, changing the host name need not result in an authentica= tion >failure, since the media intermediary can simply authenticate as itself to= both >endpoints, having changed the respective MSRP URIs appropriately. A media intermediary can only do this if it is an MSRP B2BUA, and sessmatch= was introduced just to avoid most SBCs and ALGs having to implement an MSRP B2B= UA in order to allow standard MSRP deployment. >-- There is currently no requirement that an endpoint identity in the To-P= ath >URI matches the endpoint identity authenticated at the TLS layer, because = these >two are required to be the same. This document changes that assumption, a= nd >should note that these two identities can differ. We will explicitly mention this. >The document also precludes any name-based multiplexing, where a single MS= RP >process (single IP address and port) directs requests to different virtual >recipients based on the domain name in the To-Path header. (In analogy to >Host-based multiplexing in HTTP, which is very widely deployed.) Since wit= h >this extension, the domain in the To- Path is completely unpredictable fro= m the >recipient's perspective, it is useless to the recipient. That is correct, but there should be no problem for a single MSRP process (= single IP address and port) to direct requests to different virtual recipients - b= ased on the session-id instead. It is only needed for the different virtual reci= pients to inform the receiver process on which session-ids that are currently nego= tiated instead of informing it on which domain name the virtual recipient shall be associated with. >The document has no backward-compatibility. MSRP implementations that do n= ot >support this extension will not be able to receive MSRP sessions from >implementations that do. In that regard, this document seems more like a n= ew >version of MSRP rather than an update. It is not true that there is no backwards compatibility. If there are no SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem for M= SRP implementations that do not support the sessmatch extension to receive MSRP sessions from implementations that do. MSRP implementations that do not support the sessmatch extension are howeve= r not able to establish MSRP end to end conversations if there are ALGs/SBCs in t= he session path (unless these implement MSRP B2BUA) and sessmatch does not cha= nge this fact =96 it will not work disregarding if the other endpoint supports sessm= atch or not. >>>I also note that the security considerations, in addition to having >>>some fairly disingenuous language about the impact of this change, >>>seems to fail to mention MSRPS URIs and what, if any, impact this >>>would have on them. >> >>There are no impacts to MSRPS URIs. I assumed it would be implicitly >>understood since MSRPS URIs are not mentioned in the draft. >> >>However, we could explicitly make it clear by modifying the first >>sentences of section 5: >> >>"The change of session matching procedure does not impact the >>format of MSRP URIs, disregarding if the "msrp" scheme or the "msrps" sch= eme >>is used. However, MSRP endpoints can only check that the session-id part = of >>the MSRP URI..." > >The conflict here is that with MRSPS authentication, the name in the >certificate is checked against the domain name in the URI, which was OK wh= en >the URI in the message was required to be the same. By allowing the domain >name in the message to change, this draft removes man-in-the-middle protec= tion >from MSRPS. > >The document notes that a SIP MitM can already direct the user to another >destination. However, if the peers use MSRPS with the current authenticat= ion >scheme, the MitM will not be able to be a part of the resulting MSRPS sess= ion, >since he can't authenticate as one of the endpoints. If only the session I= D is >used in comparisons, the MitM can patch himself in by changing the domain = in >the MSRPS URI. (Which actually seems to be the intended use case for this = >draft.) > >So the current document does introduce a new MitM vulnerability to MSRPS. Sessmatch does not change the fact that name based TLS authentication for M= SRPS will fail if an SBC or ALG has modified the hostname value in the MSRP URI = in the SDP a=3Dpath attribute without also acting as MSRP B2BUA. Comments from Ted =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >I join Richard in believing that this document makes changes beyond that w= hich >could be understood as "updating" the MSRP URI scheme processing. > >... > >I also note that the security considerations, in addition to having some f= airly >disingenuous language about the impact of this change, seems to fail to me= ntion >MSRPS URIs and what, if any, impact this would have on them. We will clarify what impacts there are. ------- >>>To highlight one particular aspect, RFC 4975 does not require >>>session-ids to be present, a fact noted both in the ABNF and in this >>>text: >>> >>>4. The session-id part is compared as case sensitive. A URI without >>> a session-id part is never equivalent to one that includes one. >>> >>>A matching scheme which relies on a URI section which is not >>>guaranteed to be present has some interesting problems ahead of it. If >>>this effectively makes their use mandatory, that requires a change to >>>the fundamental ABNF and text. >> >>An MSRP URI in an SDP offer or answer for an MSRP session MUST include a >>session-id part, so I believe the comment is >>based on incorrect assumptions. > >This is not indicated in the URI matching section We will clarify that sessmatch conformant UAs do not use MSRP URI matching = in order to perform MSRP session matching. >>Section 6 of RFC 4975 says: >> >>"The session-id part identifies a particular session of the >>participant. The absence of the session-id >>part indicates a reference to an MSRP host device, but does not refer to = a >>particular session at that device." >> > >The full section from which that quote is taken is: > > The MSRP URI authority field identifies a participant in a particular > MSRP session. If the authority field contains a numeric IP address, > it MUST also contain a port. The session-id part identifies a > particular session of the participant. The absence of the session-id > part indicates a reference to an MSRP host device, but does not refer > to a particular session at that device. A particular value of > session-id is only meaningful in the context of the associated > authority; thus, the authority component can be thought of as > identifying the "authority" governing a namespace for the session-id. > >This proposal changes the concept of a namespace authority present in the = URI >matching section of RFC 4975. I am sorry if my wry reference to this in my >previous message was hard to follow; I should have known better. > >To be more plain, this proposal fundamentally changes the matching semanti= cs of >the URI set out in RFC 4975, by requiring a match on only a portion of the= URI. >At a bare minimum, this would require noting a normative update to section= 6 >and 6.1 of RFC 4975, which this draft does not do. In reality, this is >unlikely to be sufficient, as URI matching semantics do not generally have= the >concept of ignoring the authority in providing a match (at least in my rea= ding >of the RFC 3986 "ladder of comparison" text). That means you'd have to sp= ecial >case the MSRP matching semantics, rather than have the URI be parsed and >compared using a standard library. Sessmatch removes the URI matching as a means to do MSRP session matching, = and replaces it with a pure session-id matching. There is no need to create a n= ew URI scheme that does not re-use the authority component. We believe the min= imum 80-bit randomness of the session-id, together with the fact that the UA its= elf generates the session-id it matches on, to be enough for the session-id to = be unique in the scope of the sessions that are active at the UA. Also, the security of the matching is not particularly decreased, since it = is relatively easy to find out the authority name anyway. >>>I also note that the security considerations, in addition to having >>>some fairly disingenuous language about the impact of this change, >>>seems to fail to mention MSRPS URIs and what, if any, impact this >>>would have on them. >> >>There are no impacts to MSRPS URIs. I assumed it would be implicitly unde= rstood >>since MSRPS URIs are not mentioned in the draft. >> >>However, we could explicitly make it clear by modifying the first sentenc= es of >>section 5: >> >>"The change of session matching procedure does not impact the format of M= SRP >>URIs, disregarding if the "msrp" scheme or the "msrps" scheme is used. >>However, MSRP endpoints can only check that the session-id part of the MS= RP >>URI..." >> >This doesn't seem to me to actually work, based on Richard's comments, unl= ess >what you mean to say is "if MSRPS is in use, nothing in this draft can be >used". That gives you different matching semantics for MSRPS (authority mu= st >be present and must be matched using TLS semantics) vs MSRP (only session-= id is >checked) which is at the very least a violation of the principle of least >surprise (no other foo over TLS protocol works that way that I know of ). Session matching is done when receiving MSRP packets on an already establis= hed TCP or TCP/TLS connection, and there will not be any different session matching= procedure depending on if the connection uses TLS or plain TCP. Regards, Christer From tena@huawei.com Tue Aug 31 20:25:27 2010 Return-Path: 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 78FD73A68E2; Tue, 31 Aug 2010 20:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.91 X-Spam-Level: X-Spam-Status: No, score=-99.91 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 uY9osyGs0lZJ; Tue, 31 Aug 2010 20:25:26 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 72FF43A6358; Tue, 31 Aug 2010 20:25:26 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L810047QTEACZ@szxga03-in.huawei.com>; Wed, 01 Sep 2010 11:22:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L81009O8TEA76@szxga03-in.huawei.com>; Wed, 01 Sep 2010 11:22:58 +0800 (CST) Received: from z00147053k ([10.70.39.122]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L810039PTE9AX@szxml04-in.huawei.com>; Wed, 01 Sep 2010 11:22:57 +0800 (CST) Date: Wed, 01 Sep 2010 11:22:57 +0800 From: Tina TSOU To: iesg@ietf.org, secdir@ietf.org, secdir-secretary@mit.edu, draft-ietf-roll-rpl@tools.ietf.org Message-id: <44BCD8D277C6479097DB80AF063B4325@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: [secdir] secdir review of draft-ietf-roll-rpl-11 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: , X-List-Received-Date: Wed, 01 Sep 2010 03:25:27 -0000 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 is well written. I only have two comments. 1. It is lack of manageability aspects to produce MIB; 2. Should be added flow examples for RPL; B. R. Tina http://tinatsou.weebly.com/index.html