From kivinen@iki.fi Thu Nov 1 04:02:05 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2156D21F84E7 for ; Thu, 1 Nov 2012 04:02:05 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBnt8Dd4K6JK for ; Thu, 1 Nov 2012 04:02:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD9421F84CE for ; Thu, 1 Nov 2012 04:02:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA1B1x9b020687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Nov 2012 13:01:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA1B1wYf001749; Thu, 1 Nov 2012 13:01:58 +0200 (EET) 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: <20626.22182.444702.18864@fireball.kivinen.iki.fi> Date: Thu, 1 Nov 2012 13:01:58 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 01 Nov 2012 11:02:05 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Magnus Nystrom is next in the rotation. For telechat 2012-11-15 Reviewer LC end Draft Rob Austein T 2012-10-23 draft-leiba-extended-doc-shepherd-00 Dave Cridland T 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-13 Dan Harkins T 2012-11-01 draft-gont-intarea-obsolete-eid-option-01 Tero Kivinen T 2012-10-24 draft-ietf-xrblock-rtcp-xr-delay-10 Catherine Meadows T 2012-11-09 draft-ietf-mpls-mldp-in-band-signaling-07 Kathleen Moriarty T 2012-11-13 draft-ietf-ipfix-a9n-07 Glen Zorn T 2012-08-14 draft-ietf-mptcp-api-06 Last calls and special requests: Shawn Emery 2012-10-17 draft-ietf-karp-ospf-analysis-05 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2012-10-22 draft-ietf-fecframe-simple-rs-04 Leif Johansson 2012-10-22 draft-ietf-mediactrl-mrb-15 Julien Laganier 2012-11-19 draft-ietf-karp-routing-tcp-analysis-05 Russ Mundy 2012-11-12 draft-ietf-mmusic-sdp-media-capabilities-15 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-10 Sandy Murphy 2012-11-26 draft-nir-ipsecme-erx-07 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-08 Yoav Nir 2012-11-13 draft-ietf-radext-ipv6-access-13 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Vincent Roca 2012-09-24 draft-ietf-dime-erp-14 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-10-25 draft-leiba-3777upd-eligibility-04 -- kivinen@iki.fi From vincent.roca@inria.fr Sun Nov 4 13:55:18 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB95D21F87F5; Sun, 4 Nov 2012 13:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5SXgQ8dngRT; Sun, 4 Nov 2012 13:55:18 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8C33721F86AE; Sun, 4 Nov 2012 13:55:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,711,1344204000"; d="scan'208,217";a="180091315" Received: from ral119r.vpn.inria.fr ([128.93.178.119]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 04 Nov 2012 22:55:14 +0100 From: Vincent Roca Content-Type: multipart/alternative; boundary=Apple-Mail-16-96758462 Date: Sun, 4 Nov 2012 22:55:13 +0100 Message-Id: <5DE1DFCC-00A7-4F54-BF14-75878273895C@inria.fr> To: IESG IESG , draft-ietf-dime-erp.all@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] Secdir review of draft-ietf-dime-erp-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 21:55:18 -0000 --Apple-Mail-16-96758462 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. -- The security section of this document is pretty simple as it refers to the security section of 4 related documents and that's all. On the opposite, each of these 4 documents includes a very detailed security analysis. The contrast is extremely important! This is all the more annoying as draft-ietf-dime-erp-14 introduces new mechanisms, and thereby new potential threats and issues (it's usually the case). What should I understand? Is the proposal guaranteed to be secure? Or have all the potential weaknesses been already addressed in the 4 related documents? I can not conclude after reading this security = section and this is a problem. So, I'd like that the authors clarify this, and if need be, I'd like the = authors explicitly mention which items in each of the 4 related documents apply. It would be helpful IMHO. Cheers, Vincent= --Apple-Mail-16-96758462 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
--

=
The = security section of this document is pretty simple as it refers = to
the security section of 4 = related documents and that's all. On the
opposite, each of these 4 = documents includes a very detailed security
analysis.  The contrast is = extremely important!
This is all the more = annoying as draft-ietf-dime-erp-14 introduces new
mechanisms, and thereby new = potential threats and issues (it's usually
the case).

What = should I understand? Is the proposal guaranteed to be secure?
Or have all the = potential weaknesses been already addressed in the
4 related documents? I can not = conclude after reading this security section
and this is a = problem.

So, I'd like that the authors = clarify this, and if need be, I'd like the authors
explicitly mention which items = in each of the 4 related documents apply.
It would be helpful = IMHO.

information had been sent in out-of-band protocols such = as  PIM and BGP. 

This document = mainly concerns ways of representing the different kinds of maps between = end-user packets and LSPs
in FECs.  Thus, the only = security considerations are inherited from the base LDP specification, = as the authors point out.
I believe that this use of mLDP FECs = is  appropriate from a security point of view, because the = information being transmitted is for use by mLDP.
Indeed, I = would argue that reducing complexity by no longer using an out-of-band = protocol improves = security.


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-23-181231044-- From kent@bbn.com Mon Nov 5 14:35:23 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B1921F8457 for ; Mon, 5 Nov 2012 14:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpwvXW0JKFVC for ; Mon, 5 Nov 2012 14:35:19 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 50F6F11E8097 for ; Mon, 5 Nov 2012 14:35:06 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:39611 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TVVET-000OPL-56; Mon, 05 Nov 2012 17:33:25 -0500 Message-ID: <50983EB5.2010501@bbn.com> Date: Mon, 05 Nov 2012 17:33:25 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: "Black, David" References: <507F45BE.2040900@bbn.com> <8D3D17ACE214DC429325B2B98F3AE7120E04B01F@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120E04B01F@MX15A.corp.emc.com> Content-Type: multipart/alternative; boundary="------------030801080108090807080000" Cc: "mkosjc@gmail.com" , Mallikarjun Chadalapaka , "ttalpey@microsoft.com" , secdir , "wes@mti-systems.com" , "nezhinsky@gmail.com" , "alexandern@mellanox.com" , "martin.stiemerling@neclab.eu" Subject: Re: [secdir] secdir review of draft-ietf-storm-iser-12.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 22:35:23 -0000 This is a multi-part message in MIME format. --------------030801080108090807080000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David, > Steve, > > Thank you for this review. > > > RFC 5042 analyzes security issues associated with RDMA, so it is an > > > appropriate reference here. As an aside, I'm surprised to see that > RFC 5042 > > > refers to the old IPsec RFCs (2401 series), instead of the newer > IPsec RFCs > > > (4301 series). RFC 5042 was published in October 2007, almost 2 years > after > > > the later set of IPsec RFCs, so there was plenty of time to update the > > > references! I didn't see any rationale in 5042 for why the earlier IPsec > > > RFCs were cited. (OK, time to fess up, which SECDIR member reviewed > 5042?) > > A conscious and deliberate decision was made at that time to continue > to use > > the IP Storage profile of the older IPsec RFCs (2401 series) as > specified in > > RFC 3723 for consistency. While that decision was apparently not recorded > > in RFC 5042, another RFC in that series, RFC 5040 does have this to say in > > its Security Considerations (Section 8): > > The IPsec requirements for RDDP are based on the version of IPsec > > specified in RFC 2401 [RFC2401] and related RFCs, as profiled by RFC > > 3723 [RFC3723], despite the existence of a newer version of IPsec > > specified in RFC 4301 [RFC4301] and related RFCs [RFC4303], > > [RFC4306], [RFC4835]. One of the important early applications of the > > RDDP protocols is their use with iSCSI [iSER]; RDDP's IPsec > > requirements follow those of IPsec in order to facilitate that usage > > by allowing a common profile of IPsec to be used with iSCSI and the > > RDDP protocols. In the future, RFC 3723 may be updated to the newer > > version of IPsec, and the IPsec security requirements of any such > > update should apply uniformly to iSCSI and the RDDP protocols. > > So, I think the (anonymous) SECDIR reviewer is off the hook on this one, > > which is just as well as (IIRC), at least one of the SEC ADs at the time > > was also involved :-). > > The consolidated iSCSI draft updates RFC 3723 to extend that IPsec profile > > to the 4301 series RFCs (as well as to the current IKEv2 specification, > > RFC 5996), although the 2401 series RFCs are still the "MUST implement" > > requirements based on what has been widely implemented. I will check with > > the current security ADs (both of whom just happen to be holding Discuss > > positions on that iSCSI draft for good reasons) about whether to go ahead > > and use that iSCSI draft to update the 5040 series RFCs - I think that > > should probably be done. > Thanks for the explanation. If the WG and ADs choose to stick with the 3401 series, I think it would be useful to readers to note the rationale for this in the SC section. > > > The document states that "iSER requires no changes to iSCSI > authentication, > > > security and text mode negotiation mechanisms." (The wording here is > a bit > > > worrisome as suggests that the authors equate security with > confidentiality, > > > since the more general, and accurate, use of the term "security" > encompasses > > > authentication.) > > You could have just called that an editorial nit :-) - we'll fix it, > regardless. > Too often I review docs where the authors don't know the difference, which is why I flag issues like this. but, in your case I'll chalk it up as a typo :-). > > > This section states plainly that iSER is "functionally iSCSI" and thus > > > all of the iSCSI security considerations apply. In particular, when iSER > > > is carried over IP networks, IPsec MUST be employed. > > Not exactly ;-). The IPsec requirements are consistently "MUST implement, > > MAY use". > Right. sorry for my sloppy characterization. > > > There is an overly-long, single sentence paragraph discussing how to > > > minimize the potential for DoS attacks. The wording is a bit vague, but > > > the text refers to the discussion of initiator and target behaviors, > > > which provide the relevant details. This is a very narrow focus on DoS, > > > and I suggest that the paragraph in question be augmented to state that > > > the only DoS attacks addressed here are ones that could cause resource > > > exhaustion at a target. > > Will edit and clarify as suggested. > Thanks. > > > The Security Considerations section concludes with a paragraph that is > > > a bit mysterious. > > What's Halloween time without a good mystery :-) :-) ? > good timing! > > > It seems to warn implementers of a residual vulnerability associated > > > with the use of a buffer identifier. However, the section to which this > > > paragraph refers contains the following sentence: > > > > > > "That iSER layer MUST check that STag invalidation has occurred whenever > > > receipt of a Send with Invalidate message is the expected means of > causing > > > an STag to be invalidated, and MUST perform the STag invalidation if the > > > STag has not already been invalidated (e.g., because a Send message was > > > used instead of Send with Invalidate)." > > > > > > This sort of writing does not explain complex issues to a reader. > > We'll provide a better explanation in the Security Considerations section. > > What happened here is that the original specification of iSER (RFC 5046) > > required (MUST) use of a Send with Invalidate RCaP primitive in some > cases. > > That primitive has the side effect of invalidating a buffer identifier, > > preventing future use (as the buffer identifier enables remote direct > access > > to memory), and that requirement allowed the implementation on the > receiving > > end to rely on use of that primitive to invalidate the buffer identifier. > > This draft allows use of a Send RCaP primitive that does not > invalidate the > > buffer identifier in all cases, and that exposes the buffer identifier to > > future use, thereby creating a potential security issue if the identifier > > was supposed to be invalidated. Hence when invalidation of the buffer > > identifier is intended or required (e.g., it's not being cached for future > > reuse), an iSER implementation can no longer rely on the underlying use of > > an RCaP Send with Invalidate primitive, but has to instead explicitly > check > > the state of the buffer identifier and/or perform a local invalidation > if the > > identifier is still valid. > > Thanks for the explanation. I;m confident that your revision will make this OK. No need for me to re-review. Steve --------------030801080108090807080000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David,

Steve,

 

Thank you for this review.

 

> RFC 5042 analyzes security issues associated with RDMA, so it is an

> appropriate reference here. As an aside, I’m surprised to see that RFC 5042

> refers to the old IPsec RFCs (2401 series), instead of the newer IPsec RFCs

> (4301 series). RFC 5042 was published in October 2007, almost 2 years after

> the later set of IPsec RFCs, so there was plenty of time to update the

> references! I didn’t see any rationale in 5042 for why the earlier IPsec

> RFCs were cited. (OK, time to fess up, which SECDIR member reviewed 5042?)

 

A conscious and deliberate decision was made at that time to continue to use

the IP Storage profile of the older IPsec RFCs (2401 series) as specified in

RFC 3723 for consistency.  While that decision was apparently not recorded

in RFC 5042, another RFC in that series, RFC 5040 does have this to say in

its Security Considerations (Section 8):

 

   The IPsec requirements for RDDP are based on the version of IPsec

   specified in RFC 2401 [RFC2401] and related RFCs, as profiled by RFC

   3723 [RFC3723], despite the existence of a newer version of IPsec

   specified in RFC 4301 [RFC4301] and related RFCs [RFC4303],

   [RFC4306], [RFC4835].  One of the important early applications of the

   RDDP protocols is their use with iSCSI [iSER]; RDDP's IPsec

   requirements follow those of IPsec in order to facilitate that usage

   by allowing a common profile of IPsec to be used with iSCSI and the

   RDDP protocols.  In the future, RFC 3723 may be updated to the newer

   version of IPsec, and the IPsec security requirements of any such

   update should apply uniformly to iSCSI and the RDDP protocols.

 

So, I think the (anonymous) SECDIR reviewer is off the hook on this one,

which is just as well as (IIRC), at least one of the SEC ADs at the time

was also involved :-).

 

The consolidated iSCSI draft updates RFC 3723 to extend that IPsec profile

to the 4301 series RFCs (as well as to the current IKEv2 specification,

RFC 5996), although the 2401 series RFCs are still the “MUST implement”

requirements based on what has been widely implemented.  I will check with

the current security ADs (both of whom just happen to be holding Discuss

positions on that iSCSI draft for good reasons) about whether to go ahead

and use that iSCSI draft to update the 5040 series RFCs - I think that

should probably be done.

Thanks for the explanation. If the WG and ADs choose to stick with the 3401 series,
I think it would be useful to readers to note the rationale for this in the SC section.

 

> The document states that “iSER requires no changes to iSCSI authentication,

> security and text mode negotiation mechanisms.” (The wording here is a bit

> worrisome as suggests that the authors equate security with confidentiality,

> since the more general, and accurate, use of the term “security” encompasses

> authentication.)

 

You could have just called that an editorial nit :-) - we’ll fix it, regardless.

Too often I review docs where the authors don't know the difference, which is why
I flag issues like this. but, in your case I'll chalk it up as a typo :-).

 

> This section states plainly that iSER is “functionally iSCSI” and thus

> all of the iSCSI security considerations apply. In particular, when iSER

> is carried over IP networks, IPsec MUST be employed.

Not exactly ;-).  The IPsec requirements are consistently “MUST implement,

MAY use”.

Right. sorry for my sloppy characterization.

 

> There is an overly-long, single sentence paragraph discussing how to

> minimize the potential for DoS attacks. The wording is a bit vague, but

> the text refers  to the discussion of initiator and target behaviors,

> which provide the relevant details. This is a very narrow focus on DoS,

> and I suggest that the paragraph in question be augmented to state that

> the only DoS attacks addressed here are ones that could cause resource

> exhaustion at a target.

 

Will edit and clarify as suggested.

Thanks.

 

> The Security Considerations section concludes with a paragraph that is

> a bit mysterious.

 

What’s Halloween time without a good mystery :-) :-) ?

good timing!

 

> It seems to warn implementers of a residual vulnerability associated

> with the use of a buffer identifier. However, the section to which this

> paragraph refers contains the following sentence:

>

> “That iSER layer MUST check that STag invalidation has occurred whenever

> receipt of a Send with Invalidate message is the expected means of causing

> an STag to be invalidated, and MUST perform the STag invalidation if the

> STag has not already been invalidated (e.g., because a Send message was

> used instead of Send with Invalidate).”

> This sort of writing does not explain complex issues to a reader.

 

We’ll provide a better explanation in the Security Considerations section.

 

What happened here is that  the original specification of iSER (RFC 5046)

required (MUST) use of a Send with Invalidate RCaP primitive in some cases.

That primitive has the side effect of invalidating a buffer identifier,

preventing future use (as the buffer identifier enables remote direct access

to memory), and that requirement allowed the implementation on the receiving

end to rely on use of that primitive to invalidate the buffer identifier.

This draft allows use of a Send RCaP primitive that does not invalidate the

buffer identifier in all cases, and that exposes the buffer identifier to

future use, thereby creating a potential security issue if the identifier

was supposed to be invalidated.  Hence when invalidation of the buffer

identifier is intended or required (e.g., it’s not being cached for future

reuse), an iSER implementation can no longer rely on the underlying use of

an RCaP Send with Invalidate primitive, but has to instead explicitly check

the state of the buffer identifier and/or perform a local invalidation if the

identifier is still valid.

 

Thanks for the explanation. I;m confident that your revision will make this OK.

No need for me to re-review.

Steve
--------------030801080108090807080000-- From turners@ieca.com Tue Nov 6 06:04:33 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0624E21F88F7 for ; Tue, 6 Nov 2012 06:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.183 X-Spam-Level: X-Spam-Status: No, score=-102.183 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TtRKwqGMsdD for ; Tue, 6 Nov 2012 06:04:30 -0800 (PST) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.52.14]) by ietfa.amsl.com (Postfix) with ESMTP id 772C021F88CB for ; Tue, 6 Nov 2012 06:04:30 -0800 (PST) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id E2CDB76409DA2; Tue, 6 Nov 2012 08:04:29 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id D7B7E76409D69 for ; Tue, 6 Nov 2012 08:04:29 -0600 (CST) Received: from [130.129.84.240] (port=49774 helo=dhcp-54f0.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TVjlV-0001Nh-NG for secdir@ietf.org; Tue, 06 Nov 2012 08:04:29 -0600 Message-ID: <509918ED.7020704@ieca.com> Date: Tue, 06 Nov 2012 09:04:29 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-54f0.meeting.ietf.org) [130.129.84.240]:49774 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [secdir] reminder: secdir lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:04:33 -0000 All, We've been assigned Room 211 on Tuesday November 6th from 11:30-13:00 for the secdir lunch. Hope to see you all there. Cheers, spt From rbarnes@bbn.com Tue Nov 6 08:14:05 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E7521F89D1 for ; Tue, 6 Nov 2012 08:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHRdHl8+Dn+s for ; Tue, 6 Nov 2012 08:14:05 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 312C421F8958 for ; Tue, 6 Nov 2012 08:14:05 -0800 (PST) Received: from [128.89.254.139] (port=60972) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TVlmh-000Phl-MA; Tue, 06 Nov 2012 11:13:51 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: <509918ED.7020704@ieca.com> Date: Tue, 6 Nov 2012 11:13:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <509918ED.7020704@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1499) Cc: secdir@ietf.org Subject: Re: [secdir] reminder: secdir lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:14:06 -0000 Anyone have ideas for where to find lunch? On Nov 6, 2012, at 9:04 AM, Sean Turner wrote: > All, >=20 > We've been assigned Room 211 on Tuesday November 6th from 11:30-13:00 = for the secdir lunch. Hope to see you all there. >=20 > Cheers, >=20 > spt > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From derek@ihtfp.com Tue Nov 6 08:16:16 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F191A21F89CF for ; Tue, 6 Nov 2012 08:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx9XF7f8tGR7 for ; Tue, 6 Nov 2012 08:16:15 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id BDBD421F8772 for ; Tue, 6 Nov 2012 08:16:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5F37D260286; Tue, 6 Nov 2012 11:16:14 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 15335-05; Tue, 6 Nov 2012 11:16:10 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id B8C862600BB; Tue, 6 Nov 2012 11:16:10 -0500 (EST) Received: from 2001:df8:0:80:224:d7ff:fee7:8924 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 6 Nov 2012 11:16:10 -0500 Message-ID: In-Reply-To: References: <509918ED.7020704@ieca.com> Date: Tue, 6 Nov 2012 11:16:10 -0500 From: "Derek Atkins" To: "Richard L. Barnes" User-Agent: SquirrelMail/1.4.22-2.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: secdir@ietf.org Subject: Re: [secdir] reminder: secdir lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:16:17 -0000 Food court in Peachetree Center Mall? -derek On Tue, November 6, 2012 11:13 am, Richard L. Barnes wrote: > Anyone have ideas for where to find lunch? > > > On Nov 6, 2012, at 9:04 AM, Sean Turner wrote: > >> All, >> >> We've been assigned Room 211 on Tuesday November 6th from 11:30-13:00 >> for the secdir lunch. Hope to see you all there. >> >> Cheers, >> >> spt >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From kwiereng@cisco.com Tue Nov 6 08:26:12 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1224421F8A3E for ; Tue, 6 Nov 2012 08:26:12 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEkn2IkmMlYi for ; Tue, 6 Nov 2012 08:26:11 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72721F8A0F for ; Tue, 6 Nov 2012 08:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=559; q=dns/txt; s=iport; t=1352219171; x=1353428771; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TcYZw0FDI7aoBDAvmYR/NWsMC28PDjEAE7fZjHBdxfw=; b=YYmUuIk5VqOx9nVbAsrljpCbUxzarcBFnXw9cT1vFER9D4sgmQc7YcGW qE6xmSzU8j+BwowvxREkU6+fL988tQ28xV9b+f8lgvQIWubS6jkVE0ZU7 L/ijypAspGER72Lvhsj1KakHOCrTlY6uTpFY5GUXwb9CWyrFF5x3fO0pZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAIc3mVCtJV2d/2dsb2JhbABEhVC9X4EIgh4BAQEDAQEBAQ8BJzQLBQsCAQg2ECcLJQIEDgUih2IGC5t1j2SQU4wDhXRhA5V7gRyNPYFrgm8 X-IronPort-AV: E=Sophos;i="4.80,722,1344211200"; d="scan'208";a="136356963" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 06 Nov 2012 16:26:10 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA6GQAAn011120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 16:26:10 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 10:26:09 -0600 From: "Klaas Wierenga (kwiereng)" To: Sean Turner Thread-Topic: [secdir] reminder: secdir lunch Thread-Index: AQHNvCesFvTow8SiiUevRx5OiDif5pfc/ovi Date: Tue, 6 Nov 2012 16:26:08 +0000 Message-ID: References: <509918ED.7020704@ieca.com> In-Reply-To: <509918ED.7020704@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--48.783800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "secdir@ietf.org" Subject: Re: [secdir] reminder: secdir lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:26:12 -0000 Hi Sean, I am signed up for the ISOC event, so I'll miss the secdir lunch alas. Klaas Sent from my iPad On 6 nov. 2012, at 09:04, "Sean Turner" wrote: > All, >=20 > We've been assigned Room 211 on Tuesday November 6th from 11:30-13:00 for= the secdir lunch. Hope to see you all there. >=20 > Cheers, >=20 > spt > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From stephen.farrell@cs.tcd.ie Tue Nov 6 11:14:40 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C7F21F8B15 for ; Tue, 6 Nov 2012 11:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS5371JBvi+j for ; Tue, 6 Nov 2012 11:14:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6BE21F8C85 for ; Tue, 6 Nov 2012 11:14:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B357CBE49 for ; Tue, 6 Nov 2012 19:14:10 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gqvMXOeFijJ for ; Tue, 6 Nov 2012 19:14:10 +0000 (GMT) Received: from [130.129.96.58] (dhcp-603a.meeting.ietf.org [130.129.96.58]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DDFC9BE2B for ; Tue, 6 Nov 2012 19:14:09 +0000 (GMT) Message-ID: <50996180.50609@cs.tcd.ie> Date: Tue, 06 Nov 2012 19:14:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] pcp chairs are looking to switch agenda iterm... X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:14:40 -0000 ... to Friday. Dunno if they need to check presenter stuff (which they may) but they said they're willing to move the agenda item if they can, S. From stephen.farrell@cs.tcd.ie Thu Nov 8 06:32:34 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8188C21F8B50 for ; Thu, 8 Nov 2012 06:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZvWixUsJAfz for ; Thu, 8 Nov 2012 06:32:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA4421F8B49 for ; Thu, 8 Nov 2012 06:32:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 56B59BE5D for ; Thu, 8 Nov 2012 14:32:12 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCytfIRZrC08 for ; Thu, 8 Nov 2012 14:32:11 +0000 (GMT) Received: from [130.129.96.58] (dhcp-603a.meeting.ietf.org [130.129.96.58]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 78C82BE5B for ; Thu, 8 Nov 2012 14:32:11 +0000 (GMT) Message-ID: <509BC26A.1080803@cs.tcd.ie> Date: Thu, 08 Nov 2012 14:32:10 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] security meeting summaries to saag list X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:32:34 -0000 Hiya, Can you please send your wg/bof meeting summaries to the saag list before the session? That is, in the next couple of hours. Thanks, Stephen. From kivinen@iki.fi Thu Nov 8 11:17:35 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E544B21F87F6 for ; Thu, 8 Nov 2012 11:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnoZvh8REFHg for ; Thu, 8 Nov 2012 11:17:35 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 20E2721F87F4 for ; Thu, 8 Nov 2012 11:17:34 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA8JHQI0028273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Nov 2012 21:17:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA8JHQim022544; Thu, 8 Nov 2012 21:17:26 +0200 (EET) 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: <20636.1350.305953.168894@fireball.kivinen.iki.fi> Date: Thu, 8 Nov 2012 21:17:26 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 08 Nov 2012 19:17:36 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2012-11-15 Reviewer LC end Draft Rob Austein T 2012-10-23 draft-leiba-extended-doc-shepherd-01 Shawn Emery T 2012-10-17 draft-ietf-karp-ospf-analysis-05 Dan Harkins T 2012-11-01 draft-gont-intarea-obsolete-eid-option-01 Kathleen Moriarty T 2012-11-13 draft-ietf-ipfix-a9n-07 Glen Zorn T 2012-08-14 draft-ietf-mptcp-api-06 For telechat 2012-11-29 Dave Cridland T 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-13 Magnus Nystrom T 2012-11-21 draft-ietf-imapmove-command-02 Last calls and special requests: Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2012-10-22 draft-ietf-fecframe-simple-rs-05 Leif Johansson 2012-11-26 draft-ietf-mediactrl-mrb-16 Julien Laganier 2012-11-19 draft-ietf-karp-routing-tcp-analysis-05 Russ Mundy 2012-11-12 draft-ietf-mmusic-sdp-media-capabilities-15 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-11 Sandy Murphy 2012-11-26 draft-nir-ipsecme-erx-07 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-08 Yoav Nir 2012-11-13 draft-ietf-radext-ipv6-access-13 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-10-25 draft-leiba-3777upd-eligibility-05 -- kivinen@iki.fi From shanna@juniper.net Thu Nov 8 12:32:27 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDDB21F88EA for ; Thu, 8 Nov 2012 12:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.447 X-Spam-Level: X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnY0Bdw-zpki for ; Thu, 8 Nov 2012 12:32:26 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 659A521F88DE for ; Thu, 8 Nov 2012 12:32:26 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUJwW2ikly9lEw/oeCAbUD3sCnUuw/ege@postini.com; Thu, 08 Nov 2012 12:32:26 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 12:30:46 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 8 Nov 2012 12:30:45 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 8 Nov 2012 12:37:47 -0800 Received: from mail136-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 20:30:45 +0000 Received: from mail136-co1 (localhost [127.0.0.1]) by mail136-co1-R.bigfish.com (Postfix) with ESMTP id ADC60C80A05 for ; Thu, 8 Nov 2012 20:30:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 4 X-BigFish: PS4(zzzz1de0h1202h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received: from mail136-co1 (localhost.localdomain [127.0.0.1]) by mail136-co1 (MessageSwitch) id 1352406636329734_1871; Thu, 8 Nov 2012 20:30:36 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.245]) by mail136-co1.bigfish.com (Postfix) with ESMTP id 4E513A80046 for ; Thu, 8 Nov 2012 20:30:36 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Nov 2012 20:30:33 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.12.27]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0233.002; Thu, 8 Nov 2012 20:01:43 +0000 From: Stephen Hanna To: "secdir@ietf.org" Thread-Topic: wpkops BOF report Thread-Index: Ac296N4rjhn99D7aTWWWhsplwz7pxA== Date: Thu, 8 Nov 2012 19:40:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [secdir] wpkops BOF report X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:32:27 -0000 The Web PKI Operations BOF (wpkops) met on Monday afternoon. Although this BOF was technically in the OPS area, it is probably of interest to many people in the SEC area. Several presenters explained the mess that is the current web PKI. A draft WG charter was presented, proposing to document the widely-used parts of this mess so that the participants can know what to expect. Perhaps someone can even help make it a little better! But improvements to the web PKI are explicitly out of scope for this effort: only documentation of the status quo. The main topic discussed was whether user interface should be in scope. The consensus was that we should include functional documentation of the information provided to users about the web PKI and the actions they can take. With this agreement, there was strong consensus in the room that the problem statement is clear, well-scoped, solvable, and urgent. Plenty of editors are on board and about 20 people indicated that they would read the drafts and comment. So there was rough consensus that we should charter a working group in this area. From dharkins@lounge.org Mon Nov 12 10:05:49 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD56C21F8539; Mon, 12 Nov 2012 10:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5qdO+3Nd8M6; Mon, 12 Nov 2012 10:05:49 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3C89A21F84BC; Mon, 12 Nov 2012 10:05:49 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C4C681022400A; Mon, 12 Nov 2012 10:05:48 -0800 (PST) Received: from 50.84.73.44 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Nov 2012 10:05:48 -0800 (PST) Message-ID: <2eb588abc880c49fa2444d4e4e06baee.squirrel@www.trepanning.net> Date: Mon, 12 Nov 2012 10:05:48 -0800 (PST) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-gont-intarea-obsolete-eid-option.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] comments on draft-gont-intarea-obsolete-eid-option X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:05:49 -0000 Hello, 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 instructs IANA to obsolete an entry in the v6 "Destination Options and Hop-by-Hop Options" registry". That's it. Strip away the boilerplate and this draft is about as long as the secdir review boilerplate I added above. The option was used by the Nimrod routing architecture but, apparently, wasn't deployed, hence the instruction to obsolete it. There are no security issues with this draft and nothing for the ADs to pay close attention to. My only suggested change would be entirely editorial and that is to remove the "e.g" in the following sentence from the Security Considerations: "[F]ormally deprecating this option may serve as a basis for e.g. providing advice about filtering packets containing such option (in a similar way to [I-D.ietf-opsec-ip-options-filtering] for the IPv4 case)." It seems to me that "e.g" is superfluous; the sentence stands without it. On the other hand, if there is some general class of behavior to which this example belongs then say that this deprecation serves as a basis for that class of behavior and give this specific example. regards, Dan. From fgont@si6networks.com Mon Nov 12 10:39:30 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA5621F878C; Mon, 12 Nov 2012 10:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTGklmQsPuLc; Mon, 12 Nov 2012 10:39:28 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 30AF021F878B; Mon, 12 Nov 2012 10:39:28 -0800 (PST) Received: from [186.134.15.187] (helo=[192.168.123.122]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TXyun-0001kb-Bb; Mon, 12 Nov 2012 19:39:21 +0100 Message-ID: <50A14225.4000609@si6networks.com> Date: Mon, 12 Nov 2012 15:38:29 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 13 Nov 2012 08:09:14 -0800 Cc: draft-ietf-v6ops-ra-guard-implementation.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-v6ops-ra-guard-implementation-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:39:30 -0000 Hi, Kathleen, My apologies for the delay in my response - it seems that I had not seen this email! Please find my comments in-line... On 07/12/2012 11:01 AM, kathleen.moriarty@emc.com wrote: > Review Summary: > The draft is mostly ready (the draft introduces new requirements to > protect against specific attack vectors and addresses them well), but I > would recommend some stronger language in the Security Considerations > section in the following areas: > > In the start of the security considerations section, it says that > ‘advice’ is given to correct the problems. Reading through the draft > this updates and this draft, would saying ‘new requirements’ or > ‘additional requirements’ be better? How about "it introduces requirements for RA-Guard implementations"? (i.e., RFC 6105 was infrmational, and didn't include any formal requirements). > Also, to be compliant with this BCP, shouldn’t the security > considerations section just require compliance with RFC5722? It woudld e inappropriate: RA-Guard is implemented at the layer-2 devices connecting the nodes to be protected, while the requirement to implement RFC5722 would aim at *those* nodes we want to protect. Put another way, there's nothing an RA-Guard implementer can do to force/push compliance with RFC5722 by other nodes. Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ynir@checkpoint.com Tue Nov 13 09:32:33 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F70021F8614; Tue, 13 Nov 2012 09:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.573 X-Spam-Level: X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tZFQ49n1Acr; Tue, 13 Nov 2012 09:32:32 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 774E821F85D9; Tue, 13 Nov 2012 09:32:30 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qADHWCJD001102; Tue, 13 Nov 2012 19:32:17 +0200 X-CheckPoint: {50A2811E-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.194]) by IL-EX10.ad.checkpoint.com ([169.254.2.194]) with mapi id 14.02.0318.004; Tue, 13 Nov 2012 19:32:11 +0200 From: Yoav Nir To: "iesg@ietf.org IESG" , "draft-ietf-radext-ipv6-access.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-radext-ipv6-access-13 Thread-Index: AQHNwcTPUbHJ2GPZ5UOxjF/f4n0iqg== Date: Tue, 13 Nov 2012 17:32:10 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210152E3@IL-EX10.ad.checkpoint.com> References: <20550.1861.349381.646147@fireball.kivinen.iki.fi> In-Reply-To: <20550.1861.349381.646147@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.141] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11899cbe73b9f71bcbeed90d6889320e646a9ed742 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "secdir@ietf.org" Subject: [secdir] SecDir review of draft-ietf-radext-ipv6-access-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 17:32:33 -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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. The draft adds IPv6 RADIUS attributes for information received using DHCP. = The attributes include IPv6 address, DNS server address, IPv6 route informa= tion, delegated IPv6 prefix, and stateful IPv6 address pool. The security considerations section covers general vulnerabilities in RADIU= S just to say that those apply here as well. It also makes a reference to I= Psec as "natively defined for IPv6". This can IMO be omitted, as pretty muc= h every platform that has IPsec for IPv6 has it for IPv4 as well, and IPsec= is not longer required for compliance with IPv6, otherwise all those smart= objects would be non-compliant. There is no treatment of the issue of a rogue RADIUS server supplying bad r= outes to the NAS. This can be explained away by saying that a trust relatio= nship exists between RADIUS server and NAS, but I think this should be ment= ioned. Yoav From kivinen@iki.fi Sat Nov 17 18:17:37 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A731021F84EE for ; Sat, 17 Nov 2012 18:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlx1o+RO6qLa for ; Sat, 17 Nov 2012 18:17:37 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 802B721F84DE for ; Sat, 17 Nov 2012 18:17:34 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qAI2HVun022713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Nov 2012 04:17:31 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qAI2HVKm014819; Sun, 18 Nov 2012 04:17:31 +0200 (EET) 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: <20648.17722.786142.400283@fireball.kivinen.iki.fi> Date: Sun, 18 Nov 2012 04:17:30 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 18 Nov 2012 02:17:37 -0000 Assignments come bit late this week, as I was checking the total eclipse in Australia and our "hotel" did not have network connectivitity. The place where I checked the eclipse didn't have any mobile phone coverage either, but eclipse was amazing again... https://www.facebook.com/photo.php?fbid=494659733899244&l=f7a31ff738 https://www.facebook.com/photo.php?fbid=494645497234001&l=7956011df9 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yaron Sheffer is next in the rotation. For telechat 2012-11-29 Reviewer LC end Draft Dave Cridland T 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-14 Magnus Nystrom T 2012-11-21 draft-ietf-imapmove-command-02 Joe Salowey T 2012-11-29 draft-ietf-softwire-6rd-radius-attrib-07 Last calls and special requests: Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2012-10-22 draft-ietf-fecframe-simple-rs-05 Leif Johansson 2012-11-26 draft-ietf-mediactrl-mrb-16 Julien Laganier 2012-11-19 draft-ietf-karp-routing-tcp-analysis-05 Russ Mundy 2012-11-12 draft-ietf-mmusic-sdp-media-capabilities-15 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-12 Sandy Murphy 2012-11-26 draft-nir-ipsecme-erx-07 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-08 Hilarie Orman 2012-12-14 draft-daboo-ical-vcard-parameter-encoding-02 Radia Perlman 2012-11-26 draft-ietf-6man-uri-zoneid-05 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Vincent Roca 2012-11-26 draft-ietf-netext-pmipv6-sipto-option-07 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-10-25 draft-leiba-3777upd-eligibility-05 -- kivinen@iki.fi From shawn.emery@oracle.com Sun Nov 18 13:26:59 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F9621F8534; Sun, 18 Nov 2012 13:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDwjqrqtEABI; Sun, 18 Nov 2012 13:26:59 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4AB21F84CC; Sun, 18 Nov 2012 13:26:59 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAILQwCO009191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Nov 2012 21:26:58 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAILQu1C008225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Nov 2012 21:26:56 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAILQtEE003692; Sun, 18 Nov 2012 15:26:55 -0600 Received: from [10.159.110.232] (/10.159.110.232) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 18 Nov 2012 13:26:55 -0800 Message-ID: <50A9523F.9070607@oracle.com> Date: Sun, 18 Nov 2012 14:25:19 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.7) Gecko/20121011 Thunderbird/10.0.7 MIME-Version: 1.0 To: secdir@ietf.org References: <503C71A4.30709@oracle.com> In-Reply-To: <503C71A4.30709@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: iesg@ietf.org, draft-ietf-karp-ospf-analysis.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-karp-ospf-analysis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 21:26:59 -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 informational draft describes security issues associated with manual keying in OSPF. The draft then provides guidance to counter these security threats. The security considerations section does exist and reiterates what is discussed in the main document, given that this is essentially a security draft. The security points discussed deal with replay, protecting routing data, and DoS attacks. For the former two the draft suggests the use of digital signatures as described in RFC2154. In regards to the latter, the draft proposes a solution utilizing RFC5082 . I believe the guidance given does not yield any security concerns and would be an improvement over the existing OSPF protocol. General comments: None. Editorial comments: s/RFC 2154 [RFC2154] provides/[RFC 2154] provides/ Shawn. -- From hilarie@purplestreak.com Mon Nov 19 14:26:04 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E4821F8597; Mon, 19 Nov 2012 14:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emWvQiIBWwL9; Mon, 19 Nov 2012 14:26:04 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4766021F8570; Mon, 19 Nov 2012 14:26:04 -0800 (PST) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1TaZn1-00066Z-6l; Mon, 19 Nov 2012 15:26:03 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx03.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1TaZn0-0007uu-91; Mon, 19 Nov 2012 15:26:03 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAJMPsq6030455; Mon, 19 Nov 2012 15:25:54 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id qAJMPsGA030453; Mon, 19 Nov 2012 15:25:54 -0700 Date: Mon, 19 Nov 2012 15:25:54 -0700 Message-Id: <201211192225.qAJMPsGA030453@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) Subject: [secdir] Security review of draft-daboo-ical-vcard-parameter-encoding-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 22:26:04 -0000 Parameter Value Encoding in iCalendar and vCard draft-daboo-ical-vcard-parameter-encoding-02 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines an character escape mechanism. This is not a literary device, but a way of encoding the double-quote and linefeed characters in vcard entries. This has no new security implications that I am aware of. The author states that it has minimal impact on existing implementations, so I assume that it is not likely to cause severe parsing problems. Hilarie Orman From magnusn@gmail.com Wed Nov 21 14:39:49 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBD521F851C; Wed, 21 Nov 2012 14:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7Jtlj2eiC-a; Wed, 21 Nov 2012 14:39:48 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B5CAE21F8513; Wed, 21 Nov 2012 14:39:48 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so404089qaa.10 for ; Wed, 21 Nov 2012 14:39:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2DuGPKFQJoy/56qYMIJkeSN0DMeoz61Chjw56jOxT48=; b=0eJ8av4RSOoWN7Lf7KyvUjOpKV4ZCd5YFaFC2VB0sC+7dQ86t9H5EqjCycaOPwMsAL XIgwiJXsPOVFAB1peNzA9iC2pY6trlX4vESwoRHKJwtR4P/s3sUb0Xxxc8ClcvsfEBkj Z3PSieVCBaB+TL6zW2smtuUTdfT0p01Z3dT+kpbz7puXg1fEWxPq7rYdn1Rxl9ZIDzcl MmxZsVleuofof6f5oeK1jFECcqmpETcChst+EWQrVB1LBbxyDVzJG/WKAybFIwcPIXpW KAM6eD/QFZHMG/huaPuX0a7BWbYmxnwIiKzGdEBk/3G2Bmp00dHmo6n7eDaKDf875xWb uprg== MIME-Version: 1.0 Received: by 10.224.168.75 with SMTP id t11mr19510156qay.89.1353537588260; Wed, 21 Nov 2012 14:39:48 -0800 (PST) Received: by 10.49.106.234 with HTTP; Wed, 21 Nov 2012 14:39:48 -0800 (PST) Date: Wed, 21 Nov 2012 14:39:48 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-imapmove-command@tools.ietf.org Content-Type: multipart/alternative; boundary=20cf3074b49623708104cf09077a Subject: [secdir] Secdir review of draft-ietf-imapmove-command-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 22:39:49 -0000 --20cf3074b49623708104cf09077a 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 standards-track document suggests a method for moving messages between mailboxes. The document is clearly written and the Security Consideration section does discuss all the potential issues I could think of. I have no further comments. -- Magnus --20cf3074b49623708104cf09077a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. =A0These 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 standards-track document suggests a method for moving messages between= mailboxes.=A0

=A0
The document is clearly written and the Security Consideration section does= discuss all the potential issues I could think of. I have no further comme= nts.

-- Magnus
--20cf3074b49623708104cf09077a-- From kivinen@iki.fi Thu Nov 22 04:50:22 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D5921F8951 for ; Thu, 22 Nov 2012 04:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZcnyhBwXQy6 for ; Thu, 22 Nov 2012 04:50:21 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 486F621F894D for ; Thu, 22 Nov 2012 04:50:20 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qAMCoEgF003160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Nov 2012 14:50:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qAMCoEdg024411; Thu, 22 Nov 2012 14:50:14 +0200 (EET) 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: <20654.8070.158251.882805@fireball.kivinen.iki.fi> Date: Thu, 22 Nov 2012 14:50:14 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 22 Nov 2012 12:50:22 -0000 There is no new assignments this week, but some documents moved from LC list to next weeks telechat agenda. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yaron Sheffer is next in the rotation. For telechat 2012-11-29 Reviewer LC end Draft Dave Cridland T 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-14 Radia Perlman T 2012-11-26 draft-ietf-6man-uri-zoneid-05 Vincent Roca T 2012-11-26 draft-ietf-netext-pmipv6-sipto-option-07 Joe Salowey T 2012-11-29 draft-ietf-softwire-6rd-radius-attrib-07 Last calls and special requests: Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2012-10-22 draft-ietf-fecframe-simple-rs-05 Leif Johansson 2012-11-26 draft-ietf-mediactrl-mrb-16 Julien Laganier 2012-11-19 draft-ietf-karp-routing-tcp-analysis-05 Russ Mundy 2012-11-12 draft-ietf-mmusic-sdp-media-capabilities-15 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-12 Sandy Murphy 2012-11-26 draft-nir-ipsecme-erx-07 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-08 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-10-25 draft-leiba-3777upd-eligibility-05 -- kivinen@iki.fi From radiaperlman@gmail.com Thu Nov 22 22:29:33 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4D721F8626; Thu, 22 Nov 2012 22:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btGiCbwaLIrH; Thu, 22 Nov 2012 22:29:29 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 469F121F84C0; Thu, 22 Nov 2012 22:29:29 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so7431963vcb.31 for ; Thu, 22 Nov 2012 22:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zKKAMsGXGTwjWQf1AO6WOqy5y3vYqfQLZJeSQgVAaLA=; b=YOrkUw+/C7DosyVIptq1o9d0fP3k10J++sF4yDCFTzPef6eEFQr95y4Gb1vjzEAiGX kUxjxc1778ZsTEdRHdOIvQvLGXAZxum64vvtETEeZHMdgnaMx2w+Qi7j5yUtB4zGU4FG I2ylwdR7QlG/bTr1YRD9uNYup+/7TUYmVqKRP+6X93I4UTKmcIiUNA0s/yf/Q0GJDwL/ 5UFcB/qfcqStBeqYxBWXc8rAwuiiKBYUFXOrFLrvys9R5A2CwNiwaxcSmkwOkqMUvQjh meSG9ovEZTYBNhE2rGNHlmoPjwHOFmg9gR/ewoYz4/MFKk51zxxrVg2/+cLRGfnwzIJo E2ag== MIME-Version: 1.0 Received: by 10.59.13.197 with SMTP id fa5mr4565946ved.47.1353652168354; Thu, 22 Nov 2012 22:29:28 -0800 (PST) Received: by 10.58.207.138 with HTTP; Thu, 22 Nov 2012 22:29:28 -0800 (PST) Date: Thu, 22 Nov 2012 22:29:28 -0800 Message-ID: From: Radia Perlman To: The IESG , secdir@ietf.org, draft-ietf-6man-uri-zoneid.all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0118499ca4e98904cf23b47c Subject: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 06:29:33 -0000 --089e0118499ca4e98904cf23b47c 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 provides syntax for specifying a port within a URI for an IPv6 link-local address. I find no security-specific issues with this draft, but I do think the clarity of the draft could be improved a lot, and also, I think that the draft allows options of what is or is not allowed, which could cause confusion for a human using this, since some strings will work sometimes. I think it would be better to lock down what is and is not allowed. I'm not fond of the term "zone identifier" (I had to do some Internet searching to figure out what it was). It would only take a sentence to explain it in this draft. Admittedly, not many people will be reading this draft out of context (like me). An example of where the wording is needlessly hard to read, and where I think the rule should be a MUST: " A SHOULD contain only ASCII characters classified in RFC 3986 as "unreserved", which conveniently excludes "]" in order to simplify parsing." That wording could mean that ] is reserved or it could mean that it is not reserved. Turns out (by referring to RFC 3986) "]" is actually reserved. And also, with my preference for specifying mandatory behavior rather than recommendation... perhaps saying something like " A MUST NOT contain ASCII characters classified in RFC 3986 as "reserved". The character "]" is reserved, so MUST NOT be used in the zone ID. --------- Again, "The rules in [RFC5952 ] SHOULD be applied in producing URIs." Why not MUST be applied? ---------- "we recommend that URI parsers accept bare "%" signs...make it easy for a user to copy and paste a string..." again, I'd think it would be better to specify what parsers MUST do, rather than saying some parsers can be more lenient, so that the same string will create the same behavior regardless of the implementation parsing it. --------- similarly "To limit this risk, implementations SHOULD NOT allow use of this format except for well-defined usages such as sending to link local addresses under prefix fe80::/10." I'd think it would be better to say MUST NOT, and also, to specify what it should do if it receives such a thing. Radia --089e0118499ca4e98904cf23b47c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate'= s
ongoing effort to review all IETF documents being processed by the IESG.=A0 These comments were written primarily for the benefit of the security area directors.=A0 Document editors and WG chairs should treat these comments just like any other last call comments.
=A0
=
This document provides syntax for specifying a port within a URI for a= n IPv6 link-local address.
I find no security-specific issues with this draft, but I do thi= nk the clarity of the draft
could be improved a lot, and also, I = think that the draft allows options of what is or is not allowed,
which could cause=A0confusion for a human using this, since some strin= gs will work sometimes.=A0 I think it would
be better to lock dow= n what is and is not allowed.=A0
=A0
I'm not fond o= f the term "zone identifier" (I had to do some Internet searching= to figure out what it was). It would
only take a sentence to explain it in this draft.=A0 Admittedly, not m= any people will be reading this draft out of
context (like me).
=A0
An example of where the wording is needlessly hard t= o read, and where I think the rule should be a MUST:
=A0
" A <zone_id> SHOULD contain only ASCII chara= cters classified
=A0=A0 in RFC 3986 as "unreserved", which convenien= tly excludes "]" in order
=A0=A0 to simplify parsing."
=A0
That wording coul= d mean that ] is reserved or it could mean that it is=A0not reserved.
=
Turns out (by=A0referring to=A0RFC 3986) "]" is actually res= erved.
And also, with my preference for specifying mandatory behavior rather = than recommendation...
perhaps saying something like
=A0
" A <zon= e_id>=A0MUST NOT=A0contain ASCII characters classified
=A0=A0 in RFC 3986 a= s "reserved".=A0 The character=A0 "]"=A0is reserved, so= MUST NOT
=A0 be used in the zone ID.
=A0
=A0
----= -----
Again,
=A0=A0=A0 "The rules in [RFC5952] SHOULD b= e applied in producing URIs."
Why not MUST be applied?
=A0
----------
"we recommend that URI parsers accept bare "%" signs..= .make it easy for a user to copy and
paste a string..."
=A0
again, I'd think it would be better to specify what = parsers MUST do, rather than saying some parsers
can be more leni= ent, so that the same string will create the same behavior regardless of th= e implementation
parsing it.
=A0
---------
similarly
=A0
"To limit this risk, implementations SHOULD NOT al= low use of this
=A0=A0 format except for well-defined usages such as sen= ding to link local
=A0=A0 addresses under prefix fe80::/10."
=A0
I= 9;d think it would be better to say MUST NOT, and also, to specify what it = should
do if it receives such a thing.
=A0
Ra= dia
=A0


=A0
=A0
=A0

=A0
=A0
= =A0
=A0

=A0
=A0
=A0
--089e0118499ca4e98904cf23b47c-- From brian.e.carpenter@gmail.com Thu Nov 22 23:50:30 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3030721F8872; Thu, 22 Nov 2012 23:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.581 X-Spam-Level: X-Spam-Status: No, score=-101.581 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO12qe9XL1Ua; Thu, 22 Nov 2012 23:50:29 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF4F921F8878; Thu, 22 Nov 2012 23:50:27 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so299655wgb.13 for ; Thu, 22 Nov 2012 23:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WXWx8xYSJskGtNJ+/mUriu5QwTEGpzbL5egm0LK47ck=; b=maVURukA4aEGD2sfryGqfrXKGE+NBIm2aloPX7Y0CUdfel1L3JDm8Fd3dbtzIXej9p oQ8oOTB2fAouyPR7TCQEBuhKClZNT/tARsqFnhyeAJOb0S6b/A0gW2Ch/Yuy75V4aJOs t5U4XIps7dv1RbjSCUB+isnO+rUFJhZCxmF7k1v4oKvbNioAe2mTEYvjKuDMPl/0ND1t I6EdLeuV7Ect73r5aDhd74xr6GLuqxEdCuTsU9l5BnVxegxXPelh9Yhs322rE49VCUoI RPUbQB0IPS5M6RaTtIJrWtuRu+QQDnIN6okaQik3Hi89fm4wgRwYxsR5eC7wv0HAmswu 3msA== Received: by 10.180.87.40 with SMTP id u8mr8175462wiz.3.1353657016908; Thu, 22 Nov 2012 23:50:16 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-114.as13285.net. [2.102.219.114]) by mx.google.com with ESMTPS id bn7sm8288510wib.8.2012.11.22.23.50.14 (version=SSLv3 cipher=OTHER); Thu, 22 Nov 2012 23:50:15 -0800 (PST) Message-ID: <50AF2ABE.4020901@gmail.com> Date: Fri, 23 Nov 2012 07:50:22 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Radia Perlman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-uri-zoneid.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 07:50:30 -0000 Thanks Radia. The WG reached consensus on a SHOULD-based version. The whole issue of browser behaviour is contentious, so changing to MUST would be a WG issue, above my pay grade as a document editor. I will wait for instructions. Thnaks for the readability comments, we can work those in. Regards Brian On 23/11/2012 06:29, Radia Perlman 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 provides syntax for specifying a port within a URI for an > IPv6 link-local address. > I find no security-specific issues with this draft, but I do think the > clarity of the draft > could be improved a lot, and also, I think that the draft allows options of > what is or is not allowed, > which could cause confusion for a human using this, since some strings will > work sometimes. I think it would > be better to lock down what is and is not allowed. > > I'm not fond of the term "zone identifier" (I had to do some Internet > searching to figure out what it was). It would > only take a sentence to explain it in this draft. Admittedly, not many > people will be reading this draft out of > context (like me). > > An example of where the wording is needlessly hard to read, and where I > think the rule should be a MUST: > > " A SHOULD contain only ASCII characters classified > in RFC 3986 as "unreserved", which > conveniently excludes "]" in order > to simplify parsing." > > That wording could mean that ] is reserved or it could mean that it is not > reserved. > Turns out (by referring to RFC 3986) "]" is actually reserved. > And also, with my preference for specifying mandatory behavior rather than > recommendation... > perhaps saying something like > > " A MUST NOT contain ASCII characters classified > in RFC 3986 as "reserved". The > character "]" is reserved, so MUST NOT > be used in the zone ID. > > > --------- > Again, > "The rules in [RFC5952 ] SHOULD be > applied in producing URIs." > Why not MUST be applied? > > ---------- > "we recommend that URI parsers accept bare "%" signs...make it easy for a > user to copy and > paste a string..." > > again, I'd think it would be better to specify what parsers MUST do, rather > than saying some parsers > can be more lenient, so that the same string will create the same behavior > regardless of the implementation > parsing it. > > --------- > similarly > > "To limit this risk, implementations SHOULD NOT allow use of this > format except for well-defined usages such as sending to link local > addresses under prefix fe80::/10." > > I'd think it would be better to say MUST NOT, and also, to specify what it > should > do if it receives such a thing. > > Radia > From barryleiba@gmail.com Fri Nov 23 06:34:11 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360C821F873C; Fri, 23 Nov 2012 06:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjbMqjwZM3Uk; Fri, 23 Nov 2012 06:34:10 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB3D421F85B6; Fri, 23 Nov 2012 06:34:09 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1494639vbb.31 for ; Fri, 23 Nov 2012 06:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HCGmH85Ti5optptdWvKivL+Z7zSio6BhADdQZEbvXsE=; b=S3eip5xdiOK5L+qVjJVQy7q4GS0t1Ga+7okWnjLHnyVpjodj96GjVnUAFYLtFD3Bol onUOpOguMIzryIrNhmygEKkQMaoXU4pqYsXVKqvtcQzVp1HOSgTddnJWKzDCivyAc9YW OvP3rpKGIsx/VjR6ihW8k+T7KT2lUCkxxsXyvvrTk8fTHSTEmYQg+dQy975xLwUN43eG SLXr8hJeq+0GQA24Bqi+hMWJkrgUpoiHWG3sLGzO3UxNycKIfEQ/jb44k9svvf2RjhVb HADQU8n97CI1cUkR68NpL5QJbC7L2ZDDqSu4eSMy3uTmbsq81xarEwOFiTDlYl/1ER1u ub2g== MIME-Version: 1.0 Received: by 10.220.119.196 with SMTP id a4mr6173122vcr.19.1353680783528; Fri, 23 Nov 2012 06:26:23 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Fri, 23 Nov 2012 06:26:23 -0800 (PST) In-Reply-To: <50AF2ABE.4020901@gmail.com> References: <50AF2ABE.4020901@gmail.com> Date: Fri, 23 Nov 2012 09:26:23 -0500 X-Google-Sender-Auth: 9obyepydfbVT4Pd_IeuYk_law1U Message-ID: From: Barry Leiba To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec54ee94e3dd16e04cf2a5e37 Cc: "draft-ietf-6man-uri-zoneid.all@tools.ietf.org" , "secdir@ietf.org" , The IESG Subject: Re: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 14:34:11 -0000 --bcaec54ee94e3dd16e04cf2a5e37 Content-Type: text/plain; charset=ISO-8859-1 > > The WG reached consensus on a SHOULD-based version. The whole issue > of browser behaviour is contentious, so changing to MUST would be > a WG issue, above my pay grade as a document editor. I will wait > for instructions. > Could you 1: give us some background on the discussion that resulted in SHOULD instead of MUST, and 2: consider adding explanations of when it would be appropriate to not do a SHOULD? For 2, above, there's a great difference between "SHOULD do x unless there's some reason that it's impossible in this implementation" and "SHOULD do x unless you don't happen to agree with it." I'd like to try to tease those apart. Barry --bcaec54ee94e3dd16e04cf2a5e37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The WG reached consensus on a SHOULD-based v= ersion. The whole issue
of browser behaviour is contentious, so changing to MUST would be
a WG issue, above my pay grade as a document editor. I will wait
for instructions.

Could you

1: give= us some background on the discussion that resulted in SHOULD instead of MU= ST, and

2: consider adding explanations of when it= would be appropriate to not do a SHOULD?

For 2, above, there's a great difference between &q= uot;SHOULD do x unless there's some reason that it's impossible in = this implementation" and "SHOULD do x unless you don't happen= to agree with it." =A0I'd like to try to tease those apart.

Barry=A0
--bcaec54ee94e3dd16e04cf2a5e37-- From brian.e.carpenter@gmail.com Fri Nov 23 06:50:34 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5387A21F849E; Fri, 23 Nov 2012 06:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.584 X-Spam-Level: X-Spam-Status: No, score=-101.584 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8GRBOie9hDh; Fri, 23 Nov 2012 06:50:32 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71B1721F8446; Fri, 23 Nov 2012 06:50:30 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so5862089eek.31 for ; Fri, 23 Nov 2012 06:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lGW9QXEg3l9WbnVronU3KPoJ9/l3+xY6oxdcRpFui2I=; b=XhL/tMCwLBOqWiYmn6t39P8NoIc4tiENDkxlemi3rKfDujO23caba7JnmTAxZW/RR3 GIHzYu0+JlybXlP65M1/sw50MWmWIssaEOo+/ScmXCkY1yUQD8ceiUB0EtHH6gEvrwKV GTbv+Q+UPaWuTFrjR4QeGE9d8jfEBwRBmmWWmOre+IidiUADjPU8sVc2QX9DL5cUVfVk brsH28YCUhyKVPou7Q52nFrxuzmZ5DhmjV2bAMLJnnixpK7J6Drdpj0n7bM51Nd32umb u9qHyDOB8YfdEcwjvpBXyL8/OEYHFA8ktypb7IARwxg3QksAUPOtjF8cpLZEIvJKCT1Z eHPA== Received: by 10.14.194.72 with SMTP id l48mr14486838een.9.1353682229488; Fri, 23 Nov 2012 06:50:29 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-114.as13285.net. [2.102.219.114]) by mx.google.com with ESMTPS id a44sm14050901eeo.7.2012.11.23.06.50.27 (version=SSLv3 cipher=OTHER); Fri, 23 Nov 2012 06:50:28 -0800 (PST) Message-ID: <50AF8D42.50106@gmail.com> Date: Fri, 23 Nov 2012 14:50:42 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Barry Leiba References: <50AF2ABE.4020901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-6man-uri-zoneid.all@tools.ietf.org" , "secdir@ietf.org" , The IESG Subject: Re: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 14:50:34 -0000 On 23/11/2012 14:26, Barry Leiba wrote: >> The WG reached consensus on a SHOULD-based version. The whole issue >> of browser behaviour is contentious, so changing to MUST would be >> a WG issue, above my pay grade as a document editor. I will wait >> for instructions. >> > > Could you > > 1: give us some background on the discussion that resulted in SHOULD > instead of MUST, and I don't recall it being explicitly discussed - what I meant is that this is the text that got through WG last call and post-last-call discussion, without dissent. > 2: consider adding explanations of when it would be appropriate to not do a > SHOULD? Yes, this is one of the things I look for when reviewing documents, too ;-) > For 2, above, there's a great difference between "SHOULD do x unless > there's some reason that it's impossible in this implementation" and > "SHOULD do x unless you don't happen to agree with it." I'd like to try to > tease those apart. I'm not a browser implementor, but as far as I can tell, there is a strong tendency in that community to respect the law of least user astonishment, so my very personal interpretation is "you SHOULD do this unless experience shows that it will confuse the user." However, I think the real interpretation in this case is closer to your first one - do this, because it helps the user, unless your implementation makes this unreasonable. Very much IMHO. Brian From jsalowey@cisco.com Sat Nov 24 17:19:46 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C6721F8594; Sat, 24 Nov 2012 17:19:46 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqWnaVF-1ULu; Sat, 24 Nov 2012 17:19:46 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 168B621F8550; Sat, 24 Nov 2012 17:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2179; q=dns/txt; s=iport; t=1353806386; x=1355015986; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=t6nI5hX0Ag2vqPBNl0JPeeuO4dJ7nvHMqLk+Dh2AZAs=; b=j9Cxv9TfUtxVEzaNW65+xpzdHfwaL43+MEswJnLalpNU2/USCMsWQQwz 0ZMU6P8khRPGwVGY6R9QEa52JQl/ZAXrjSSPf6vm2bAribz1E3GzBCvxn 24sQBcw8uHVo832iZXLEZTNXzTnMQ6UO8/XsZ3q6B1Llt/6XBtD3AGp5N M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADRxsVCtJV2Z/2dsb2JhbABEwD0Wc4IgAQQ6UQEqFEInBAEaiAW9J5AXYQOmRYJvgh0 X-IronPort-AV: E=McAfee;i="5400,1158,6906"; a="145599475" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 25 Nov 2012 01:19:45 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAP1Jjbm012440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Nov 2012 01:19:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.63]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Sat, 24 Nov 2012 19:19:45 -0600 From: "Joseph Salowey (jsalowey)" To: "secdir@ietf.org" , "draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org" , The IESG Thread-Topic: Secdir review of draft-ietf-softwire-6rd-radius-attrib-07 Thread-Index: AQHNyqrzvpodTOJq1EuwowbWoRgUow== Date: Sun, 25 Nov 2012 01:19:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-softwire-6rd-radius-attrib-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 01:19:47 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. I believe the document is almost ready for publication. =20 The following are significant issues that need to be addressed: 1. A RADIUS message used for call-check does not contain any information t= hat would authenticate the request. Therefore RADIUS messages using the 6r= d attribute MUST include a message-authenticator attribute or another attri= bute that is capable of authenticating the RAIDUS packet. =20 2. I'm not so familiar with the deployment scenario here so I have a ques= tion. Is it possible that the BNG was involved in a previous transaction w= ith the AAA server to authenticate a user? If this is the case then the B= NG may have received a state attribute in the access-accept message. Retu= rning this state attribute to the AAA server allows the AAA server to link = the 6rd request with the original authentication transaction. If this is= a possible scenario the document should specify this since state attribute= s are not typically used with the call-check service. Also if its the case= that there could have been a related previous authentication session it se= ems that it should be possible to include this attribute in an access-reque= st as part of the authentication exchange. =20 3. It was not clear in the specification what is sent in the access-reques= t message is the BNG is looking to get a IPv6-6rd-configuration attribute i= n the access accept. It seems that you would need to send this attribute i= n the request if you expected it in the response or else the AAA server wou= ld not be able to un ambiguously be able to service the request; there are = other uses for the call-check service. I think you should specify that th= e 6rd attribute must be in the request if you want to see it in the respons= e. =20 Cheers, Joe From aland@deployingradius.com Sun Nov 25 06:18:08 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B290721F84D5; Sun, 25 Nov 2012 06:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj++bYH214zc; Sun, 25 Nov 2012 06:18:08 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E288821F8466; Sun, 25 Nov 2012 06:18:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 0DB9D22408BE; Sun, 25 Nov 2012 15:18:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSclztXGp-vd; Sun, 25 Nov 2012 15:18:03 +0100 (CET) Received: from Thor-2.local (206-47-94-208.dsl.ncf.ca [206.47.94.208]) by power.freeradius.org (Postfix) with ESMTPSA id BD02922403DE; Sun, 25 Nov 2012 15:18:02 +0100 (CET) Message-ID: <50B2289A.8060402@deployingradius.com> Date: Sun, 25 Nov 2012 09:18:02 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: The IESG , "draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-softwire-6rd-radius-attrib-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 14:18:08 -0000 Joseph Salowey (jsalowey) wrote: > 1. A RADIUS message used for call-check does not contain any information that would authenticate the request. Therefore RADIUS messages using the 6rd attribute MUST include a message-authenticator attribute or another attribute that is capable of authenticating the RAIDUS packet. I missed that. I agree with the requirement for a Message-Authenticator. > 2. I'm not so familiar with the deployment scenario here so I have a question. Is it possible that the BNG was involved in a previous transaction with the AAA server to authenticate a user? If this is the case then the BNG may have received a state attribute in the access-accept message. Returning this state attribute to the AAA server allows the AAA server to link the 6rd request with the original authentication transaction. If this is a possible scenario the document should specify this since state attributes are not typically used with the call-check service. Also if its the case that there could have been a related previous authentication session it seems that it should be possible to include this attribute in an access-request as part of the authentication exchange. I *think* that the answer here is "no". The document previously used Service-Type = Authorize-Only and a State attribute. After some discussion, it was decided to change that to Call-Check, because there was no way to obtain a State attribute. > 3. It was not clear in the specification what is sent in the access-request message is the BNG is looking to get a IPv6-6rd-configuration attribute in the access accept. It seems that you would need to send this attribute in the request if you expected it in the response or else the AAA server would not be able to un ambiguously be able to service the request; there are other uses for the call-check service. I think you should specify that the 6rd attribute must be in the request if you want to see it in the response. That would probably be good. From bernard_aboba@hotmail.com Sun Nov 25 12:00:33 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA64521F8658; Sun, 25 Nov 2012 12:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOssbmuidoE7; Sun, 25 Nov 2012 12:00:32 -0800 (PST) Received: from blu0-omc4-s37.blu0.hotmail.com (blu0-omc4-s37.blu0.hotmail.com [65.55.111.176]) by ietfa.amsl.com (Postfix) with ESMTP id F089321F8683; Sun, 25 Nov 2012 12:00:31 -0800 (PST) Received: from BLU002-W217 ([65.55.111.135]) by blu0-omc4-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Nov 2012 12:00:31 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_1d696ece-3a08-4474-ba8e-6a3d8c3075ec_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" Date: Sun, 25 Nov 2012 12:00:30 -0800 Importance: Normal In-Reply-To: <50B2289A.8060402@deployingradius.com> References: , <50B2289A.8060402@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2012 20:00:31.0027 (UTC) FILETIME=[85B9B830:01CDCB47] Cc: "radext@ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-softwire-6rd-radius-attrib-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 20:00:33 -0000 --_1d696ece-3a08-4474-ba8e-6a3d8c3075ec_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Joseph Salowey (jsalowey) wrote: >Therefore RADIUS messages using the 6rd attribute MUST include a =0A= message-authenticator attribute or another attribute that is capable of =0A= authenticating the RADIUS packet. =20 >=20 > I missed that. I agree with the requirement for a Message-Authenticato= r. [BA]=0A= Yes=2C as currently specified the Access-Request is not authenticated or = =0A= integrity protected=2C and is therefore susceptible to forgery. =20 > > 1. A RADIUS message used for call-check does not contain any informati= on that would authenticate the request. =20 [BA] There isn't even any information with which to authorize the request. = The "Call Check" Service-Type was designed for situations where authorizat= ion can be determined via the Called-Station-Id or Calling-Station-Id attri= butes=2C which originally contained telephone numbers. In RFC 3580=2C Call= ed/Calling-Station-Id could also contain a MAC address=2C but the principle= was similar -- an unique (non-authenticated) identifier which could be use= d to determine whether a call was authorized. Here is what RFC 2865 Sectio= n 5.6 says about Call Check: Call Check Used by the NAS in an Access-Request packet to=0A= indicate that a call is being received and=0A= that the RADIUS server should send back an=0A= Access-Accept to answer the call=2C or an=0A= Access-Reject to not accept the call=2C=0A= typically based on the Called-Station-Id or=0A= Calling-Station-Id attributes. It is=0A= recommended that such Access-Requests use the=0A= value of Calling-Station-Id as the value of=0A= the User-Name. However=2C this document does not say anything about use of the Calling-Sta= tion-Id or Called-Station-Id attributes=2C or the value of the User-Name at= tribute. Given that=2C the use of Service-Type =3D "Call Check" would not = seem to apply. > > 2. I'm not so familiar with the deployment scenario here so I have a = question. Is it possible that the BNG was involved in a previous transacti= on with the AAA server to authenticate a user? If this is the case then t= he BNG may have received a state attribute in the access-accept message. = Returning this state attribute to the AAA server allows the AAA server to l= ink the 6rd request with the original authentication transaction. If thi= s is a possible scenario the document should specify this since state attri= butes are not typically used with the call-check service. Also if its the = case that there could have been a related previous authentication session i= t seems that it should be possible to include this attribute in an access-r= equest as part of the authentication exchange. =20 >=20 > I *think* that the answer here is "no". The document previously used > Service-Type =3D Authorize-Only and a State attribute. After some > discussion=2C it was decided to change that to Call-Check=2C because ther= e > was no way to obtain a State attribute. [BA] As I understand it=2C at least one of the scenarios described in the d= ocument would involve the retrieval of DHCP information along with a user a= uthentication. In such a scenario=2C why would either Authorize-Only or Ca= ll Check be needed? > 3. It was not clear in the specification what is sent in the access-requ= est message is the BNG is looking to get a IPv6-6rd-configuration attribute= in the access accept. It seems that you would need to send this attribute= in the request if you expected it in the response or else the AAA server w= ould not be able to un-ambiguously be able to service the request=3B there = are other uses for the call-check service. I think you should specify tha= t the 6rd attribute must be in the request if you want to see it in the res= ponse. =20 >=20 [BA] Yes. Otherwise the RADIUS server would not know that an IPv6-6rd-conf= iguration attribute was needed. = --_1d696ece-3a08-4474-ba8e-6a3d8c3075ec_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B Joseph Salowey (= jsalowey) wrote:

>=3BTherefore RADIUS messages using the 6rd attri= bute MUST include a =0A= message-authenticator attribute or another attribute that is capable of =0A= authenticating the RADIUS packet.
>=3B
>=3B I missed that. = I agree with the requirement for a Message-Authenticator.

[BA]=0A= Yes=2C as currently specified the Access-Request is not authenticated or = =0A= integrity protected=2C and is therefore susceptible to forgery. =3B
>=3B >=3B 1. A RADIUS message used for call-check does not contai= n any information that would authenticate the request.

[BA] There = isn't even any information with which to authorize the request. =3B The= "Call Check" Service-Type was designed for situations where authorization = can be determined via the Called-Station-Id or Calling-Station-Id attribute= s=2C which originally contained telephone numbers. =3B In RFC 3580=2C C= alled/Calling-Station-Id could also contain a MAC address=2C but the princi= ple was similar -- an unique (non-authenticated) identifier which could be = used to determine whether a call was authorized. =3B Here is what RFC 2= 865 Section 5.6 says about Call Check:

     C=
all Check          Used by the NAS in an Access-Request packet to=0A=
                          indicate that a call is being received and=0A=
                          that the RADIUS server should send back an=0A=
                          Access-Accept to answer the call=2C or an=0A=
                          Access-Reject to not accept the call=2C=0A=
                          typically based on the Called-Station-Id or=0A=
                          Calling-Station-Id attributes.  It is=0A=
                          recommended that such Access-Requests use the=0A=
                          value of Calling-Station-Id as the value of=0A=
                          the User-Name.

However=2C this document = does not say anything about use of the Calling-Station-Id or Called-Station= -Id attributes=2C or the value of the User-Name attribute. =3B Given th= at=2C the use of Service-Type =3D "Call Check" would not seem to apply.
=
>=3B >=3B 2. I'm not so familiar with the deployment scenario her= e so I have a question. Is it possible that the BNG was involved in a prev= ious transaction with the AAA server to authenticate a user? If this is t= he case then the BNG may have received a state attribute in the access-acce= pt message. Returning this state attribute to the AAA server allows the A= AA server to link the 6rd request with the original authentication transact= ion. If this is a possible scenario the document should specify this sin= ce state attributes are not typically used with the call-check service. Al= so if its the case that there could have been a related previous authentica= tion session it seems that it should be possible to include this attribute = in an access-request as part of the authentication exchange.
>=3B >=3B I *think* that the answer here is "no". The document previously= used
>=3B Service-Type =3D Authorize-Only and a State attribute. Aft= er some
>=3B discussion=2C it was decided to change that to Call-Check= =2C because there
>=3B was no way to obtain a State attribute.

= [BA] As I understand it=2C at least one of the scenarios described in the d= ocument would involve the retrieval of DHCP information along with a user a= uthentication. =3B In such a scenario=2C why would either Authorize-Onl= y or Call Check be needed?

>=3B 3. It was not clear in the specif= ication what is sent in the access-request message is the BNG is looking to= get a IPv6-6rd-configuration attribute in the access accept. It seems tha= t you would need to send this attribute in the request if you expected it i= n the response or else the AAA server would not be able to un-ambiguously b= e able to service the request=3B there are other uses for the call-check se= rvice. I think you should specify that the 6rd attribute must be in the r= equest if you want to see it in the response.
>=3B

[BA] Yes= . =3B Otherwise the RADIUS server would not know that an IPv6-6rd-confi= guration attribute was needed.
= --_1d696ece-3a08-4474-ba8e-6a3d8c3075ec_-- From aland@deployingradius.com Sun Nov 25 15:01:34 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8E821F846D; Sun, 25 Nov 2012 15:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiaZSk2OYOpQ; Sun, 25 Nov 2012 15:01:33 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B62021F846C; Sun, 25 Nov 2012 15:01:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 85ACF22408BE; Mon, 26 Nov 2012 00:00:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkcW+HC8HDtp; Mon, 26 Nov 2012 00:00:32 +0100 (CET) Received: from Thor-2.local (206-47-94-208.dsl.ncf.ca [206.47.94.208]) by power.freeradius.org (Postfix) with ESMTPSA id 1F95E22403DE; Mon, 26 Nov 2012 00:00:31 +0100 (CET) Message-ID: <50B2A30E.4020605@deployingradius.com> Date: Sun, 25 Nov 2012 18:00:30 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: , <50B2289A.8060402@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "iesg@ietf.org" , "draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] [radext] Secdir review of draft-ietf-softwire-6rd-radius-attrib-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 23:01:34 -0000 Bernard Aboba wrote: > [BA] There isn't even any information with which to authorize the > request. The "Call Check" Service-Type was designed for situations > where authorization can be determined via the Called-Station-Id or > Calling-Station-Id attributes, which originally contained telephone > numbers. The issue I have is what else to use. IIRC, I suggested a new Service-Type at one point. But that didn't seem to fly. > [BA] As I understand it, at least one of the scenarios described in the > document would involve the retrieval of DHCP information along with a > user authentication. In such a scenario, why would either > Authorize-Only or Call Check be needed? It would seem useful to have a Service-Type in the packet. The alternative would be to delete it entirely. Alan DeKok. From radiaperlman@gmail.com Tue Nov 27 16:14:55 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC1E21F866F; Tue, 27 Nov 2012 16:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyY8dJGS1n2e; Tue, 27 Nov 2012 16:14:55 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAC921F8650; Tue, 27 Nov 2012 16:14:54 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5715543vbb.31 for ; Tue, 27 Nov 2012 16:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zpf0sFlhEcfqRaoGIRiS/rBgtkV1Fs9kfm44mBnbG6w=; b=uSuvbkclnV/wrEMagGYRpEElvjBtXNwB/+LHCZ7d0LuGkB0vVpAtrk9X17V8n47v9i Exbrnd+aVWaDitnfxerckFgQq77GVPWD/DOLamK9gLaKNHcQSkMBqIC3WDFEwVKED1k4 wed5hoCngqX3UjQSybfXFuqmBpzKidWVSSuzF2l2DlRJF5jQ3lzb23iQGD8nRrjRi33Z p5DT8NLoNayIQBxKwUoiN08E3OIFWvRyykTUgyYScwTsLUdydnlZdKVESjrMqjFTO2l/ J2NOgw9kkm6bkJJ0xewP8t5ROyzEToj3yMj5P4sEbvuG6ryazwNpCJbKR7oMSt2wM/3f hGfw== MIME-Version: 1.0 Received: by 10.220.231.65 with SMTP id jp1mr730438vcb.30.1354061693890; Tue, 27 Nov 2012 16:14:53 -0800 (PST) Received: by 10.58.207.138 with HTTP; Tue, 27 Nov 2012 16:14:53 -0800 (PST) In-Reply-To: <50AF8D42.50106@gmail.com> References: <50AF2ABE.4020901@gmail.com> <50AF8D42.50106@gmail.com> Date: Tue, 27 Nov 2012 16:14:53 -0800 Message-ID: From: Radia Perlman To: Brian E Carpenter Content-Type: multipart/alternative; boundary=14dae9cdc87144afac04cf830e9a Cc: "draft-ietf-6man-uri-zoneid.all@tools.ietf.org" , Barry Leiba , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 00:14:55 -0000 --14dae9cdc87144afac04cf830e9a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 23, 2012 at 6:50 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 23/11/2012 14:26, Barry Leiba wrote: > >> The WG reached consensus on a SHOULD-based version. The whole issue > >> of browser behaviour is contentious, so changing to MUST would be > >> a WG issue, above my pay grade as a document editor. I will wait > >> for instructions. > >> > > > > Could you > > > > 1: give us some background on the discussion that resulted in SHOULD > > instead of MUST, and > > I don't recall it being explicitly discussed - what I meant is that > this is the text that got through WG last call and post-last-call > discussion, without dissent. > Often, in my observation, lack of discussion doesn't necessarily mean people are happy with the idea. It often (usually?) means they haven't read it. I think it would be good to have an explicit discussion in the WG, not on the entire draft, but on specifically, whether the syntax should be standardized so that the same syntax works the same on all implementations, or whether there is some reason why it's important for implementers to have flexibility in how they interpret the string, and it's not so important that URIs work differently with different implementations. I'd be more convinced that people want it this way if there was discussion on the mailing list, focusing people exactly on this issue. (and I'm also curious about why the flexibility is important). Radia > > > 2: consider adding explanations of when it would be appropriate to not > do a > > SHOULD? > > Yes, this is one of the things I look for when reviewing documents, too ;-) > > > For 2, above, there's a great difference between "SHOULD do x unless > > there's some reason that it's impossible in this implementation" and > > "SHOULD do x unless you don't happen to agree with it." I'd like to try > to > > tease those apart. > > I'm not a browser implementor, but as far as I can tell, there is a strong > tendency in that community to respect the law of least user astonishment, > so my very personal interpretation is "you SHOULD do this unless experience > shows that it will confuse the user." However, I think the real > interpretation > in this case is closer to your first one - do this, because it helps the > user, unless your implementation makes this unreasonable. > > Very much IMHO. > > Brian > --14dae9cdc87144afac04cf830e9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 23, 2012 at 6:50 AM, Brian E= Carpenter <brian.e.carpenter@gmail.com> wrote:
On 23/11/2012 14:26, Barry Leiba wrote:
>> The WG reached consensus on a SHOULD-based version. The whole issu= e
>> of browser behaviour is contentious, so changing to MUST would be<= br> >> a WG issue, above my pay grade as a document editor. I will wait >> for instructions.
>>
>
> Could you
>
> 1: give us some background on the discussion that resulted in SHOULD > instead of MUST, and

I don't recall it being explicitly discussed - what I meant is th= at
this is the text that got through WG last call and post-last-call
discussion, without dissent.
=A0
Often, in m= y observation, lack of discussion doesn't necessarily mean people are h= appy with the idea.=A0 It often (usually?) means they haven't read it.<= /div>
=A0
I think it would be good to have an explicit discussion = in the WG, not on the entire draft, but on specifically, whether the syntax= should be standardized so that the same syntax works the same on all imple= mentations, or whether=A0there is some reason why it's important for im= plementers to have flexibility in how they interpret the string, and it'= ;s not so important that=A0URIs work differently with different implementat= ions.=A0 I'd be more convinced that people want it this way if there wa= s discussion on the mailing list, focusing people exactly on this issue.=A0= (and I'm also curious about why the flexibility is important).
=A0
Radia
=A0
=A0
=A0
=A0
=A0

> 2: consider adding explanations of when it would be appropriate to not= do a
> SHOULD?

Yes, this is one of the things I look for when reviewing documents, t= oo ;-)

> For 2, above, there's a great difference between "SHOULD do x= unless
> there's some reason that it's impossible in this implementatio= n" and
> "SHOULD do x unless you don't happen to agree with it." = =A0I'd like to try to
> tease those apart.

I'm not a browser implementor, but as far as I can tell, there is= a strong
tendency in that community to respect the law of least user astonishment, so my very personal interpretation is "you SHOULD do this unless exper= ience
shows that it will confuse the user." However, I think the real interp= retation
in this case is closer to your first one - do this, because it helps the user, unless your implementation makes this unreasonable.

Very much IMHO.

=A0 =A0 Brian

--14dae9cdc87144afac04cf830e9a-- From brian.e.carpenter@gmail.com Tue Nov 27 23:50:50 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7758121F845B; Tue, 27 Nov 2012 23:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYd8o0Z3eExv; Tue, 27 Nov 2012 23:50:50 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B56021F8458; Tue, 27 Nov 2012 23:50:49 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so2539934wgb.13 for ; Tue, 27 Nov 2012 23:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q9pUHFw6YmXrn9N8JnmY2t9NulPWLHRMXrJC3cpNh98=; b=W8isUYeECr5MIAgkKqQwUerFV3+m6K6KuMQw6mOgFE7eu6FHHjo7kfqNIr/fa1d4d8 zzyC5howkNJ0UMOgX2qBIXj3TZXn925eq6ZbmiPAdBLBPB0R1pG2FowXCZPXIqrht5UT twzoqj7a31W4xipe4YLt3V6jsx6eo2qPxjc5+qg2q/697oacitGJcueIcsaIiGCr/o5r YBEMZxAPj1CVzkz8iw2KY+uLBWGlK2W0Lt7hQNUalvRCOKVLm5BMcB9k9BqyPFuaRCJu gYAuWbMbY5faaK/m6/8FOoI2XDNo4IZp8E4yK8tQU0Gt+lJ1ZH3FV8cYHxCbrch4U4/G JRVg== Received: by 10.180.109.132 with SMTP id hs4mr27649425wib.1.1354089048074; Tue, 27 Nov 2012 23:50:48 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-221.as13285.net. [2.102.217.221]) by mx.google.com with ESMTPS id hv4sm5847925wib.0.2012.11.27.23.50.46 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 23:50:47 -0800 (PST) Message-ID: <50B5C25A.1010102@gmail.com> Date: Wed, 28 Nov 2012 07:50:50 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Radia Perlman References: <50AF2ABE.4020901@gmail.com> <50AF8D42.50106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-6man-uri-zoneid.all@tools.ietf.org" , Barry Leiba , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 07:50:50 -0000 On 28/11/2012 00:14, Radia Perlman wrote: > On Fri, Nov 23, 2012 at 6:50 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 23/11/2012 14:26, Barry Leiba wrote: >>>> The WG reached consensus on a SHOULD-based version. The whole issue >>>> of browser behaviour is contentious, so changing to MUST would be >>>> a WG issue, above my pay grade as a document editor. I will wait >>>> for instructions. >>>> >>> Could you >>> >>> 1: give us some background on the discussion that resulted in SHOULD >>> instead of MUST, and >> I don't recall it being explicitly discussed - what I meant is that >> this is the text that got through WG last call and post-last-call >> discussion, without dissent. >> > > Often, in my observation, lack of discussion doesn't necessarily mean > people are happy with the idea. It often (usually?) means they haven't > read it. > > I think it would be good to have an explicit discussion in the WG, not on > the entire draft, but on specifically, whether the syntax should be > standardized so that the same syntax works the same on all implementations, > or whether there is some reason why it's important for implementers to have > flexibility in how they interpret the string, and it's not so important > that URIs work differently with different implementations. I'd be more > convinced that people want it this way if there was discussion on the > mailing list, focusing people exactly on this issue. (and I'm also curious > about why the flexibility is important). I honestly think that discussing that in 6man is pointless. The issue is the one I already raised on the IETF list: the user input box on a browser is one thing, the URI on the wire is another, and in between there is a heuristic. I don't see what a single IETF WG can do about this other than bemoaning it, because each browser implementer comes up with their own heuristic. (I certainly didn't realise how annoying this is before working on this draft.) Brian > > Radia > > > > > > >>> 2: consider adding explanations of when it would be appropriate to not >> do a >>> SHOULD? >> Yes, this is one of the things I look for when reviewing documents, too ;-) >> >>> For 2, above, there's a great difference between "SHOULD do x unless >>> there's some reason that it's impossible in this implementation" and >>> "SHOULD do x unless you don't happen to agree with it." I'd like to try >> to >>> tease those apart. >> I'm not a browser implementor, but as far as I can tell, there is a strong >> tendency in that community to respect the law of least user astonishment, >> so my very personal interpretation is "you SHOULD do this unless experience >> shows that it will confuse the user." However, I think the real >> interpretation >> in this case is closer to your first one - do this, because it helps the >> user, unless your implementation makes this unreasonable. >> >> Very much IMHO. >> >> Brian >> > From vincent.roca@inria.fr Wed Nov 28 06:34:35 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6921421F880F; Wed, 28 Nov 2012 06:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oxsQjAs2dZA; Wed, 28 Nov 2012 06:34:32 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBC621F8802; Wed, 28 Nov 2012 06:34:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,179,1355094000"; d="scan'208";a="164091057" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 28 Nov 2012 15:34:29 +0100 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Nov 2012 15:34:29 +0100 Message-Id: <6AF80A4F-EA0A-4E09-B304-043066124E4E@inria.fr> To: IESG IESG , secdir@ietf.org, draft-ietf-netext-pmipv6-sipto-option.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] Secdir review of draft-ietf-netext-pmipv6-sipto-option-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 14:34:35 -0000 Hello, 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 is a small document that describes PMIPv6 options to handle traffic offloading. Taken alone, the "security considerations" section would not be sufficient. However the RFC5213 (PMIPv6) provides the required security guidelines. In particular it clarifies that the use of IPsec is recommended between the MAG and LMA for signaling messages. The present document therefore inherits from these recommendations. I therefore agree with the authors. A remark. It is said: "This option is carried like any other mobility header option as specified in [RFC5213] and does not require any special security considerations." It's misleading IMHO. This option does require security considerations since an attacker, by sending fake signaling messages, may prevent a mobile network from offloading traffic which may lead to a DoS. You'd better say something like: "This option is carried like any other mobility header option as specified in [RFC5213]. Therefore it inherits from [RFC5213] its security guidelines and does not require any additional security considerations." Typos: Section 1: s/its only about IPv4/it is only about IPv4/ Cheers, Vincent From kivinen@iki.fi Thu Nov 29 03:29:08 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C1B21F893C for ; Thu, 29 Nov 2012 03:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkrgPJY9Ppgj for ; Thu, 29 Nov 2012 03:29:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1968821F89CD for ; Thu, 29 Nov 2012 03:29:06 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qATBT1Va012679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Nov 2012 13:29:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qATBSwbl004885; Thu, 29 Nov 2012 13:28:58 +0200 (EET) 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: <20663.18170.381767.293274@fireball.kivinen.iki.fi> Date: Thu, 29 Nov 2012 13:28:58 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 29 Nov 2012 11:29:08 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Brian Weis is next in the rotation. For telechat 2012-11-29 Reviewer LC end Draft Dave Cridland T 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-14 For telechat 2012-12-13 Leif Johansson T 2012-11-26 draft-ietf-mediactrl-mrb-16 David Waltermire T 2012-12-10 draft-ietf-tcpm-initcwnd-06 Glen Zorn T 2012-10-25 draft-leiba-3777upd-eligibility-05 For telechat 2012-12-20 Carl Wallace T - draft-ietf-tcpm-experimental-options-03 Last calls and special requests: Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2012-10-22 draft-ietf-fecframe-simple-rs-05 Julien Laganier 2012-11-19 draft-ietf-karp-routing-tcp-analysis-05 Russ Mundy 2012-11-12 draft-ietf-mmusic-sdp-media-capabilities-15 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-12 Sandy Murphy 2012-11-26 draft-nir-ipsecme-erx-07 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-08 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Yaron Sheffer 2012-12-12 draft-ietf-6renum-enterprise-04 Ondrej Sury 2012-12-12 draft-ietf-6renum-static-problem-02 Tina TSOU 2012-12-11 draft-ietf-avt-rtp-evrc-nw-08 Sam Weiler 2012-12-26 draft-salgueiro-vcarddav-kind-device-06 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 -- kivinen@iki.fi