From n@arifumi.net Wed Jun 5 06:51:15 2013 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 C138621F9B4B for ; Wed, 5 Jun 2013 06:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd-m1Ljdl2sM for ; Wed, 5 Jun 2013 06:51:10 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id A441D21F9AB4 for ; Wed, 5 Jun 2013 06:51:09 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so1867602pdj.0 for ; Wed, 05 Jun 2013 06:51:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=+aN40ip5XcasqfQov6zmxaodHuDfN/HlsT39BGpD0Kg=; b=R8TBLxDQez8lG42FvjZAS5CHoTe634Xk2qkSkoQ9Yz6uz0dMfBGutKGB/UCL9tKNPw M7wY4p47dWOQq8eTJnJ3MkgiGnMzJONrkDNYj3ECglUdKSfkOYenB2dck4UbX7E8n6nB XsrbyO5dcV8cEPbJMzPXznhIo7nVXME4YYfRvCorisH0Fd7AuiMTnt2HofDiOcg/u7WZ PRWNMt7V4a9j+40AohBr0/wlbxp+063EDZbDthyMhyxl1y4hKQGBv2v2tFVDtiEEmK+G PJ3uveg237TJxfI4ovhcty43SMq4q4MckX3l4kN3EvxUIA8WRbgjwmzlndE2kHDrTnHG WaQA== MIME-Version: 1.0 X-Received: by 10.66.162.67 with SMTP id xy3mr33709276pab.94.1370440269322; Wed, 05 Jun 2013 06:51:09 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.194.198 with HTTP; Wed, 5 Jun 2013 06:51:09 -0700 (PDT) X-Originating-IP: [118.21.146.144] In-Reply-To: References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> Date: Wed, 5 Jun 2013 22:51:09 +0900 X-Google-Sender-Auth: NKStlTe0Apla3rEYHHwBiXk5ky4 Message-ID: From: Arifumi Matsumoto To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=047d7b86e3e470d6a304de687d2c X-Gm-Message-State: ALoCoQkkwSj2jSpLQjx/9t9H/WwZVSCeaHyHpd0SonosV/yfAY1rt+9W3BLNPtwePOeRJMHZ/Mf1 Cc: "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 05 Jun 2013 13:51:16 -0000 --047d7b86e3e470d6a304de687d2c Content-Type: text/plain; charset=ISO-8859-1 Hi, did my previous e-mail get to you all ? 2013/5/28 Arifumi Matsumoto > Hi Dan, > I appreciate your review. > > Comments below. > > 2013/5/22 Dan Harkins > >> >> Hello, >> >> I have reviewed draft-ietf-6man-addr-select-opt 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. >> >> draft-ietf-6man-addr-select-opt defines address selection options >> for DHCPv6 that allow a network administrator to effect some >> control over address selection behavior of nodes on their sites. >> >> This sounds like a reasonably straightforward problem but as I >> read the draft it seemed like it might be have interoperability issues. >> I don't believe this draft is ready for advancement until these issues >> are resolved. >> >> For instance, while I think I understand the policy override of RFC >> 6724, having the Automatic Row Additions Flag be part of the address >> selection options seems problematic. If it is set to zero, then what are >> the semantics of such a message? "Here's an address selection option >> but don't you dare use it!"? What is the point? Me, as a node, can have >> this as part of my policy state which would allow me to ignore such >> an update but to have the bit be part of the option to update does >> not seem to make much sense. The semantics of the message needs >> to be explained much more clearly, or the bit needs to be removed >> from the message. >> > > If A flag is zero, it means Automatic Row Addition is indicated not to > perform. > If A flag is 1, it means it is up to the node. > > Even in the latter case, the Address Selection Option may contain other > information to the node, such as the policy table and other flags. > > Make sense ? > > If not, splitting the flag into another new sub-option makes sense to you ? > > >> >> Section 3.3 says, "Even if the received policy from one source is >> merged with one from another source, the effect of both policy are >> more or less changed." I don't understand how both policies are >> changed. And what does "more or less" mean? > > > I think that a policy table has its own unique meaning. Even single > insertion/deletion from the table makes the table different. > > For example, when adding a line, from one source, to the default policy > table below, > > Prefix Precedence Label > ::1/128 50 0 > ::/0 40 1 > ::ffff:0:0/96 35 4 > 2002::/16 30 2 > 2001::/32 5 5 > fc00::/7 3 13 > ::/96 1 3 > fec0::/10 1 11 > 3ffe::/16 1 12 > > makes > > Prefix Precedence Label > ::1/128 50 0 > ::/0 40 1 > ::ffff:0:0/96 35 4 > 2002::/16 30 2 > + 2003::/16 10 6 > 2001::/32 5 5 > fc00::/7 3 13 > ::/96 1 3 > fec0::/10 1 11 > 3ffe::/16 1 12 > > In this case, the prefix 2003::/16 has lower precendence than the default > policy table. And, the table contains a lot of policy that is not intended > by > the source who deliver single line of policy. > > > >> 3.3 also says, >> "It also should be noted that absence of the distributed policy from a >> certain network interface should not be treated as absence of policy >> itself, because it may mean preference for the default address >> selection policy." So I use the default address selection policy then, >> is that it? > > > I mean, there is no way to tell the network with no policy distribution > prefers default policy, or does not care about it. > The conclusion is "using the default policy should be safe", though. > > >> This whole section (3.3) screams out for some normative >> language since it sounds like it refers to behavioral changes on the >> node. >> > > Do you mean this section should have more SHOULDs and MUSTs ? > If so, on which part do you think should we put ? > > >> >> There is an "Implementation Consideration" mentioning that the >> label is passed as an unsigned integer. But it then goes on to say, >> "DHCPv6 clients SHOULD convert this label to a representation >> appropriate for the local implementation (e.g., string)." This has >> interoperability implications because it is not solely a local matter. >> The node may represent these things differently than the network >> administrator and the preference will not be done properly. RFC 6724 >> does not really define what the label is from what I can tell. It's >> used to just allow for policies to prefer a particular source address, >> S, with a particular destination address, D, if "Label(S) = Label(D)". >> But to pass a value over a network, and have it be used by the >> recipient, means that a canonical representation of "label" has to >> be defined. >> > > Maybe, I don't understand your point quite well. > As far as the one-to-one mapping in a node is performed between an > unsinged integer and representation format, I think there will not arise > interoperability issue, such that a policy has different meaning depending > on a receiving host. > > >> An appendix with examples would be most helpful! >> > > RFC 6724 has a lot of examples for policy table. > Do you think we need other examples, or just same ones ? > > >> >> Spelling nit: section 3.1 "The choice a SHOULD be default, as far as >> the policy table is not configured by the user." There's an extra >> word in there somewhere, or maybe there's some words missing, >> it's hard to understand what is being implied. >> > > It means the choice called "a" below should be default. > Maybe using parenthesis (a) makes it clearer ? > > Best regards, > > >> >> regards, >> >> Dan. >> >> >> > --047d7b86e3e470d6a304de687d2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

did my previous e-mail get to you al= l ?


2013/5= /28 Arifumi Matsumoto <arifumi@nttv6.net>
Hi Dan,
= I appreciate your review.
Comments below.

2013/5/22 Dan Harkins <dharkins@lounge.org>

=A0 Hello,

=A0 I have reviewed draft-ietf-6man-addr-select-opt as part of the
security directorate's =A0ongoing effort to review all IETF documents being processed by the IESG. =A0These comments were written primarily
for the benefit of the =A0security area directors. =A0Document editors and<= br> WG chairs should treat these comments just like any other last call
comments.

=A0 draft-ietf-6man-addr-select-opt defines address selection options
for DHCPv6 that allow a network administrator to effect some
control over address selection behavior of nodes on their sites.

=A0 This sounds like a reasonably straightforward problem but as I
read the draft it seemed like it might be have interoperability issues.
I don't believe this draft is ready for advancement until these issues<= br> are resolved.

=A0 For instance, while I think I understand the policy override of RFC
6724, having the Automatic Row Additions Flag be part of the address
selection options seems problematic. If it is set to zero, then what are the semantics of such a message? "Here's an address selection opti= on
but don't you dare use it!"? What is the point? Me, as a node, can= have
this as part of my policy state which would allow me to ignore such
an update but to have the bit be part of the option to update does
not seem to make much sense. The semantics of the message needs
to be explained much more clearly, or the bit needs to be removed
from the message.

If A flag= is zero, it means Automatic Row Addition is indicated not to perform.
<= /div>
If A flag is 1, it means it is up to the node.

Even in the latter case, the Address Selection Option may contain othe= r
information to the node, such as the policy table and other flag= s.

Make sense ?

If not, spli= tting the flag into another new sub-option makes sense to you ?
=A0

=A0 Section 3.3 says, "Even if the received policy from one source is<= br> merged with one from another source, the effect of both policy are
more or less changed." I don't understand how both policies are changed. And what does "more or less" mean?
I think that a policy table has its own unique meaning. Even s= ingle
insertion/deletion from the table= makes the table different.

For example, when adding a line, from one source, to the def= ault policy table below,

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      ::ffff:0:0/96         35     4
      2002::/16             30     2
      2001::/32              5     5
      fc00::/7               3    13
      ::/96                  1     3
      fec0::/10              1    11
      3ffe::/16              1    12
makes
      Prefix       =
 Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      ::ffff:0:0/96         35     4
      2002::/16             30     2
+     2003::/16             10    6=

     =A02001::/32              5     5
      fc00::/7               3    13
      ::/96                  1     3
      fec0::/10              1    11
      3ffe::/16              1    12
In this case, the prefix 2003::/1= 6 has lower precendence than the default
policy table. And, the table co= ntains a lot of policy that is not intended by
the source who deliver si= ngle line of policy.

=A0
3.3 also says,
"It also should be noted that absence of the distributed policy from a=
certain network interface should not be treated as absence of policy
itself, because it may mean preference for the default address
selection policy." So I use the default address selection policy then,=
is that it?

I mean, there is no way = to tell the network with no policy distribution
prefers defau= lt policy, or does not care about it.
The conclusion is "= ;using the default policy should be safe", though.
=A0
This whole section (3.3) screams out for some normative
language since it sounds like it refers to behavioral changes on the
node.

Do you mean this section sh= ould have more SHOULDs and MUSTs ?
If so, on which part do yo= u think should we put ?
=A0

=A0 There is an "Implementation Consideration" mentioning that th= e
label is passed as an unsigned integer. But it then goes on to say,
"DHCPv6 clients SHOULD convert this label to a representation
appropriate for the local implementation (e.g., string)." This has
interoperability implications because it is not solely a local matter.
The node may represent these things differently than the network
administrator and the preference will not be done properly. RFC 6724
does not really define what the label is from what I can tell. It's
used to just allow for policies to prefer a particular source address,
S, with a particular destination address, D, if "Label(S) =3D Label(D)= ".
But to pass a value over a network, and have it be used by the
recipient, means that a canonical representation of "label" has t= o
be defined.

Maybe, I don't un= derstand your point quite well.
As far as the one-to-one mapp= ing in a node is performed between an
unsinged integer and representatio= n format, I think there will not arise
interoperability issue, such that a policy has different meaning= depending
on a receiving host.
=A0
<= /div>
=A0 An appendix with examples would be most helpful!
<= br>
RFC 6724 has a lot of examples for policy table.
Do you think we need other examples, or just same ones ?
=A0

=A0 Spelling nit: section 3.1 "The choice a SHOULD be default, as far = as
the policy table is not configured by the user." There's an extra<= br> word in there somewhere, or maybe there's some words missing,
it's hard to understand what is being implied.
It means the choice called "a" below should be = default.
Maybe using parenthesis (a) makes it clearer ?

Best regards,
=A0

=A0 regards,

=A0 Dan.




--047d7b86e3e470d6a304de687d2c-- From dharkins@lounge.org Wed Jun 5 11:55:27 2013 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 B0A0321F9BD3; Wed, 5 Jun 2013 11:54:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLGzOkyqIvMD; Wed, 5 Jun 2013 11:54:35 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC2C21F9C04; Wed, 5 Jun 2013 11:54:19 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 63079A888008; Wed, 5 Jun 2013 11:54:02 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Jun 2013 11:54:02 -0700 (PDT) Message-ID: In-Reply-To: References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> Date: Wed, 5 Jun 2013 11:54:02 -0700 (PDT) From: "Dan Harkins" To: "Arifumi Matsumoto" 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 Cc: "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , secdir@ietf.org, iesg@ietf.org, Arifumi Matsumoto Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 05 Jun 2013 18:55:28 -0000 Hi, On Wed, June 5, 2013 6:51 am, Arifumi Matsumoto wrote: > Hi, > > did my previous e-mail get to you all ? No, it didn't; thanks for resending. > 2013/5/28 Arifumi Matsumoto > >> Hi Dan, >> I appreciate your review. >> >> Comments below. >> >> 2013/5/22 Dan Harkins >> >>> >>> Hello, >>> >>> I have reviewed draft-ietf-6man-addr-select-opt 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. >>> >>> draft-ietf-6man-addr-select-opt defines address selection options >>> for DHCPv6 that allow a network administrator to effect some >>> control over address selection behavior of nodes on their sites. >>> >>> This sounds like a reasonably straightforward problem but as I >>> read the draft it seemed like it might be have interoperability issues. >>> I don't believe this draft is ready for advancement until these issues >>> are resolved. >>> >>> For instance, while I think I understand the policy override of RFC >>> 6724, having the Automatic Row Additions Flag be part of the address >>> selection options seems problematic. If it is set to zero, then what >>> are >>> the semantics of such a message? "Here's an address selection option >>> but don't you dare use it!"? What is the point? Me, as a node, can have >>> this as part of my policy state which would allow me to ignore such >>> an update but to have the bit be part of the option to update does >>> not seem to make much sense. The semantics of the message needs >>> to be explained much more clearly, or the bit needs to be removed >>> from the message. >>> >> >> If A flag is zero, it means Automatic Row Addition is indicated not to >> perform. >> If A flag is 1, it means it is up to the node. So what is the purpose of sending someone a row for addition and saying "do not perform addition"? >> Even in the latter case, the Address Selection Option may contain other >> information to the node, such as the policy table and other flags. >> >> Make sense ? Not really. So what's the semantics of this other information if the flag is set to zero? "Here's some other stuff but don't use it either"? >> If not, splitting the flag into another new sub-option makes sense to >> you ? Why not just get rid of this flag. It's always "up to the node" whether it is willing to modify its own resources or not. >> >>> >>> Section 3.3 says, "Even if the received policy from one source is >>> merged with one from another source, the effect of both policy are >>> more or less changed." I don't understand how both policies are >>> changed. And what does "more or less" mean? >> >> >> I think that a policy table has its own unique meaning. Even single >> insertion/deletion from the table makes the table different. >> >> For example, when adding a line, from one source, to the default policy >> table below, >> >> Prefix Precedence Label >> ::1/128 50 0 >> ::/0 40 1 >> ::ffff:0:0/96 35 4 >> 2002::/16 30 2 >> 2001::/32 5 5 >> fc00::/7 3 13 >> ::/96 1 3 >> fec0::/10 1 11 >> 3ffe::/16 1 12 >> >> makes >> >> Prefix Precedence Label >> ::1/128 50 0 >> ::/0 40 1 >> ::ffff:0:0/96 35 4 >> 2002::/16 30 2 >> + 2003::/16 10 6 >> 2001::/32 5 5 >> fc00::/7 3 13 >> ::/96 1 3 >> fec0::/10 1 11 >> 3ffe::/16 1 12 >> >> In this case, the prefix 2003::/16 has lower precendence than the >> default >> policy table. And, the table contains a lot of policy that is not >> intended >> by >> the source who deliver single line of policy. If I add lines from one table to another I only change the latter. The former is not changed. And "more or less" is too vague. So how about rewriting that sentence to be: "Merging received policy into an existing policy changes the existing policy." although this statement seems so self-evident as to suggest just getting rid of the problematic text from 3.3 altogether. >> >>> 3.3 also says, >>> "It also should be noted that absence of the distributed policy from a >>> certain network interface should not be treated as absence of policy >>> itself, because it may mean preference for the default address >>> selection policy." So I use the default address selection policy then, >>> is that it? >> >> >> I mean, there is no way to tell the network with no policy distribution >> prefers default policy, or does not care about it. >> The conclusion is "using the default policy should be safe", though. Then I think you should say that directly. >> >>> This whole section (3.3) screams out for some normative >>> language since it sounds like it refers to behavioral changes on the >>> node. >>> >> >> Do you mean this section should have more SHOULDs and MUSTs ? >> If so, on which part do you think should we put ? How about: "In the absence of distributed policy for a certain network interface, the default address selection policy SHOULD be used." And get rid of the single SHOULD in the existing text that is followed by 1) and 2) and make two separate SHOULD statements: "A single-homed host SHOULD use default address selection options. Hosts that use advanced heuristics that are defined outside the scope of this document SHOULD use default address selection options." You say, "The above restrictions do not preclude implementations from providing configuration options to enable this option on a certain network interface." which could be changed to "Implementations MAY provide configuration options to enable this protocol on a per interface basis." if that is your intent. >>> >>> There is an "Implementation Consideration" mentioning that the >>> label is passed as an unsigned integer. But it then goes on to say, >>> "DHCPv6 clients SHOULD convert this label to a representation >>> appropriate for the local implementation (e.g., string)." This has >>> interoperability implications because it is not solely a local matter. >>> The node may represent these things differently than the network >>> administrator and the preference will not be done properly. RFC 6724 >>> does not really define what the label is from what I can tell. It's >>> used to just allow for policies to prefer a particular source address, >>> S, with a particular destination address, D, if "Label(S) = Label(D)". >>> But to pass a value over a network, and have it be used by the >>> recipient, means that a canonical representation of "label" has to >>> be defined. >>> >> >> Maybe, I don't understand your point quite well. >> As far as the one-to-one mapping in a node is performed between an >> unsinged integer and representation format, I think there will not arise >> interoperability issue, such that a policy has different meaning >> depending >> on a receiving host. I'm saying this has an impact on interoperability because there's no way to ensure that this option will be processed correctly. There is no way for the sender of this option to know how the recipient is representing labels locally and therefore there is no way for the sender to properly convey his intent in the option he sends. I may have existing policies where Label(A) = 0x31 and another where Label(B) = 0x01. Now I get an label in my address selection option that is an unsigned integer of the value 0x01. Should I convert it to a string, as the text says I SHOULD? Should I use ASCII? So then it will match Label(A)? Or should I use it directly and it therefore should match Label(B). I just don't think you can mention conversion here. The field has to be treated as an opaque blob or some canonical representation MUST be defined. >>> An appendix with examples would be most helpful! >>> >> >> RFC 6724 has a lot of examples for policy table. >> Do you think we need other examples, or just same ones ? Since this draft is about updating, or modifying, the policy table it would be nice to see a sample Address Selection Option with at least one, and preferably more, Address Selection Policy Table options and what receipt of that message would be to a sample policy table. Show a before policy table, the message that modifies it, and an after policy table. >>> >>> Spelling nit: section 3.1 "The choice a SHOULD be default, as far as >>> the policy table is not configured by the user." There's an extra >>> word in there somewhere, or maybe there's some words missing, >>> it's hard to understand what is being implied. >>> >> >> It means the choice called "a" below should be default. >> Maybe using parenthesis (a) makes it clearer ? That make more sense. Suggest removing the article then too. So make it "Choice (a) SHOULD be default...." regards, Dan. From radiaperlman@gmail.com Thu Jun 6 06:14:20 2013 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 6AB0E21F99D2; Thu, 6 Jun 2013 06:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FjAKgAqx359; Thu, 6 Jun 2013 06:14:19 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 36D8621F99C3; Thu, 6 Jun 2013 06:14:19 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id eb20so2563568lab.15 for ; Thu, 06 Jun 2013 06:14:18 -0700 (PDT) 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=6yVmIZlypMuBkZ5ZbiHlhKIU1Ir7e/Srg6qPOZ20ais=; b=aK2MzPona90hnLXDxCve8YPPSZl0F1wJ4cA+/3F6x07r0JuuVts2qY3v62iYCeisAY Xgrlxr8eP+hLx7cfR3eZhpM5lDoMTh0PhhCTUn6Yg81VpJDa6I9ZWTlDB5Vsrb6WXgIb 2qfes/KZ7fDvPhK9SMKl1uWtKsuOdv2BSJyE/aVOiuPKmJwgR3Z+uwOQbdQqVpJoT40p saU1eKRmXxVfwzeo+B4Qd64LgoR7MmqIdA3/dtnEX7M6PYtm8XqNf9v72F3elcXZ1YHR oJEZexJpzf/BA/8cwnpnobmJhfp7yt+wUZAf2TDGUCcY2PQURs6WgV4NXcO8MkFGuHNN hEYA== MIME-Version: 1.0 X-Received: by 10.112.142.73 with SMTP id ru9mr17256869lbb.22.1370524457975; Thu, 06 Jun 2013 06:14:17 -0700 (PDT) Received: by 10.112.69.8 with HTTP; Thu, 6 Jun 2013 06:14:17 -0700 (PDT) Date: Thu, 6 Jun 2013 06:14:17 -0700 Message-ID: From: Radia Perlman To: secdir@ietf.org, The IESG , draft-ietf-avtcore-avp-codecs@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c36c7a79454504de7c1746 Subject: [secdir] SECDIR review of draft-ietf-avtcore-avp-codecs-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: Thu, 06 Jun 2013 13:14:20 -0000 --001a11c36c7a79454504de7c1746 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 is a completely harmless editorial update of another document (RFC 3551] to replace the paragraph Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol. with Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload type 0 (PCMU). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol. Some environments REQUIRE support for PCMU. There are certainly no security implications (as correctly noted in this draft). My only question is...shouldn't this be an actual updated document, rather than a tiny document saying "replace this paragraph with this other paragraph"? Surely we wouldn't make this document an RFC rather than simply replacing RFC 3551 with an updated RFC? Radia --001a11c36c7a79454504de7c1746 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 ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors. =A0Document editors and WG chairs should treat these comments just li= ke any other last call comments.

This is a completely harmless editorial update of another do= cument (RFC 3551] to replace the paragraph

   Audio applications ope=
rating under this profile SHOULD, at a minimum,
   be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4).
   This allows interoperability without format negotiation and ensures
   successful negotiation with a conference control protocol.

=A0with

   Audio applications operating under thi=
s profile SHOULD, at a minimum,
   be able to send and/or receive payload type 0 (PCMU).  This allows
   interoperability without format negotiation and ensures successful
   negotiation with a conference control protocol.  Some environments
   REQUIRE support for PCMU.

There are certainly no security =
implications (as correctly noted in this draft).

My only question =
is...shouldn't this be an actual updated document, rather than a tiny d=
ocument saying "replace this paragraph with this other paragraph"=
? =A0Surely we wouldn't make this document an RFC rather than simply re=
placing RFC 3551 with an updated RFC?

Radia
--001a11c36c7a79454504de7c1746-- From clonvick@cisco.com Thu Jun 6 09:38:00 2013 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 D77D821F99AC; Thu, 6 Jun 2013 09:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiXvuVIX7HQw; Thu, 6 Jun 2013 09:37:54 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 89CDC21F99BA; Thu, 6 Jun 2013 09:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=688; q=dns/txt; s=iport; t=1370536674; x=1371746274; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=6aWxxrw/DjhjVX9mlbSZIqHuNiAv2kuxZF5v6pyLeh8=; b=jYv6SEho6EU+LAgm0qHF8w9I68S5rKtpGKJjkDf7ryBeAjitT0f+pM+6 3Urm1uO0UxoYSzEGKYc9Th+VOG0r10XNsPWL7E0zPaQZCrCvchTXKcXzw luKlCO4r8fZ7WBzPmmN34ycQfQq8eg/XBCC+HFn7dDkmohmkpEJMKZoRh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAH26sFGtJV2Z/2dsb2JhbABZgwm/d3gWdIIlAQQ6UQEqFEImAQQBGogFu3qPAYMyYQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208";a="219730681" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 06 Jun 2013 16:37:28 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r56GbRKm003632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 16:37:27 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 11:37:26 -0500 From: "Chris Lonvick (clonvick)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-mmusic-rfc2326bis-34 Thread-Index: Ac5i1CClI30rLRrtSr6OoqunYaYT0w== Date: Thu, 6 Jun 2013 16:37:26 +0000 Message-ID: <9BB92CB59918E1418A06FD4E3269FABE116A4737@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-mmusic-rfc2326bis-34 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, 06 Jun 2013 16:38:01 -0000 Hi,=0A= =0A= 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.=0A= =0A= This is a lengthy document and I did not have time to fully review it. I d= id review the Security Considerations section and found it to be well writt= en and thorough. I found no problems there and consider that it appropriat= ely covers the concepts in the document.=0A= =0A= Thanks,=0A= Chris=0A= =0A= =0A= From david.black@emc.com Thu Jun 6 16:04:08 2013 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 9E3CA21E8051 for ; Thu, 6 Jun 2013 16:04:08 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr8nMMnMTlWs for ; Thu, 6 Jun 2013 16:04:02 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD0D21E8050 for ; Thu, 6 Jun 2013 16:03:59 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r56N3bV4001440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 19:03:47 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 6 Jun 2013 19:03:17 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r56N3Gpu022814; Thu, 6 Jun 2013 19:03:16 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Thu, 6 Jun 2013 19:03:16 -0400 From: "Black, David" To: Stephen Kent Date: Thu, 6 Jun 2013 19:03:15 -0400 Thread-Topic: draft-ietf-storm-iser and IPsec version requirements Thread-Index: Ac27pdS7k0A1MNMdRSCXzEJZDT+W3SnYcgMw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712980CA080@MX15A.corp.emc.com> References: <507F45BE.2040900@bbn.com> <8D3D17ACE214DC429325B2B98F3AE7120E04B01F@MX15A.corp.emc.com> <50983EB5.2010501@bbn.com> In-Reply-To: <50983EB5.2010501@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712980CA080MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "mkosjc@gmail.com" , Mallikarjun Chadalapaka , "ttalpey@microsoft.com" , secdir , "nezhinsky@gmail.com" , "alexandern@mellanox.com" , "spencerdawkins.ietf@gmail.com" , "martin.stiemerling@neclab.eu" Subject: [secdir] draft-ietf-storm-iser and IPsec version requirements 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, 06 Jun 2013 23:04:08 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712980CA080MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, This is a much delayed follow-up on the IPsec version concern noted in the secdir review of draft-ietf-storm-iser found. After further investigation, it turns out that the iSER draft implicitly used different sets of IPsec requirements for the iSCSI vs. RDMA layers of the iSER protocol stack. That was not a good approach, as the protocol stack is iSER/RDMA/TCP/IP, so a single common IPsec implementation is likely to be used for both iSER and RDMA, but doing the proverbial "right thing" has taken a while. Getting to a single common set of IPsec requirements required a new draft. That new storm WG draft has just been posted; it updates RFC 3723's IPsec requirements to encompass IPsec v3 (4301 series RFCs). That update covers iSCSI, iSER, the iWARP RDMA protocols, and all other protocols that use the IPsec requirements for IP Storage in RFC 3723: http://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update/ Yaron Sheffer's prompt review of that draft (thank you!) found a few minor problems, which will be addressed in a -01 version to be posted in the next few days. The just-posted -14 version of the iSER draft contains a normative reference to that ipsec-ips-update draft, with the result that the IPsec requirements are now consistent and include IPsec v3 (4301 series RFCs). Everything else noted in the secdir review has been addressed in that new -14 version. Thanks, --David From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, November 05, 2012 5:33 PM To: Black, David Cc: mkosjc@gmail.com; alexandern@mellanox.com; nezhinsky@gmail.com; secdir;= wes@mti-systems.com; martin.stiemerling@neclab.eu; ttalpey@microsoft.com; = Mallikarjun Chadalapaka; Steve Kent Subject: Re: secdir review of draft-ietf-storm-iser-12.txt 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 50= 42 > refers to the old IPsec RFCs (2401 series), instead of the newer IPsec RF= Cs > (4301 series). RFC 5042 was published in October 2007, almost 2 years aft= er > 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 us= e the IP Storage profile of the older IPsec RFCs (2401 series) as specified i= n 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 authenticatio= n, > security and text mode negotiation mechanisms." (The wording here is a bi= t > worrisome as suggests that the authors equate security with confidentiali= ty, > since the more general, and accurate, use of the term "security" encompas= ses > authentication.) You could have just called that an editorial nit :-) - we'll fix it, regard= less. 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 causin= g > 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 acces= s to memory), and that requirement allowed the implementation on the receivin= g 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 t= he 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 --_000_8D3D17ACE214DC429325B2B98F3AE712980CA080MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Steve,

 

This is a much delayed fo= llow-up on the IPsec version concern noted

in the= secdir review of draft-ietf-storm-iser found.  After further

investigation, it turns out that the iSER draft implicitl= y used

different sets of IPsec requirements for t= he iSCSI vs. RDMA layers

of the iSER protocol sta= ck.  That was not a good approach, as the

pr= otocol stack is iSER/RDMA/TCP/IP, so a single common IPsec

implementation is likely to be used for both iSER and RDMA, but<= o:p>

doing the proverbial “right thing” ha= s taken a while.

 

Getting to a single common set of IPsec requirements required a new

draft.  That new storm WG draft has just been post= ed; it updates

RFC 3723’s IPsec requirement= s to encompass IPsec v3 (4301 series RFCs).

Tha= t update covers iSCSI, iSER, the iWARP RDMA protocols, and all other

protocols that use the IPsec requirements for IP Storag= e in RFC 3723:

 

http://datatracker.ietf.org/doc/draft-ietf-st= orm-ipsec-ips-update/

 

Yaron Sheffer’s prompt review of that draft (thank you!) fo= und a

few minor problems, which will be addressed= in a -01 version to be

posted in the next few da= ys.

 

The just-pos= ted -14 version of the iSER draft contains a normative

reference to that ipsec-ips-update draft, with the result that the IP= sec

requirements are now consistent and include I= Psec v3 (4301 series RFCs).

Everything else noted= in the secdir review has been addressed in that

= new -14 version.

 

Thanks,
--David

=  

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Monday= , November 05, 2012 5:33 PM
To: Black, David
Cc: mkosjc= @gmail.com; alexandern@mellanox.com; nezhinsky@gmail.com; secdir; wes@mti-s= ystems.com; martin.stiemerling@neclab.eu; ttalpey@microsoft.com; Mallikarju= n Chadalapaka; Steve Kent
Subject: Re: secdir review of draft-iet= f-storm-iser-12.txt

<= o:p> 

David,


<= p class=3DMsoNormal>Steve,

 

Tha= nk you for this review.

 <= /p>

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

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

>= ; refers to the old IPsec RFCs (2401 series), instead of the newer IPsec RF= Cs

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

> the late= r set of IPsec RFCs, so there was plenty of time to update the<= /o:p>

> 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 w= as made at that time to continue to use

the IP St= orage profile of the older IPsec RFCs (2401 series) as specified in<= o:p>

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

 <= /span>

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

   specif= ied in RFC 2401 [RFC2401] and related RFCs, as profiled by RFC<= /o:p>

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

   specified in RFC 4= 301 [RFC4301] and related RFCs [RFC4303],

 &= nbsp; [RFC4306], [RFC4835].  One of the important early applications o= f the

   RDDP protocols is their use wi= th iSCSI [iSER]; RDDP's IPsec

   requir= ements follow those of IPsec in order to facilitate that usage<= /o:p>

   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 requiremen= ts of any such

   update should apply u= niformly to iSCSI and the RDDP protocols.

 <= /span>

So, I think the (anonymous) SECDIR reviewer is of= f the hook on this one,

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

w= as also involved :-).

 

The consolidated iSCSI draft updates RFC 3723 to extend that IPsec pr= ofile

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 (b= oth of whom just happen to be holding Discuss

pos= itions on that iSCSI draft for good reasons) about whether to go ahead

and use that iSCSI draft to update the 5040 series RF= Cs - I think that

should probably be done.=

Thanks for the explanation. If the WG a= nd 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 th= at “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 “sec= urity” encompasses

> authentication.)

 

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

Too often I review docs where the autho= rs 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 :-).

&n= bsp;

> This section states plainly that iSER i= s “functionally iSCSI” and thus

>= ; all of the iSCSI security considerations apply. In particular, when iSER<= /span>

> is carried over IP networks, IPsec MUST be e= mployed.

Not exactly ;-).  The IPsec requirements are consisten= tly “MUST implement,

MAY use”.=

Right. sorry for my sloppy characteriza= tion.

 

> Ther= e 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 t= he 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 questi= on be augmented to state that

> the only DoS a= ttacks addressed here are ones that could cause resource<= /p>

> exhaustion at a target.

 

Will edit and clarify as suggested.<= /p>

Thanks.

=  

> The Security Considerations section concludes with a = paragraph that is

> a bit mysterious. <= o:p>

 

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

good timing!

 

> with the use of a buffer identifier. Howev= er, the section to which this

> paragraph refe= rs contains the following sentence:

> <= o:p>

> “That iSER layer MUST check that STag invalid= ation has occurred whenever

> receipt of a Sen= d with Invalidate message is the expected means of causing

> an STag to be invalidated, and MUST perform the STag invalid= ation if the

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

> use= d instead of Send with Invalidate).”

>&n= bsp;

> This sort of writing does not explain c= omplex issues to a reader.

 

We’ll provide a better explanation in the Security Conside= rations section.

 

What happened here is that  the original specification of iSER (RFC 5= 046)

required (MUST) use of a Send with Invalidat= e RCaP primitive in some cases.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>That primitive ha= s 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 o= n use of that primitive to invalidate the buffer identifier.

This draft allows use of a Send RCaP primitive that does not in= validate the

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

future use,= thereby creating a potential security issue if the identifier<= /o:p>

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

re= use), 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.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> 

Thanks for the explanation. I;m confident t= hat your revision will make this OK.

No need for me to re-review.
Steve

= --_000_8D3D17ACE214DC429325B2B98F3AE712980CA080MX15Acorpemccom_-- From prvs=6870181dd3=magnus.westerlund@ericsson.com Thu Jun 6 23:17:40 2013 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 E043A21F8CDD; Thu, 6 Jun 2013 23:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEkiSzLrNSch; Thu, 6 Jun 2013 23:17:34 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 11F9D21F8C38; Thu, 6 Jun 2013 23:17:33 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-1d-51b17afc805f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A0.D5.15700.CFA71B15; Fri, 7 Jun 2013 08:17:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Jun 2013 08:17:31 +0200 Message-ID: <51B17B3C.3090509@ericsson.com> Date: Fri, 7 Jun 2013 08:18:36 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Chris Lonvick (clonvick)" References: <9BB92CB59918E1418A06FD4E3269FABE116A4737@xmb-rcd-x06.cisco.com> In-Reply-To: <9BB92CB59918E1418A06FD4E3269FABE116A4737@xmb-rcd-x06.cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+Jvre6fqo2BBh9a5Cx+dqtaXNs9hcli xp+JzBYfFj5kcWDxmPJ7I6vHkiU/mTy+XP7MFsAcxW2TlFhSFpyZnqdvl8Cd8fX6HJaCe1wV q758YWlgPMvRxcjJISFgIrGzcQoThC0mceHeerYuRi4OIYFTjBINv9cwQzjLGCUOb9vACFLF K6AtsfnOWtYuRg4OFgEViWOXVEHCbAIWEjd/NLKB2KICwRJHtm9mgSgXlDg58wmYLSJgLPHp UA8TyExmgRWMEj1LtoHNFBawlTja8YAZxBYS8JG4vL2bGWQ+p4CvxO0f6RDHSUpsedHODmIz C+hJTLnawghhy0s0b50N1aot0dDUwTqBUWgWktWzkLTMQtKygJF5FSN7bmJmTnq54SZGYCAf 3PJbdwfjqXMihxilOViUxHn1eBcHCgmkJ5akZqemFqQWxReV5qQWH2Jk4uAEEVxSDYyZn2dN qhQ6bCS7eebf3uaJJ5IeqdsfuJX6u/rM24TkvbsY5L71zSo+arRJQ/bIr1sBxQWGnfG9obX+ OyOupnCvuSiwtCi8mv1AU9VFH/v+Xx/SbPbMWRPxmuvYhKXbn0ULPl/+8/WTioAIR7HN1c7Z k13duxNmT3u9IKxAeveGuHbVAz3+BjeUWIozEg21mIuKEwEpXyt9NwIAAA== Cc: "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-rfc2326bis-34 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, 07 Jun 2013 06:17:41 -0000 Hi Chris, Did you review Section 19 - Security Framework and section C.1.4 which are the two major sections which defines usage of security mechanisms? Thanks, Magnus On 2013-06-06 18:37, Chris Lonvick (clonvick) wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This is a lengthy document and I did not have time to fully review > it. I did review the Security Considerations section and found it to > be well written and thorough. I found no problems there and consider > that it appropriately covers the concepts in the document. > > Thanks, Chris > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From kivinen@iki.fi Fri Jun 7 05:34:28 2013 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 3C4B621F91A3 for ; Fri, 7 Jun 2013 05:34:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH9mFiBMt5ni for ; Fri, 7 Jun 2013 05:34:27 -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 39B1621F8F78 for ; Fri, 7 Jun 2013 05:34:16 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r57CYDJ6016917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 7 Jun 2013 15:34:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r57CYDt0013394; Fri, 7 Jun 2013 15:34:13 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20913.54085.471931.295709@fireball.kivinen.iki.fi> Date: Fri, 7 Jun 2013 15:34:13 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 1 min X-Total-Time: 0 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: Fri, 07 Jun 2013 12:34:28 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Glen Zorn is next in the rotation. For telechat 2013-06-13 Reviewer LC end Draft Alan DeKok T 2013-05-06 draft-ietf-geopriv-held-measurements-07 David Harrington T 2013-05-09 draft-ietf-6man-impatient-nud-06 Matt Lepinski T 2013-06-06 draft-ietf-manet-nhdp-sec-threats-04 For telechat 2013-06-27 Hilarie Orman T 2013-06-25 draft-thornburgh-adobe-rtmfp-07 Carl Wallace T - draft-ietf-ipsecme-ad-vpn-problem-07 Last calls and special requests: Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-10 Julien Laganier - draft-ietf-avtcore-rtp-security-options-03 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Kathleen Moriarty 2013-06-03 draft-ietf-xrblock-rtcp-xr-discard-14 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Russ Mundy 2013-05-31 draft-ietf-xrblock-rtcp-xr-jb-11 Sandy Murphy 2013-06-17 draft-jabley-dnsext-eui48-eui64-rrtypes-04 Magnus Nystrom 2013-06-11 draft-ietf-avtcore-6222bis-03 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-09 Joe Salowey 2013-06-06 draft-ietf-l3vpn-virtual-hub-06 Yaron Sheffer 2013-06-07 draft-ietf-pce-gmpls-aps-req-07 Ondrej Sury 2013-06-17 draft-ietf-abfab-eapapplicability-03 Tina TSOU 2013-06-20 draft-ietf-alto-server-discovery-08 David Waltermire 2013-05-14 draft-housley-rfc2050bis-01 David Waltermire 2013-06-19 draft-ietf-nvo3-overlay-problem-statement-03 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-09 Sam Weiler 2013-06-19 draft-ietf-ospf-manet-single-hop-mdr-03 Brian Weis 2013-06-18 draft-ietf-payload-vp8-08 Klaas Wierenga 2013-06-20 draft-ietf-rmt-sec-discussion-08 Nico Williams - draft-ietf-httpbis-p5-range-22 Tom Yu 2013-06-19 draft-ietf-rtgwg-cl-requirement-10 -- kivinen@iki.fi From new-work-bounces@ietf.org Thu Jun 6 11:41:44 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E189121E80A9; Thu, 6 Jun 2013 11:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1370544104; bh=ombworTecX+H6XOHY+kkw9bwh/WT83hhUlklH6GW0M0=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=HTJUwepasK4lmQDrcHm36hC0RkgRIDWmlVe2rZFLBHg+Yr1cmIFjIHxSswyEedEsp lvi1Cqi/LDhhKRlmGKOc4UeM2gZuI44Z5lSNztZNQ9QR5aiG9bdOZ9jmn9djaaSOk0 cV8bpGLHLjS0tSdESxiSpxE+XNddmvb8gwBOtimk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEE021E80AC; Thu, 6 Jun 2013 11:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe4FfunwMrB9; Thu, 6 Jun 2013 11:41:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C8821E809C; Thu, 6 Jun 2013 11:41:40 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130606184140.30639.90561.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 11:41:40 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 07 Jun 2013 08:03:22 -0700 Subject: [secdir] [new-work] WG Review: IP Performance Metrics (ippm) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:41:45 -0000 The IP Performance Metrics (ippm) working group in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-06-13. IP Performance Metrics (ippm) ------------------------------------------------ Current Status: Active WG Chairs: Brian Trammell Bill Cerveny Assigned Area Director: Spencer Dawkins Mailing list Address: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm/ Charter: The IP Performance Metrics (IPPM) Working Group develops and maintains standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services and applications running over transport layer protocols (e.g. TCP, UDP) over IP. Direct measurement of raw network- or lower-layer protocols, such as OAM based performance measurement, is out of scope for IPPM. It also develops and maintains protocols for the measurement of these metrics. These metrics are designed such that they can be used by network operators, end users, or independent testing groups. Metrics developed by the IPPM WG are intended to provide unbiased quantitative performance measurements and not a value judgement. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. The working group will continue advancing the most useful of these metrics along the standards track, using the guidelines stated in RFC 6576. To the extent possible, these metrics will be used as the basis for future work on metrics in the WG. The WG will seek to develop new metrics and models to more accurately characterize the network paths under test and/or the performance of transport and application layer protocols on these paths. The WG will balance the need for new metrics with the desire to minimize the introduction of new metrics, and will require that new metric definitions state how the definition improves on an existing metric definition, or assesses a property of network performance not previously covered by a defined metric. Metric definitions will follow the template given in RFC 6390. It is possible that new measurement protocols will be needed to support new metrics; if this is the case, the working group will be rechartered to develop these protocols. Additional methods will be defined for the composition and calibration of IPPM-defined metrics, as well as active, passive and hybrid measurement methods for these metrics. In addition, the WG encourages work which describes the applicability of metrics and measurement methods, especially to improve understanding of the tradeoffs involved among active, passive, and hybrid methods. The WG may update its core framework RFC 2330 as necessary to accommodate these activities. The WG has produced protocols for communication among test equipment to enable the measurement of the one- and two-way metrics (OWAMP and TWAMP respectively). These protocols will be advanced along the standards track. The work of the WG will take into account the suitability of measurements for automation, in order to support large-scale measurement efforts. This may result in further developments in protocols such as OWAMP and TWAMP. Agreement about the definitions of metrics and methods of measurement enables accurate, reproducible, and equivalent results across different implementations. To this end, the WG will define and maintain a registry of metric definitions. The WG encourages work which assesses the comparability of measurements of IPPM metrics with metrics developed elsewhere. The WG also encourages work which improves the availability of information about the context in which measurements were taken. The IPPM WG seeks cooperation with other appropriate standards bodies and forums to promote consistent approaches and metrics. Within the IETF process, IPPM metric definitions and measurement protocols will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersects with the requirement of these specific metrics. The WG will, on request, provide input to other IETF working groups on the use and implementation of these metrics. Specific near-term milestones include: 1. Advancement of protocols for one- and two-way metrics (OWAMP and TWAMP respectively) along the standards track. 2. Update of the IPPM framework document (RFC 2330) to reflect experience with the framework, and to cover planned future metric development. 3. Definition of a registry of metric definitions to improve the equivalency of metric results across multiple implementations. 4. Publication of a rate measurement problem statement. 5. Publication of documents supporting the use of IPSec to protect OWAMP / TWAMP. 6. Publication of documents related to model-based TCP bulk transfer capacity metrics. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From clonvick@cisco.com Fri Jun 7 08:25:43 2013 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 E698C21F93F8; Fri, 7 Jun 2013 08:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfaMk-Kc-VIT; Fri, 7 Jun 2013 08:25:38 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2768621F9339; Fri, 7 Jun 2013 08:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2027; q=dns/txt; s=iport; t=1370618738; x=1371828338; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PlNceRTV9504ussaJt3EsYKzMKW3NGOz0FHsp9gFcIk=; b=SsKCWBmI0R4SaLcAC0JRntzIxVydVJ+OkWkyu+Hum1XaCAbggdu1LJoQ O15bOeffL8V8k77spOBLndJQI+qSdTCWN1aHIZw1gvCS9VrifNG1B5E2d xLOvVFvnFmraZGZy3CBO3j1APDY4G+lH4pIwUQbhXLC1lzFd8bYndcWgF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAE36sVGtJXHB/2dsb2JhbABZgwm/IH8WdIIjAQEBAwEMbQUJAgIBCBgnBxsXFBEBAQQOBYgHBrx1BI8BMweCe2EDiGiOWJFCgw8 X-IronPort-AV: E=Sophos;i="4.87,822,1363132800"; d="scan'208";a="220070709" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jun 2013 15:25:37 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r57FPbu0027607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 15:25:37 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 10:25:37 -0500 From: "Chris Lonvick (clonvick)" To: Magnus Westerlund Thread-Topic: Secdir review of draft-ietf-mmusic-rfc2326bis-34 Thread-Index: Ac5i1CClI30rLRrtSr6OoqunYaYT0wAnKAAAAAiga1M= Date: Fri, 7 Jun 2013 15:25:36 +0000 Message-ID: References: <9BB92CB59918E1418A06FD4E3269FABE116A4737@xmb-rcd-x06.cisco.com>, <51B17B3C.3090509@ericsson.com> In-Reply-To: <51B17B3C.3090509@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-rfc2326bis-34 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, 07 Jun 2013 15:25:44 -0000 Hi Magnus, Unfortunately I did not review those sections. My travel with the day job l= ately has prevented me from doing that. I did want to get a review in befor= e the deadline and what I did was all that I could accomplish right now.=20 I do have a long-ish flight coming up in a few days. If it would help, I co= uld review those sections and have my notes out by next Wednesday or Thursd= ay. Let me know.=20 Best regards, Chris Sent from my phone. On Jun 7, 2013, at 8:17 AM, "Magnus Westerlund" wrote: > Hi Chris, >=20 > Did you review Section 19 - Security Framework and section C.1.4 which > are the two major sections which defines usage of security mechanisms? >=20 > Thanks, >=20 > Magnus >=20 > On 2013-06-06 18:37, Chris Lonvick (clonvick) wrote: >> Hi, >>=20 >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >>=20 >> This is a lengthy document and I did not have time to fully review >> it. I did review the Security Considerations section and found it to >> be well written and thorough. I found no problems there and consider >> that it appropriately covers the concepts in the document. >>=20 >> Thanks, Chris >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From clonvick@cisco.com Sun Jun 9 15:52:58 2013 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 F286421F880F; Sun, 9 Jun 2013 15:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgiRHtlcQM+C; Sun, 9 Jun 2013 15:52:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 311EF21F84F9; Sun, 9 Jun 2013 15:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4844; q=dns/txt; s=iport; t=1370818372; x=1372027972; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SlXP3CW68v/BPQGUk3lsFd8gghwYicZbJWaAsSRczLU=; b=G2wgNbBOsvnXDSM1K5pTfIbSLjrUWuBE1B0lCGqTNpzULg30YtMqUIAr 39/jiz07rVBNFKxNbnrxy7/plgK6DxKR+Ey7cKMVMTHeVKCVNjLfFV9Ra DU+qDREzdszmSiurDzCjFULFzhl2Rd4zcvDty5wKhIKVeM3hNdsrqNH1m w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHYGtVGtJV2b/2dsb2JhbABZgwl5vj56FnSCIwEBAQMBDG0FCQICAQgRBAEBAQodBxsXFAkIAQEEDgUIh38GuGkEjwMxB4J/YQOIaKAagw+CJw X-IronPort-AV: E=Sophos;i="4.87,833,1363132800"; d="scan'208";a="220727064" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 09 Jun 2013 22:52:51 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r59Mqpje015985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Jun 2013 22:52:51 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Sun, 9 Jun 2013 17:52:51 -0500 From: "Chris Lonvick (clonvick)" To: Magnus Westerlund Thread-Topic: Secdir review of draft-ietf-mmusic-rfc2326bis-34 Thread-Index: Ac5i1CClI30rLRrtSr6OoqunYaYT0wAnKAAAAAiga1MAc+ZEFg== Date: Sun, 9 Jun 2013 22:52:51 +0000 Message-ID: <9BB92CB59918E1418A06FD4E3269FABE116A6711@xmb-rcd-x06.cisco.com> References: <9BB92CB59918E1418A06FD4E3269FABE116A4737@xmb-rcd-x06.cisco.com>, <51B17B3C.3090509@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.88.189] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-rfc2326bis-34 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, 09 Jun 2013 22:52:58 -0000 Hi All,=0A= =0A= I looked over those sections on my long-ish flight and have written up some= notes while I'm waiting for my very much delayed final leg back home.=0A= =0A= Without a thorough reading of the entire document, I'll say that I understa= nd the intentions of Appendix C.1.4, and Section 19, but havn't fully wrapp= ed my head around it. I'll also say that I'm not well versed in MIKEY. Si= nce it stood out, I also looked at Appendix G. Nothing stood out as being = insecure and I'll say again that most of the documentation is very well don= e.=0A= =0A= Below are some nits:=0A= =0A= Appendix G=0A= =0A= Current:=0A= This section provides anyone intending to define how to transport of=0A= RTSP messages over a unreliable transport protocol with some=0A= information learned by the attempt in RFC 2326 [RFC2326]. RFC 2326=0A= defined both an URI scheme and some basic functionality for transport=0A= of RTSP messages over UDP, however, it was not sufficient for=0A= reliable usage and successful interoperability.=0A= =0A= The RTSP scheme defined for unreliable transport of RTSP messages was=0A= "rtspu". It has been reserved by this specification as at least one=0A= commercial implementation exists, thus avoiding any collisions in the=0A= name space.=0A= =0A= The following considerations should exist for operation of RTSP over=0A= an unreliable transport protocol:=0A= =0A= Proposed:=0A= This appendix provides guidance for those who want to implement RTSP mes= sages over unreliable transports as has been defined in RFC 2326 [RFC2326].= RFC 2326 defined the "rtspu" scheme and provided some basic information f= or the transport of RTSP messages over UDP. The information is being provi= ded here as there has been at at least one commercial implementation and co= mpatibility with that should be maintained.=0A= =0A= The following points should be considered for an interoperable implement= ation:=0A= =0A= =0A= =0A= CML> Throughout the document, I found an assortment of "an URI" and "a URI"= . Please pick one and be consistent. :-)=0A= =0A= CML> Do you want to say something about using rtspu is NOT RECOMMENDED in t= he Security Considerations section?=0A= =0A= =0A= Best regards,=0A= Chris=0A= ________________________________________=0A= From: Chris Lonvick (clonvick)=0A= Sent: Friday, June 07, 2013 10:25 AM=0A= To: Magnus Westerlund=0A= Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-mmusic-rfc2326bis@tools.ietf= .org=0A= Subject: Re: Secdir review of draft-ietf-mmusic-rfc2326bis-34=0A= =0A= Hi Magnus,=0A= =0A= Unfortunately I did not review those sections. My travel with the day job l= ately has prevented me from doing that. I did want to get a review in befor= e the deadline and what I did was all that I could accomplish right now.=0A= =0A= I do have a long-ish flight coming up in a few days. If it would help, I co= uld review those sections and have my notes out by next Wednesday or Thursd= ay. Let me know.=0A= =0A= Best regards,=0A= Chris=0A= =0A= Sent from my phone.=0A= =0A= On Jun 7, 2013, at 8:17 AM, "Magnus Westerlund" wrote:=0A= =0A= > Hi Chris,=0A= >=0A= > Did you review Section 19 - Security Framework and section C.1.4 which=0A= > are the two major sections which defines usage of security mechanisms?=0A= >=0A= > Thanks,=0A= >=0A= > Magnus=0A= >=0A= > On 2013-06-06 18:37, Chris Lonvick (clonvick) wrote:=0A= >> Hi,=0A= >>=0A= >> I have reviewed this document as part of the security directorate's=0A= >> ongoing effort to review all IETF documents being processed by the=0A= >> IESG. These comments were written primarily for the benefit of the=0A= >> security area directors. Document editors and WG chairs should treat=0A= >> these comments just like any other last call comments.=0A= >>=0A= >> This is a lengthy document and I did not have time to fully review=0A= >> it. I did review the Security Considerations section and found it to=0A= >> be well written and thorough. I found no problems there and consider=0A= >> that it appropriately covers the concepts in the document.=0A= >>=0A= >> Thanks, Chris=0A= >=0A= >=0A= > --=0A= >=0A= > Magnus Westerlund=0A= >=0A= > ----------------------------------------------------------------------=0A= > Multimedia Technologies, Ericsson Research EAB/TVM=0A= > ----------------------------------------------------------------------=0A= > Ericsson AB | Phone +46 10 7148287=0A= > F=E4r=F6gatan 6 | Mobile +46 73 0949079=0A= > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com=0A= > ----------------------------------------------------------------------=0A= >=0A= From mlepinski.ietf@gmail.com Sun Jun 9 21:13:38 2013 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 6695C21F8B90; Sun, 9 Jun 2013 21:13:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNGuXL9wIxIw; Sun, 9 Jun 2013 21:13:26 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id ABE0321F8AC2; Sun, 9 Jun 2013 21:13:26 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so3802452qeb.13 for ; Sun, 09 Jun 2013 21:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+NzIt9DP7hTcy2jEQTh7LEZ/XM25SqoXclVVv60eF6U=; b=fvdq/FakIMgh4R0SsYp5g8wvaFbg6pu0aI2yi9ofQOXYu7HwmYal/96br6gPXOFN9e NxMECqb7yJRoLQ3gjiwxzyNxc8yjXEOmspxC7ourRf+gl0pCo+aZxMWIHd428xlUaKVD mThnE/oAsRCEJR7PMaceWmUM9v81qIkKtYUySeR9C70qMJQDqFLwSMitEgnyN7FSqiLa V2BBvOkUe67FoK9Q6yW/1tYsaqCwB1rzf0XrX1iiacWysivBGwpuHxTABkHNcfjn+Mqc arBIvkNcAxEP9raXT22HfmA7efipkbXOOs84/xLEz+QOGsKcIAhlik0dKgdRPYJqzmxJ lpsQ== MIME-Version: 1.0 X-Received: by 10.229.24.198 with SMTP id w6mr452903qcb.37.1370837606125; Sun, 09 Jun 2013 21:13:26 -0700 (PDT) Received: by 10.49.1.43 with HTTP; Sun, 9 Jun 2013 21:13:25 -0700 (PDT) Date: Mon, 10 Jun 2013 00:13:25 -0400 Message-ID: From: Matthew Lepinski To: "secdir@ietf.org" , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=14dae9d70e748ed96f04dec5007b Cc: draft-ietf-manet-nhdp-sec-threats@tools.ietf.org Subject: [secdir] SECDIR review of draft-ietf-manet-nhdp-sec-threats-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, 10 Jun 2013 04:13:38 -0000 --14dae9d70e748ed96f04dec5007b 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 a taxonomy of attacks against the Mobile Ad Hoc Network Neighborhood Discovery Protocol (NHDP) [RFC 6130]. The document also contains a discussion of the impact of these attacks on running on top of NHDP (in particular, OLSRv2 and SMF) Having reviewed the document, I do not see substantial issues in the document. I believe it is reasonable to publish as an informational RFC. *One minor issue:* The replay attack described in Section 4.5 did not seem substantially different than the attacks described in Section 4.4. It is not clear to me how replaying a message from another part of the network is any worse (or substantially different) than just fabricating a message claiming connectivity that does not exist (i.e., like what is described in 4.4.2). I would recommend either deleting 4.5 or else clarifying how these attacks are substantially different. *Trivial nit:* In Section 5, "a Compromised NHDP router will seek to manipulate" -- substitute "may seek" instead of "will seek". We don't know for certain what a compromised router will do (unless one assigns clear motivation to the adversary, which this document does not). --14dae9d70e748ed96f04dec5007b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dir= ectorate's ongoing effort to review all IETF documents being processed = by the IESG. =A0These comments were=A0written primarily for the ben= efit of the security area directors. =A0Document editors and WG chairs shou= ld treat these comments just like any other last call comments.

This document provides a taxonomy of attacks against t= he Mobile Ad Hoc Network Neighborhood Discovery Protocol (NHDP) [RFC 6130].= The document also contains a discussion of the impact of these attacks on = running on top of NHDP (in particular,=A0OLSRv2 and SMF)

Having reviewed the document, I do not see substantial issue= s in the document. I believe it is reasonable to publish as an informationa= l RFC.

One minor issue: The rep= lay attack described in Section 4.5 did not seem substantially different th= an the attacks described in Section 4.4. It is not clear to me how replayin= g a message from another part of the network is any worse (or substantially= different) than just fabricating a message claiming connectivity that does= not exist (i.e., like what is described in 4.4.2). I would recommend eithe= r deleting 4.5 or else clarifying how these attacks are substantially diffe= rent.

Trivial nit: In Section 5, "a Compromised NHDP route= r will seek to manipulate" -- substitute "may seek" instead = of "will seek". We don't know for certain what a compromised = router will do (unless one assigns clear=A0motivation=A0to the adversary, which this document does not).


--14dae9d70e748ed96f04dec5007b-- From magnusn@gmail.com Sun Jun 9 23:37:25 2013 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 C420421F84B6; Sun, 9 Jun 2013 23:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbEZdKJkcxff; Sun, 9 Jun 2013 23:37:25 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DFF3321F8FEB; Sun, 9 Jun 2013 23:37:24 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so4512772wev.36 for ; Sun, 09 Jun 2013 23:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Gi3V7xMpgD9bHF+UUrihtfd5VJTpdR23btBJxvrhcf0=; b=efTtR0fJvaY/Ti8UQnapXMEGK+iuOuv3kIQ1H6xFSO2V+WRMw07lybxZNfrtOanFAw lGBqYkVZROg6CtNSACluQ8WOJnH5+nWmh7ckO1XEzyIL0HKv0CU3Zrp2Kn8odRRBOiMX 2JNoqfIPM+xEHUqjsvMKP20eFbd0vxAQErucZ+HBBd8E3NEBvt62l4MqyVUu22kC0uJ5 GBe2xnDywZb55DDdjuCCOVCMBoT8Clv8H6TT9lUJVezgH8sjGxthFhsaC3Gs+cMHrO2J icH7wsDviz0sflAz6W3P9C6HBmZHmq5RCkQmGMTdxQ5f+hYKokSZkv0n4vyBVbCB1kwn ZOfQ== MIME-Version: 1.0 X-Received: by 10.180.105.231 with SMTP id gp7mr3881908wib.23.1370846244037; Sun, 09 Jun 2013 23:37:24 -0700 (PDT) Received: by 10.180.163.168 with HTTP; Sun, 9 Jun 2013 23:37:23 -0700 (PDT) Date: Sun, 9 Jun 2013 23:37:23 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "secdir@ietf.org" , draft-ietf-avtcore-6222bis@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d0442881a6aeb8804dec703c9 Cc: "iesg@ietf.org" Subject: [secdir] Secdir review of draft-ietf-avtcore-6222bis-03 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, 10 Jun 2013 06:37:25 -0000 --f46d0442881a6aeb8804dec703c9 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 avtcore document describes a new method for generating unique RTCP canonical names and obsoletes RFC 6222. The Security Considerations section seems adequate to me. (A few side comments: - RFC 6222 is mentioned in several places (e.g., Section 1, Section 8). Should it not also be a reference? - In Section 4.2, it is stated that, if the RTP endpoint is in a virtualized environment, then the MAC address may not be unique. In such cases, the host shall use the other presented option for short-term persistent RTP CNAMEs. I wonder if it in general is possible for an RTCP endpoint to deterministically determine if its MAC address is unique? It is not in general possible for a process to detect if it is running in a virtualized OS.) Thanks, -- Magnus --f46d0442881a6aeb8804dec703c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate'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 avtcore document describes a new method for generating unique RTCP can= onical names and obsoletes RFC 6222.

The Security Considerations section seems adequate to me.

(A few sid= e comments:
- RFC 6222 is mentioned in several places (e.g., Section 1,= Section 8). Should it not also be a reference?
- In Section 4.2, it is = stated that, if the RTP endpoint is in a virtualized environment, then the = MAC address may not be unique. In such cases, the host shall use the other = presented option for short-term persistent RTP CNAMEs. I wonder if it in ge= neral is possible for an RTCP endpoint to deterministically determine if it= s MAC address is unique? It is not in general possible for a process to det= ect if it is running in a virtualized OS.)

Thanks,
-- Magnus
--f46d0442881a6aeb8804dec703c9-- From n@arifumi.net Mon Jun 10 03:51:41 2013 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 663CD21F8EC6 for ; Mon, 10 Jun 2013 03:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.425 X-Spam-Level: X-Spam-Status: No, score=-100.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o469QBs7D0NL for ; Mon, 10 Jun 2013 03:51:34 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 14DF521F8E93 for ; Mon, 10 Jun 2013 03:51:30 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so7143459pbc.18 for ; Mon, 10 Jun 2013 03:51:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=DmooZt248CaSNeMYP1cM+LZi/F53znwakrM536r1Q4c=; b=QAB+5z2+vZdcRZ7wZ9prEqrRLp59ryOltIJ3eZI1OhPQLq+Yy9N8vXOBqCbKc/+Xpp kUrtqXyW1n5pWwC9GQwHglZ+9L2IRU2HpySm9uFVaB0Bd5lrT6k8zsKZlFOb64pJTnuL 5c9866NfHqW/smidkkVCDzNW1cbT59fLzSJWepNqsf7PjaKYUjzzSJfRHeDD0hBFAUJW gVrCDZ0Z0rKIyA0hWDHXM9ZxKmhJhoAzCqCNplMMQ4b2MOYL/MuG0EF8miaTj3e2n0PK 9GNCnPIwMnd7AD8XC8ZwM7DrN0RGd+VQAZyUeV0F6yvAexTXbZsifszqSWRYr/C9U7Hv 5R3A== MIME-Version: 1.0 X-Received: by 10.68.28.232 with SMTP id e8mr6715904pbh.94.1370861489736; Mon, 10 Jun 2013 03:51:29 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.194.198 with HTTP; Mon, 10 Jun 2013 03:51:29 -0700 (PDT) X-Originating-IP: [129.60.57.66] In-Reply-To: References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> Date: Mon, 10 Jun 2013 19:51:29 +0900 X-Google-Sender-Auth: mk4ltFtT9Fi_jZxa-JYiYvFx0aw Message-ID: From: Arifumi Matsumoto To: Dan Harkins Content-Type: multipart/alternative; boundary=bcaec520eacd21e83404deca9091 X-Gm-Message-State: ALoCoQlNPZMRR+M36hCi6+f/z93KSC81BqvIFoEWsiuBQYl/QCdwdXd/ftyjuQmtFv5AxzPb5Ec5 Cc: "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , secdir@ietf.org, iesg@ietf.org, Arifumi Matsumoto Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 10 Jun 2013 10:51:41 -0000 --bcaec520eacd21e83404deca9091 Content-Type: text/plain; charset=ISO-8859-1 Hi, thank you for your reply. comments below. 2013/6/6 Dan Harkins > > Hi, > > On Wed, June 5, 2013 6:51 am, Arifumi Matsumoto wrote: > > Hi, > > > > did my previous e-mail get to you all ? > > No, it didn't; thanks for resending. > I will resend an e-mail sooner, this time :) > > > 2013/5/28 Arifumi Matsumoto > > > >> Hi Dan, > >> I appreciate your review. > >> > >> Comments below. > >> > >> 2013/5/22 Dan Harkins > >> > >>> > >>> Hello, > >>> > >>> I have reviewed draft-ietf-6man-addr-select-opt 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. > >>> > >>> draft-ietf-6man-addr-select-opt defines address selection options > >>> for DHCPv6 that allow a network administrator to effect some > >>> control over address selection behavior of nodes on their sites. > >>> > >>> This sounds like a reasonably straightforward problem but as I > >>> read the draft it seemed like it might be have interoperability issues. > >>> I don't believe this draft is ready for advancement until these issues > >>> are resolved. > >>> > >>> For instance, while I think I understand the policy override of RFC > >>> 6724, having the Automatic Row Additions Flag be part of the address > >>> selection options seems problematic. If it is set to zero, then what > >>> are > >>> the semantics of such a message? "Here's an address selection option > >>> but don't you dare use it!"? What is the point? Me, as a node, can have > >>> this as part of my policy state which would allow me to ignore such > >>> an update but to have the bit be part of the option to update does > >>> not seem to make much sense. The semantics of the message needs > >>> to be explained much more clearly, or the bit needs to be removed > >>> from the message. > >>> > >> > >> If A flag is zero, it means Automatic Row Addition is indicated not to > >> perform. > >> If A flag is 1, it means it is up to the node. > > So what is the purpose of sending someone a row for addition > and saying "do not perform addition"? No, the distributed policy table is not for addition, but for replacement. > > >> Even in the latter case, the Address Selection Option may contain other > >> information to the node, such as the policy table and other flags. > >> > >> Make sense ? > > Not really. So what's the semantics of this other information if the > flag is set to zero? "Here's some other stuff but don't use it either"? > > >> If not, splitting the flag into another new sub-option makes sense to > >> you ? > > Why not just get rid of this flag. It's always "up to the node" whether > it > is willing to modify its own resources or not. > I missed one point. Regarding flag A, it is hard to insert automatically some specific prefixes into the distributed policy table. This is for the reason mentioned in policy merging issue. So, this flag should be used, only when the distributed option does not include policy table, which should be mentioned in this draft. And, when the option does not include policy table, this flag A can be used to indicate whether a host can insert ULA and 6to4, to the default policy table. >> > >>> > >>> Section 3.3 says, "Even if the received policy from one source is > >>> merged with one from another source, the effect of both policy are > >>> more or less changed." I don't understand how both policies are > >>> changed. And what does "more or less" mean? > >> > >> > >> I think that a policy table has its own unique meaning. Even single > >> insertion/deletion from the table makes the table different. > >> > >> For example, when adding a line, from one source, to the default policy > >> table below, > >> > >> Prefix Precedence Label > >> ::1/128 50 0 > >> ::/0 40 1 > >> ::ffff:0:0/96 35 4 > >> 2002::/16 30 2 > >> 2001::/32 5 5 > >> fc00::/7 3 13 > >> ::/96 1 3 > >> fec0::/10 1 11 > >> 3ffe::/16 1 12 > >> > >> makes > >> > >> Prefix Precedence Label > >> ::1/128 50 0 > >> ::/0 40 1 > >> ::ffff:0:0/96 35 4 > >> 2002::/16 30 2 > >> + 2003::/16 10 6 > >> 2001::/32 5 5 > >> fc00::/7 3 13 > >> ::/96 1 3 > >> fec0::/10 1 11 > >> 3ffe::/16 1 12 > >> > >> In this case, the prefix 2003::/16 has lower precendence than the > >> default > >> policy table. And, the table contains a lot of policy that is not > >> intended > >> by > >> the source who deliver single line of policy. > > If I add lines from one table to another I only change the latter. > The former is not changed. And "more or less" is too vague. So how > about rewriting that sentence to be: > > "Merging received policy into an existing policy changes > the existing policy." > > although this statement seems so self-evident as to suggest just > getting rid of the problematic text from 3.3 altogether. > I agree with removing the following sentence, because it looks redundant. Even if the received policy from one source is merged with one from another source, the effect of both policy are more or less changed. > >> > >>> 3.3 also says, > >>> "It also should be noted that absence of the distributed policy from a > >>> certain network interface should not be treated as absence of policy > >>> itself, because it may mean preference for the default address > >>> selection policy." So I use the default address selection policy then, > >>> is that it? > >> > >> > >> I mean, there is no way to tell the network with no policy distribution > >> prefers default policy, or does not care about it. > >> The conclusion is "using the default policy should be safe", though. > > Then I think you should say that directly. > Ok, I'll change the text accordingly. > > >> > >>> This whole section (3.3) screams out for some normative > >>> language since it sounds like it refers to behavioral changes on the > >>> node. > >>> > >> > >> Do you mean this section should have more SHOULDs and MUSTs ? > >> If so, on which part do you think should we put ? > > How about: "In the absence of distributed policy for a certain network > interface, the default address selection policy SHOULD be used." And > get rid of the single SHOULD in the existing text that is followed by 1) > and 2) and make two separate SHOULD statements: "A single-homed > host SHOULD use default address selection options. Hosts that use > advanced heuristics that are defined outside the scope of this document > SHOULD use default address selection options." > > You say, "The above restrictions do not preclude implementations from > providing configuration options to enable this option on a certain network > interface." which could be changed to "Implementations MAY provide > configuration options to enable this protocol on a per interface basis." > if that is your intent. > Okay. Looks nice. > > >>> > >>> There is an "Implementation Consideration" mentioning that the > >>> label is passed as an unsigned integer. But it then goes on to say, > >>> "DHCPv6 clients SHOULD convert this label to a representation > >>> appropriate for the local implementation (e.g., string)." This has > >>> interoperability implications because it is not solely a local matter. > >>> The node may represent these things differently than the network > >>> administrator and the preference will not be done properly. RFC 6724 > >>> does not really define what the label is from what I can tell. It's > >>> used to just allow for policies to prefer a particular source address, > >>> S, with a particular destination address, D, if "Label(S) = Label(D)". > >>> But to pass a value over a network, and have it be used by the > >>> recipient, means that a canonical representation of "label" has to > >>> be defined. > >>> > >> > >> Maybe, I don't understand your point quite well. > >> As far as the one-to-one mapping in a node is performed between an > >> unsinged integer and representation format, I think there will not arise > >> interoperability issue, such that a policy has different meaning > >> depending > >> on a receiving host. > > I'm saying this has an impact on interoperability because there's no > way to ensure that this option will be processed correctly. There is no > way for the sender of this option to know how the recipient is > representing labels locally and therefore there is no way for the sender > to properly convey his intent in the option he sends. > > I may have existing policies where Label(A) = 0x31 and another > where Label(B) = 0x01. Now I get an label in my address selection option > that is an unsigned integer of the value 0x01. Should I convert it to a > string, as the text says I SHOULD? Should I use ASCII? So then it will > match Label(A)? Or should I use it directly and it therefore should > match Label(B). > > I just don't think you can mention conversion here. The field has to > be treated as an opaque blob or some canonical representation MUST > be defined. > I think what you describe here is conflict with local policy. As 3.1 mentioned, the distributed policy will replace local policy, or will not be used at all. So, as far as policy merge does not happen, conflict also will not happen. > >>> An appendix with examples would be most helpful! > >>> > >> > >> RFC 6724 has a lot of examples for policy table. > >> Do you think we need other examples, or just same ones ? > > Since this draft is about updating, or modifying, the policy table > it would be nice to see a sample Address Selection Option with at > least one, and preferably more, Address Selection Policy Table > options and what receipt of that message would be to a sample > policy table. Show a before policy table, the message that modifies > it, and an after policy table. > Okay, I'll include some in the rev. > >>> > >>> Spelling nit: section 3.1 "The choice a SHOULD be default, as far as > >>> the policy table is not configured by the user." There's an extra > >>> word in there somewhere, or maybe there's some words missing, > >>> it's hard to understand what is being implied. > >>> > >> > >> It means the choice called "a" below should be default. > >> Maybe using parenthesis (a) makes it clearer ? > > That make more sense. Suggest removing the article then too. So > make it "Choice (a) SHOULD be default...." > Looks good. Thanks. > > regards, > > Dan. > > > --bcaec520eacd21e83404deca9091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

thank you for your reply.
comments below.


2013/6/6 Dan Harkins <dharkins@lounge.org>

=A0 Hi,

On Wed, June 5, 2013 6:51 am, Arifumi Matsumoto wrote:
> Hi,
>
> did my previous e-mail get to you all ?

=A0 No, it didn't; thanks for resending.
I will resend an e-mail sooner, this time :)
= =A0

> 2013/5/28 Arifumi Matsumoto <a= rifumi@nttv6.net>
>
>> Hi Dan,
>> I appreciate your review.
>>
>> Comments below.
>>
>> 2013/5/22 Dan Harkins <d= harkins@lounge.org>
>>
>>>
>>> =A0 Hello,
>>>
>>> =A0 I have reviewed draft-ietf-6man-addr-select-opt as part of= the
>>> security directorate's =A0ongoing effort to review all IET= F documents
>>> being processed by the IESG. =A0These comments were written pr= imarily
>>> for the benefit of the =A0security area directors. =A0Document= editors and
>>> WG chairs should treat these comments just like any other last= call
>>> comments.
>>>
>>> =A0 draft-ietf-6man-addr-select-opt defines address selection = options
>>> for DHCPv6 that allow a network administrator to effect some >>> control over address selection behavior of nodes on their site= s.
>>>
>>> =A0 This sounds like a reasonably straightforward problem but = as I
>>> read the draft it seemed like it might be have interoperabilit= y issues.
>>> I don't believe this draft is ready for advancement until = these issues
>>> are resolved.
>>>
>>> =A0 For instance, while I think I understand the policy overri= de of RFC
>>> 6724, having the Automatic Row Additions Flag be part of the a= ddress
>>> selection options seems problematic. If it is set to zero, the= n what
>>> are
>>> the semantics of such a message? "Here's an address s= election option
>>> but don't you dare use it!"? What is the point? Me, a= s a node, can have
>>> this as part of my policy state which would allow me to ignore= such
>>> an update but to have the bit be part of the option to update = does
>>> not seem to make much sense. The semantics of the message need= s
>>> to be explained much more clearly, or the bit needs to be remo= ved
>>> from the message.
>>>
>>
>> If A flag is zero, it means Automatic Row Addition is indicated no= t to
>> perform.
>> If A flag is 1, it means it is up to the node.

> =A0 So what is the purpose of sending someone a row for addition<= /span>
> and saying= "do not perform addition"?

No, the distributed policy table is not for addition,= but for replacement.

=A0
=

>> Even in the latter case, the Address Selection Option may contain = other
>> information to the node, such as the policy table and other flags.=
>>
>> Make sense ?

=A0 Not really. So what's the semantics of this other information= if the
flag is set to zero? "Here's some other stuff but don't use it= either"?

>> If not, splitting the flag into another new sub-option makes sense= to
>> you ?

=A0 Why not just get rid of this flag. It's always "up to th= e node" whether it
is willing to modify its own resources or not.

I missed one point.

Regarding = flag A, it is hard to insert automatically some specific prefixes
into the distributed policy table. This is for the reason mentio= ned in policy
merging issue. So, this flag should be used, = only when the distributed=A0
option does not include policy= table, which should be mentioned in this
draft.

And, when the option= does not include policy table, this flag A can be
used to = indicate whether a host can insert ULA and 6to4, to the default
policy table.

>>
>>>
>>> =A0 Section 3.3 says, "Even if the received policy from o= ne source is
>>> merged with one from another source, the effect of both policy= are
>>> more or less changed." I don't understand how both po= licies are
>>> changed. And what does "more or less" mean?
>>
>>
>> I think that a policy table has its own unique meaning. Even singl= e
>> insertion/deletion from the table makes the table different.
>>
>> For example, when adding a line, from one source, to the default p= olicy
>> table below,
>>
>> =A0 =A0 =A0 Prefix =A0 =A0 =A0 =A0Precedence Label
>> =A0 =A0 =A0 ::1/128 =A0 =A0 =A0 =A0 =A0 =A0 =A0 50 =A0 =A0 0
>> =A0 =A0 =A0 ::/0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A040 =A0 =A0 1 >> =A0 =A0 =A0 ::ffff:0:0/96 =A0 =A0 =A0 =A0 35 =A0 =A0 4
>> =A0 =A0 =A0 2002::/16 =A0 =A0 =A0 =A0 =A0 =A0 30 =A0 =A0 2
>> =A0 =A0 =A0 2001::/32 =A0 =A0 =A0 =A0 =A0 =A0 =A05 =A0 =A0 5
>> =A0 =A0 =A0 fc00::/7 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 =A0 =A013
>> =A0 =A0 =A0 ::/96 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 3 >> =A0 =A0 =A0 fec0::/10 =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A011
>> =A0 =A0 =A0 3ffe::/16 =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A012
>>
>> makes
>>
>> =A0 =A0 =A0 Prefix =A0 =A0 =A0 =A0Precedence Label
>> =A0 =A0 =A0 ::1/128 =A0 =A0 =A0 =A0 =A0 =A0 =A0 50 =A0 =A0 0
>> =A0 =A0 =A0 ::/0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A040 =A0 =A0 1 >> =A0 =A0 =A0 ::ffff:0:0/96 =A0 =A0 =A0 =A0 35 =A0 =A0 4
>> =A0 =A0 =A0 2002::/16 =A0 =A0 =A0 =A0 =A0 =A0 30 =A0 =A0 2
>> + =A0 =A0 2003::/16 =A0 =A0 =A0 =A0 =A0 =A0 10 =A0 =A06
>> =A0 =A0 =A0 2001::/32 =A0 =A0 =A0 =A0 =A0 =A0 =A05 =A0 =A0 5
>> =A0 =A0 =A0 fc00::/7 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 =A0 =A013
>> =A0 =A0 =A0 ::/96 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 3 >> =A0 =A0 =A0 fec0::/10 =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A011
>> =A0 =A0 =A0 3ffe::/16 =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A012
>>
>> In this case, the prefix 2003::/16 has lower precendence than the<= br> >> default
>> policy table. And, the table contains a lot of policy that is not<= br> >> intended
>> by
>> the source who deliver single line of policy.

=A0 If I add lines from one table to another I only change the = latter.
The former is not changed. And "more or less" is too vague. So ho= w
about rewriting that sentence to be:

=A0 =A0 =A0 "Merging received policy into an existing policy changes =A0 =A0 =A0 =A0the existing policy."

although this statement seems so self-evident as to suggest just
getting rid of the problematic text from 3.3 altogether.


I agree with removing the foll= owing sentence, because it looks redundant.

   Even if the received policy from one sour=
ce is merged with one from
     another source, the effect of both policy are more or less changed.


>>
>>> 3.3 also says,
>>> "It also should be noted that absence of the distributed = policy from a
>>> certain network interface should not be treated as absence of = policy
>>> itself, because it may mean preference for the default address=
>>> selection policy." So I use the default address selection= policy then,
>>> is that it?
>>
>>
>> I mean, there is no way to tell the network with no policy distrib= ution
>> prefers default policy, or does not care about it.
>> The conclusion is "using the default policy should be safe&qu= ot;, though.

=A0 Then I think you should say that directly.
<= br>
Ok, I'll change the text accordingly.
=A0=

>>
>>> This whole section (3.3) screams out for some normative
>>> language since it sounds like it refers to behavioral changes = on the
>>> node.
>>>
>>
>> Do you mean this section should have more SHOULDs and MUSTs ?
>> If so, on which part do you think should we put ?

=A0 How about: "In the absence of distributed policy for a certa= in network
interface, the default address selection policy SHOULD be used." And get rid of the single SHOULD in the existing text that is followed by 1) and 2) and make two separate SHOULD statements: "A single-homed
host SHOULD use default address selection options. Hosts that use
advanced heuristics that are defined outside the scope of this document
SHOULD use default address selection options."

=A0 You say, "The above restrictions do not preclude implementations f= rom
providing configuration options to enable this option on a certain network<= br> interface." which could be changed to "Implementations MAY provid= e
configuration options to enable this protocol on a per interface basis.&quo= t;
if that is your intent.

Okay. Loo= ks nice.
=A0

>>>
>>> =A0 There is an "Implementation Consideration" menti= oning that the
>>> label is passed as an unsigned integer. But it then goes on to= say,
>>> "DHCPv6 clients SHOULD convert this label to a representa= tion
>>> appropriate for the local implementation (e.g., string)."= This has
>>> interoperability implications because it is not solely a local= matter.
>>> The node may represent these things differently than the netwo= rk
>>> administrator and the preference will not be done properly. RF= C 6724
>>> does not really define what the label is from what I can tell.= It's
>>> used to just allow for policies to prefer a particular source = address,
>>> S, with a particular destination address, D, if "Label(S)= =3D Label(D)".
>>> But to pass a value over a network, and have it be used by the=
>>> recipient, means that a canonical representation of "labe= l" has to
>>> be defined.
>>>
>>
>> Maybe, I don't understand your point quite well.
>> As far as the one-to-one mapping in a node is performed between an=
>> unsinged integer and representation format, I think there will not= arise
>> interoperability issue, such that a policy has different meaning >> depending
>> on a receiving host.

=A0 I'm saying this has an impact on interoperability because the= re's no
way to ensure that this option will be processed correctly. There is no
way for the sender of this option to know how the recipient is
representing labels locally and therefore there is no way for the sender to properly convey his intent in the option he sends.

=A0 I may have existing policies where Label(A) =3D 0x31 and another
where Label(B) =3D 0x01. Now I get an label in my address selection option<= br> that is an unsigned integer of the value 0x01. Should I convert it to a
string, as the text says I SHOULD? Should I use ASCII? So then it will
match Label(A)? Or should I use it directly and it therefore should
match Label(B).

=A0 I just don't think you can mention conversion here. The field has t= o
be treated as an opaque blob or some canonical representation MUST
be defined.

I think what you desc= ribe here is conflict with local policy.

As 3.1 mentioned, the distributed policy will replace local policy, or
will not be used at all.

So= , as far as policy merge does not happen, conflict also will not happen.


>>> =A0 An appendix with examples would be most helpful!
>>>
>>
>> RFC 6724 has a lot of examples for policy table.
>> Do you think we need other examples, or just same ones ?

=A0 Since this draft is about updating, or modifying, the policy tabl= e
it would be nice to see a sample Address Selection Option with at
least one, and preferably more, Address Selection Policy Table
options and what receipt of that message would be to a sample
policy table. Show a before policy table, the message that modifies
it, and an after policy table.

Ok= ay, I'll include some in the rev.


>>>
>>> =A0 Spelling nit: section 3.1 "The choice a SHOULD be def= ault, as far as
>>> the policy table is not configured by the user." There= 9;s an extra
>>> word in there somewhere, or maybe there's some words missi= ng,
>>> it's hard to understand what is being implied.
>>>
>>
>> It means the choice called "a" below should be default.<= br> >> Maybe using parenthesis (a) makes it clearer ?

=A0 That make more sense. Suggest removing the article then too. So make it "Choice (a) SHOULD be default...."
<= br>
Looks good.

Thanks.
=A0

=A0 regards,

=A0 Dan.



--bcaec520eacd21e83404deca9091-- From abegen@cisco.com Mon Jun 10 06:30:18 2013 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 D99AD21F8FA1; Mon, 10 Jun 2013 06:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBrznOhXIqNI; Mon, 10 Jun 2013 06:30:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5F21F8E8F; Mon, 10 Jun 2013 06:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1656; q=dns/txt; s=iport; t=1370871011; x=1372080611; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1TClMAZ7TBVpiT0Htc47wf04H4yfVQ8Y0hjAK6lw1QA=; b=AU+IG5rqr+4we0ZY2Q6H0XOhhZvp5kkGavfesMfxUE1mJ7KTDeY24ofG uVNLwcX2kX0opwfWK9CDLfa5g+T8/PdeRfHPNCI/0/Xsy21mn3O6iLiyI UOWkImj6PYQ0bZZ17gpyfMD3Efds/ZipIfluFs4S5iedWNDK34cjajnPc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPTTtVGtJXG9/2dsb2JhbABagmgheb5BgQQWdIIjAQEBAwF5BQsCAQgiJCERJQIEDgUIh3MDCQYBsDwNiFKMW4IqAjEHgn9hA4hojHGOBYUkgw+CJw X-IronPort-AV: E=Sophos;i="4.87,837,1363132800"; d="scan'208";a="220898528" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jun 2013 13:30:10 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5ADUAcD028996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jun 2013 13:30:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 08:30:10 -0500 From: "Ali C. Begen (abegen)" To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= Thread-Topic: Secdir review of draft-ietf-avtcore-6222bis-03 Thread-Index: AQHOZaUFNPUD6nElDEO1r2PQ5QubBJkvRb+A Date: Mon, 10 Jun 2013 13:30:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7391921F0480754A8D7243B5E8B6D68A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Jun 2013 07:44:58 -0700 Cc: "" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-6222bis-03 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, 10 Jun 2013 13:30:18 -0000 On Jun 10, 2013, at 9:37 AM, Magnus Nystr=F6m wrote: > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. =20 Thanks. > These comments were written primarily for the benefit of the security are= a directors. Document editors and WG chairs should treat these comments jus= t like any other last call comments. > This avtcore document describes a new method for generating unique RTCP c= anonical names and obsoletes RFC 6222. >=20 > The Security Considerations section seems adequate to me. >=20 > (A few side comments:=20 > - RFC 6222 is mentioned in several places (e.g., Section 1, Section 8). S= hould it not also be a reference? I dont think it should as we are not requiring something from 6222. we are = simply mentioning it to emphasize what 6222 did and what this document is d= oing. > - In Section 4.2, it is stated that, if the RTP endpoint is in a virtuali= zed environment, then the MAC address may not be unique. In such cases, the= host shall use the other presented option for short-term persistent RTP CN= AMEs. I wonder if it in general is possible for an RTCP endpoint to determi= nistically determine if its MAC address is unique? It is not in general pos= sible for a process to detect if it is running in a virtualized OS.) I am not sure about this (i.e., do not know how easy for a program to deter= mine whether it is in a virtual system or not). I think if a program is lik= ely to be in a virtual OS, it can simply default to the other option. >=20 > Thanks, > -- Magnus From magnusn@gmail.com Mon Jun 10 07:56:44 2013 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 8E8B421F86CA; Mon, 10 Jun 2013 07:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbATUZG4z2aO; Mon, 10 Jun 2013 07:56:42 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0440A21F940D; Mon, 10 Jun 2013 07:56:36 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so5026207wes.3 for ; Mon, 10 Jun 2013 07:56:35 -0700 (PDT) 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=oQgAr7SDuqpZtYQlkF+L/RjN84fvSNdmeze7mvnHZjY=; b=qwkYH7Rrkx0YkGODPMEuDafv6VbTBB2778IoP7lqxrNDIO4d20sxM2/tVYXC/za2/B e9uMuuH54Hy0Kcz09j+ULyDC3n0WvHQJhIxWBRqybiM1fpaP+MmSHFpso58XK8KqOhgq 8MGwuJhSaf/qRl+OCitpWbHrR1Ck1sDP3D6gECXEz6JlXBYzSJ5vltTJ0+clFAc9gTEC vstrxvbkjxNZv19G+t52QIbPg1y14Yai9XWYWS/Bcd7z0jV5yzjikfsN6lxrve1or+an TdOo0vApJ5YYQsxgtKO1/h6/K/5u6yPXHOffWgDKgPps7ocFXRhL760ozK6RewfXhVs5 gJEQ== MIME-Version: 1.0 X-Received: by 10.180.105.231 with SMTP id gp7mr4894739wib.23.1370876195775; Mon, 10 Jun 2013 07:56:35 -0700 (PDT) Received: by 10.180.163.168 with HTTP; Mon, 10 Jun 2013 07:56:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Jun 2013 07:56:35 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=f46d0442881aae2ca704decdfc99 Cc: "" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-6222bis-03 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, 10 Jun 2013 14:56:45 -0000 --f46d0442881aae2ca704decdfc99 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For the first comment, then I think you should remove the [RFC6222] from the first section because that definitely looks like a reference to me. It is your call, it has nothing to do with security, but when you refer to what is done in a different document several times then I would recommend you to include it at least as an informational reference. For the second comment, how would a program developer know if his program is likely to be executed in a virtualized OS? I think today, pretty much any program could in which case this alternative (the MAC alternative) looks a bit doubtful to even have in there to me. Thanks, /M On Mon, Jun 10, 2013 at 6:30 AM, Ali C. Begen (abegen) wr= ote: > > On Jun 10, 2013, at 9:37 AM, Magnus Nystr=F6m 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. > > Thanks. > > > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these comment= s > just like any other last call comments. > > This avtcore document describes a new method for generating unique RTCP > canonical names and obsoletes RFC 6222. > > > > The Security Considerations section seems adequate to me. > > > > (A few side comments: > > - RFC 6222 is mentioned in several places (e.g., Section 1, Section 8). > Should it not also be a reference? > > I dont think it should as we are not requiring something from 6222. we ar= e > simply mentioning it to emphasize what 6222 did and what this document is > doing. > > > - In Section 4.2, it is stated that, if the RTP endpoint is in a > virtualized environment, then the MAC address may not be unique. In such > cases, the host shall use the other presented option for short-term > persistent RTP CNAMEs. I wonder if it in general is possible for an RTCP > endpoint to deterministically determine if its MAC address is unique? It = is > not in general possible for a process to detect if it is running in a > virtualized OS.) > > I am not sure about this (i.e., do not know how easy for a program to > determine whether it is in a virtual system or not). I think if a program > is likely to be in a virtual OS, it can simply default to the other optio= n. > > > > > Thanks, > > -- Magnus > > --=20 -- Magnus --f46d0442881aae2ca704decdfc99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For the first comment, then I think you sho= uld remove the [RFC6222] from the first section because that definitely loo= ks like a reference to me. It is your call, it has nothing to do with secur= ity, but when you refer to what is done in a different document several tim= es then I would recommend you to include it at least as an informational re= ference.

For the second comment, how would a program developer know if his= program is likely to be executed in a virtualized OS? I think today, prett= y much any program could in which case this alternative (the MAC alternativ= e) looks a bit doubtful to even have in there to me.

Thanks,
/M


<= div class=3D"gmail_quote">On Mon, Jun 10, 2013 at 6:30 AM, Ali C. Begen (ab= egen) <abegen@cisco.com> wrote:

On Jun 10, 2013, at 9:37 AM, Magnus Nystr=F6m <magnusn@gmail.com> 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.<= br>
Thanks.

> 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 avtcore document describes a new method for generating unique RTC= P canonical names and obsoletes RFC 6222.
>
> The Security Considerations section seems adequate to me.
>
> (A few side comments:
> - RFC 6222 is mentioned in several places (e.g., Section 1, Section 8)= . Should it not also be a reference?

I dont think it should as we are not requiring something from 6222. w= e are simply mentioning it to emphasize what 6222 did and what this documen= t is doing.

> - In Section 4.2, it is stated that, if the RTP endpoint is in a virtu= alized environment, then the MAC address may not be unique. In such cases, = the host shall use the other presented option for short-term persistent RTP= CNAMEs. I wonder if it in general is possible for an RTCP endpoint to dete= rministically determine if its MAC address is unique? It is not in general = possible for a process to detect if it is running in a virtualized OS.)

I am not sure about this (i.e., do not know how easy for a program to= determine whether it is in a virtual system or not). I think if a program = is likely to be in a virtual OS, it can simply default to the other option.=

>
> Thanks,
> -- Magnus




--
-- Magnus
--f46d0442881aae2ca704decdfc99-- From yi.jiazi@gmail.com Tue Jun 11 01:52:57 2013 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 9AE0A21F9A7E; Tue, 11 Jun 2013 01:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8G9zIdcFOyN; Tue, 11 Jun 2013 01:52:57 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 86DFB21F9A84; Tue, 11 Jun 2013 01:52:54 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so5542810wes.21 for ; Tue, 11 Jun 2013 01:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Smsx6gv7AsIawp3PDro8N/+6isgO9BbEg6tV/fvMvrM=; b=RzU/cJ1BcapZW4PGw4mrBirB4QnAOLTO9GhuIMBJwRyit3RN6vDgLhg1k9Z2WEfnQA HlNrrikc5QzKWP7fo2EatoPZFxTg5bVyLPK1Yqpf/vf0tDu+B4S2NWhrq+8qtq4py413 KvoZp0MbCr+ajN0/vITqP6qQ83kcpxfskyehzH9EoOi/k8blBcepVlGCqhN+68tMBr8Q fJOM6OWYLH6vsNsBNUNGywjiOdG59HVTJGs7ZVIuneLPYoj0IHBW8hY62+MIsyO0M7Pb j4lUZqvRkENVr82uTpK8yraRx3Q2NtdsMxrjChCiWRQ3XHzasYvuo2XhmbqdfPMG7GV3 iY7A== X-Received: by 10.194.237.38 with SMTP id uz6mr7792648wjc.73.1370940773746; Tue, 11 Jun 2013 01:52:53 -0700 (PDT) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPSA id f8sm15676251wiv.0.2013.06.11.01.52.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Jun 2013 01:52:53 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jiazi Yi In-Reply-To: Date: Tue, 11 Jun 2013 10:52:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BB5E033-6EBD-4218-9022-20245E60EDE0@gmail.com> References: To: Matthew Lepinski X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Tue, 11 Jun 2013 01:55:25 -0700 Cc: draft-ietf-manet-nhdp-sec-threats@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-manet-nhdp-sec-threats-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: Tue, 11 Jun 2013 08:52:57 -0000 Dear Matthew,=20 Thanks for your review of the draft. Please check the reply inline: On Jun 10, 2013, at 06:13 , Matthew Lepinski = wrote: > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > This document provides a taxonomy of attacks against the Mobile Ad Hoc = Network Neighborhood Discovery Protocol (NHDP) [RFC 6130]. The document = also contains a discussion of the impact of these attacks on running on = top of NHDP (in particular, OLSRv2 and SMF) >=20 > Having reviewed the document, I do not see substantial issues in the = document. I believe it is reasonable to publish as an informational RFC. >=20 > One minor issue: The replay attack described in Section 4.5 did not = seem substantially different than the attacks described in Section 4.4. = It is not clear to me how replaying a message from another part of the = network is any worse (or substantially different) than just fabricating = a message claiming connectivity that does not exist (i.e., like what is = described in 4.4.2). I would recommend either deleting 4.5 or else = clarifying how these attacks are substantially different. The main difference between 4.4 and 4.5 is that reply attack is based on = manipulating the transmission channel, while Incorrect HELLO message = generation is based on wrong HELLO message.=20 We proposed more text to describe the difference in the end of section = 4.5: =3D=3D Compared to Incorrect HELLO Message attacks described in Section 4.4, = the messages used in Replay attack are legitimate messages sent out by = (non-malicious) NHDP routers and replayed at a later time or different = locality by malicious routers. This makes this kind of attack harder to = be detect and to counteract: integrity checks cannot help in this case = as the original message ICV was correctly calculated. =3D=3D=3D=3D If you are OK with the text, we will add it to the next revision.=20 >=20 > Trivial nit: In Section 5, "a Compromised NHDP router will seek to = manipulate" -- substitute "may seek" instead of "will seek". We don't = know for certain what a compromised router will do (unless one assigns = clear motivation to the adversary, which this document does not). Yes, will be corrected in the next revision :) thanks again best Jiazi= From otroan@employees.org Tue Jun 11 02:25:24 2013 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 80F9821F9607; Tue, 11 Jun 2013 02:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSxii9FmUWiT; Tue, 11 Jun 2013 02:25:02 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4E71021F89EB; Tue, 11 Jun 2013 02:24:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAEjstlGQ/khR/2dsb2JhbABZgwm/QnsWdIIjAQEEAXkFCwUGDjhXBiSHdga5dY8EMweCf2EDqQKDETo X-IronPort-AV: E=Sophos;i="4.87,844,1363132800"; d="scan'208";a="14146161" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 11 Jun 2013 09:24:55 +0000 Received: from dhcp-lys02-vla252-10-147-116-93.cisco.com (dhcp-lys02-vla252-10-147-116-93.cisco.com [10.147.116.93]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5B9OqtY009364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jun 2013 09:24:52 GMT Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Ole Troan X-Priority: 3 (Normal) In-Reply-To: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> Date: Tue, 11 Jun 2013 11:24:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Tue, 11 Jun 2013 02:33:06 -0700 Cc: draft-ietf-6man-addr-select-opt.all@tools.ietf.org, draft-ietf-6man-rfc3484bis@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 11 Jun 2013 09:25:25 -0000 Dan, let me chime in as the document shepherd. (thank you very much for the thorough comments by the way). > For instance, while I think I understand the policy override of RFC > 6724, having the Automatic Row Additions Flag be part of the address > selection options seems problematic. If it is set to zero, then what = are > the semantics of such a message? "Here's an address selection option > but don't you dare use it!"? What is the point? Me, as a node, can = have > this as part of my policy state which would allow me to ignore such > an update but to have the bit be part of the option to update does > not seem to make much sense. The semantics of the message needs > to be explained much more clearly, or the bit needs to be removed > from the message. my reading of the meaning of the A flag is a little different. (I have = cc'ed the authors of rfc6724 for confirmation.) an implementation of RFC6724 may automatically add entries in the policy = table based on addresses configured on the node. e.g. the node has an interface with a ULA address. RFC6724 also says: An implementation SHOULD provide a means (the Automatic Row Additions = flag) for an administrator to disable automatic row additions. the A-flag in draft-ietf-6man-addr-select-opt provides the means. it does not affect the policy entries that is contained in the DHCP = option. the A-flag only affects the RFC6724 behaviour of adding entries based on = address configuration on the node. cheers, Ole= From dharkins@lounge.org Tue Jun 11 09:32:02 2013 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 03BE321F9622; Tue, 11 Jun 2013 09:32:02 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2ncRbKajHb5; Tue, 11 Jun 2013 09:31:56 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D899021F8BC0; Tue, 11 Jun 2013 09:31:56 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2F449A888006; Tue, 11 Jun 2013 09:31:56 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 11 Jun 2013 09:31:56 -0700 (PDT) Message-ID: In-Reply-To: <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> Date: Tue, 11 Jun 2013 09:31:56 -0700 (PDT) From: "Dan Harkins" To: "Ole Troan" 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 Cc: draft-ietf-6man-addr-select-opt.all@tools.ietf.org, draft-ietf-6man-rfc3484bis@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 11 Jun 2013 16:32:02 -0000 Hi Ole, On Tue, June 11, 2013 2:24 am, Ole Troan wrote: > Dan, > > let me chime in as the document shepherd. > (thank you very much for the thorough comments by the way). > >> For instance, while I think I understand the policy override of RFC >> 6724, having the Automatic Row Additions Flag be part of the address >> selection options seems problematic. If it is set to zero, then what are >> the semantics of such a message? "Here's an address selection option >> but don't you dare use it!"? What is the point? Me, as a node, can have >> this as part of my policy state which would allow me to ignore such >> an update but to have the bit be part of the option to update does >> not seem to make much sense. The semantics of the message needs >> to be explained much more clearly, or the bit needs to be removed >> from the message. > > my reading of the meaning of the A flag is a little different. (I have > cc'ed the authors of rfc6724 for confirmation.) > > an implementation of RFC6724 may automatically add entries in the policy > table based on addresses configured on the node. > e.g. the node has an interface with a ULA address. > > RFC6724 also says: > An implementation SHOULD provide a means (the Automatic Row Additions > flag) for an administrator to disable > automatic row additions. That makes perfect sense. A client implementation SHOULD provide a means to disable automatic row additions. So it has some knob that can be turned on or off locally that would allow for update of its policy table by receiving policy options (enable) or forbid received policy options from updating the policy table (disable). > the A-flag in draft-ietf-6man-addr-select-opt provides the means. So this is where I'm confused. The sender of the policy option should not have the ability to control the knob that an implementation added locally to satisfy RFC 6724. If a client implementation sets its knob to "disable" then it forbids policy option updates to its policy table. It shouldn't inspect the received option update to decide whether it should override the setting of its local knob. This seems like a security issue to me. There's a reason why an implementation would choose to disable updates of its policy table and allowing the sender of policy updates to override that seems wrong. > it does not affect the policy entries that is contained in the DHCP > option. > the A-flag only affects the RFC6724 behaviour of adding entries based on > address configuration on the node. Again, according to the draft a message can be received by a client implementation that provides policy update options to its policy table with semantics of "you SHOULD NOT use these!" So what is the point of sending that message? Why not just refrain from sending the message if that's what the message is? Would you ever tell someone, "disregard what I am about to tell you"? I can't see why. And that's what the semantics of this message seem to be. regards, Dan. From mlepinski.ietf@gmail.com Tue Jun 11 10:38:33 2013 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 682FC21F9702; Tue, 11 Jun 2013 10:38:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I8s4F9v51IM; Tue, 11 Jun 2013 10:38:28 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id EBFB721F8ADF; Tue, 11 Jun 2013 10:38:27 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id nd7so2445224qeb.5 for ; Tue, 11 Jun 2013 10:38:27 -0700 (PDT) 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=ib8Hz7NolrPF8B8/uQT2iOfiEpC8O9MVMyv4Wq07z8o=; b=PvcPtdt/cl9FyAyuVFLChwKFX9KzCbQwBd5XxL2PMi7aR/ZYIPhicQo+VlajQwEPqO 5CMBo9wMt+j4GZ27Tgt7svgx67D7N9rw35mu8ugdL+GVpXwRk861VcPyeoPDYaD4vw0Z MevPYjlI8IAUshuxhcLcKseQzLUGfzs4GXCQlcRdCXsy1DuiklhqkxacfJzjkHVv8iQA h94PhimI6EAdsiL5002HrM8+wITS7irZiMTHt+TmWEiWupKweSXAm80HiGp5gePh9jBY wUhnCzkZdtVDtPsT/fleKJk1WzGUyXTKiadblO0wUbgphz8wgfndh85PAIvm4StEUfR9 OywQ== MIME-Version: 1.0 X-Received: by 10.224.161.83 with SMTP id q19mr19857120qax.32.1370972307328; Tue, 11 Jun 2013 10:38:27 -0700 (PDT) Received: by 10.49.1.43 with HTTP; Tue, 11 Jun 2013 10:38:27 -0700 (PDT) In-Reply-To: <5BB5E033-6EBD-4218-9022-20245E60EDE0@gmail.com> References: <5BB5E033-6EBD-4218-9022-20245E60EDE0@gmail.com> Date: Tue, 11 Jun 2013 13:38:27 -0400 Message-ID: From: Matthew Lepinski To: Jiazi Yi Content-Type: multipart/alternative; boundary=089e0149ccde601bb604dee45d6b Cc: draft-ietf-manet-nhdp-sec-threats@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-manet-nhdp-sec-threats-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: Tue, 11 Jun 2013 17:38:33 -0000 --089e0149ccde601bb604dee45d6b Content-Type: text/plain; charset=ISO-8859-1 Thank you, I found that clarification helpful. Also, as I indicated, I think the document is quite good. I think it valuable to document the attacks that can be preformed by a compromised device in a manet and the impact on the network. (Although, I am mostly left thinking ... Wow, compromising a routing in an ad hoc network is just really, really bad :-< ) On Tue, Jun 11, 2013 at 4:52 AM, Jiazi Yi wrote: > Dear Matthew, > > Thanks for your review of the draft. Please check the reply inline: > > On Jun 10, 2013, at 06:13 , Matthew Lepinski > 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 a taxonomy of attacks against the Mobile Ad Hoc > Network Neighborhood Discovery Protocol (NHDP) [RFC 6130]. The document > also contains a discussion of the impact of these attacks on running on top > of NHDP (in particular, OLSRv2 and SMF) > > > > Having reviewed the document, I do not see substantial issues in the > document. I believe it is reasonable to publish as an informational RFC. > > > > One minor issue: The replay attack described in Section 4.5 did not seem > substantially different than the attacks described in Section 4.4. It is > not clear to me how replaying a message from another part of the network is > any worse (or substantially different) than just fabricating a message > claiming connectivity that does not exist (i.e., like what is described in > 4.4.2). I would recommend either deleting 4.5 or else clarifying how these > attacks are substantially different. > > The main difference between 4.4 and 4.5 is that reply attack is based on > manipulating the transmission channel, while Incorrect HELLO message > generation is based on wrong HELLO message. > We proposed more text to describe the difference in the end of section 4.5: > > == > Compared to Incorrect HELLO Message attacks described in Section 4.4, the > messages used in Replay attack are legitimate messages sent out by > (non-malicious) NHDP routers and replayed at a later time or different > locality by malicious routers. This makes this kind of attack harder to be > detect and to counteract: integrity checks cannot help in this case as the > original message ICV was correctly calculated. > ==== > > If you are OK with the text, we will add it to the next revision. > > > > > > Trivial nit: In Section 5, "a Compromised NHDP router will seek to > manipulate" -- substitute "may seek" instead of "will seek". We don't know > for certain what a compromised router will do (unless one assigns clear > motivation to the adversary, which this document does not). > > Yes, will be corrected in the next revision :) > > thanks again > > best > > Jiazi --089e0149ccde601bb604dee45d6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you, I found that clarification helpful.
<= br>Also, as I indicated, I think the document is quite good. I think it val= uable to document the attacks that can be preformed by a compromised device= in a manet and the impact on the network. (Although, I am mostly left thin= king ... Wow, compromising a routing in an ad hoc network is just really, r= eally bad :-< )


On Tue,= Jun 11, 2013 at 4:52 AM, Jiazi Yi <yi.jiazi@gmail.com> wro= te:
Dear Matthew,

Thanks for your review of the draft. Please check the reply inline:

On Jun 10, 2013, at 06:13 , Matthew Lepinski <mlepinski.ietf@gmail.com> 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. = =A0These comments were written primarily for the benefit of the security ar= ea directors. =A0Document editors and WG chairs should treat these comments= just like any other last call comments.
>
> This document provides a taxonomy of attacks against the Mobile Ad Hoc= Network Neighborhood Discovery Protocol (NHDP) [RFC 6130]. The document al= so contains a discussion of the impact of these attacks on running on top o= f NHDP (in particular, OLSRv2 and SMF)
>
> Having reviewed the document, I do not see substantial issues in the d= ocument. I believe it is reasonable to publish as an informational RFC.
>
> One minor issue: The replay attack described in Section 4.5 did not se= em substantially different than the attacks described in Section 4.4. It is= not clear to me how replaying a message from another part of the network i= s any worse (or substantially different) than just fabricating a message cl= aiming connectivity that does not exist (i.e., like what is described in 4.= 4.2). I would recommend either deleting 4.5 or else clarifying how these at= tacks are substantially different.

The main difference between 4.4 and 4.5 is that reply attack is based= on manipulating the transmission channel, while Incorrect HELLO message ge= neration is based on wrong HELLO message.
We proposed more text to describe the difference in the end of section 4.5:=

=3D=3D
Compared to Incorrect HELLO Message attacks described in Section 4.4, the m= essages used in Replay attack are legitimate messages sent out by (non-mali= cious) NHDP routers and replayed at a later time or different locality by m= alicious routers. This makes this kind of attack harder to be detect and to= counteract: integrity checks cannot help in this case as the original mess= age ICV was correctly calculated.
=3D=3D=3D=3D

If you are OK with the text, we will add it to the next revision.


>
> Trivial nit: In Section 5, "a Compromised NHDP router will seek t= o manipulate" -- substitute "may seek" instead of "will= seek". We don't know for certain what a compromised router will d= o (unless one assigns clear motivation to the adversary, which this documen= t does not).

Yes, will be corrected in the next revision :)

thanks again

best

Jiazi

--089e0149ccde601bb604dee45d6b-- From david.waltermire@nist.gov Tue Jun 11 11:54:39 2013 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 8C04421F992A; Tue, 11 Jun 2013 11:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.284 X-Spam-Level: X-Spam-Status: No, score=-5.284 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI9pGgDPck39; Tue, 11 Jun 2013 11:54:33 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9AF21F9811; Tue, 11 Jun 2013 11:54:33 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Jun 2013 14:54:06 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 11 Jun 2013 14:54:31 -0400 From: "Waltermire, David A." To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-housley-rfc2050bis-01.all@tools.ietf.org" Date: Tue, 11 Jun 2013 14:54:30 -0400 Thread-Topic: secdir review of draft-housley-rfc2050bis-01 Thread-Index: Ac5m0xncB9thc7fdRLyKE6dmlK6umw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930C049D6C6DMBCLUSTERxcha_" MIME-Version: 1.0 Subject: [secdir] secdir review of draft-housley-rfc2050bis-01 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, 11 Jun 2013 18:54:39 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930C049D6C6DMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft, a proposed update to RFC 2050, documents current policies and processes used in the Internet Numbers Registry System for the assignment of the Internet Protocol (IP) address space and autonomous system (AS) numbers. It does not propose any changes to the Internet Numbers Registry System. After reviewing this informational document I do not have any security-related concerns. Sincerely, Dave Waltermire --_000_D7A0423E5E193F40BE6E94126930C4930C049D6C6DMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2Vj dGlvbjE+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MmbmJzcDtvbmdvaW5nIGVmZm9y dCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVT Ry4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJl bmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBh bnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+VGhpcyBk cmFmdCwgYSBwcm9wb3NlZCB1cGRhdGUgdG8gUkZDIDIwNTAsIGRvY3VtZW50cyBjdXJyZW50IHBv bGljaWVzIGFuZCBwcm9jZXNzZXMgdXNlZCBpbiB0aGUgSW50ZXJuZXQgTnVtYmVycyBSZWdpc3Ry eSBTeXN0ZW0gZm9yIHRoZSBhc3NpZ25tZW50IG9mIHRoZSBJbnRlcm5ldCBQcm90b2NvbCAoSVAp IGFkZHJlc3Mgc3BhY2UgYW5kIGF1dG9ub21vdXMgc3lzdGVtIChBUykgbnVtYmVycy4gSXQgZG9l cyBub3QgcHJvcG9zZSBhbnkgY2hhbmdlcyB0byB0aGUgSW50ZXJuZXQgTnVtYmVycyBSZWdpc3Ry eSBTeXN0ZW0uPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5BZnRlciByZXZpZXdpbmcgdGhpcyBpbmZv cm1hdGlvbmFsIGRvY3VtZW50IEkgZG8gbm90IGhhdmUgYW55IHNlY3VyaXR5LXJlbGF0ZWQgY29u Y2VybnMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5TaW5jZXJlbHksPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PkRhdmUgV2FsdGVybWlyZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930C049D6C6DMBCLUSTERxcha_-- From housley@vigilsec.com Tue Jun 11 14:56:26 2013 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 12B8621F9A41; Tue, 11 Jun 2013 14:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGqEg+KBmXSM; Tue, 11 Jun 2013 14:56:21 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D3B4A21F9A3D; Tue, 11 Jun 2013 14:56:20 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 40C09F24077; Tue, 11 Jun 2013 17:56:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id vuCIefixkbWT; Tue, 11 Jun 2013 17:56:00 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4C9C1F24072; Tue, 11 Jun 2013 17:56:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-36--308928789 From: Russ Housley In-Reply-To: Date: Tue, 11 Jun 2013 17:56:18 -0400 Message-Id: References: To: "Waltermire, David A." X-Mailer: Apple Mail (2.1085) Cc: "draft-housley-rfc2050bis-01.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-housley-rfc2050bis-01 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, 11 Jun 2013 21:56:26 -0000 --Apple-Mail-36--308928789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dave: Thanks for taking the time to review it. Russ On Jun 11, 2013, at 2:54 PM, Waltermire, David A. wrote: > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. > =20 > This draft, a proposed update to RFC 2050, documents current policies = and processes used in the Internet Numbers Registry System for the = assignment of the Internet Protocol (IP) address space and autonomous = system (AS) numbers. It does not propose any changes to the Internet = Numbers Registry System. > =20 > After reviewing this informational document I do not have any = security-related concerns. > =20 > Sincerely, > Dave Waltermire > =20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail-36--308928789 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I have reviewed this document = as part of the security directorate's ongoing effort to review all = IETF documents being processed by the IESG.  These comments were = written primarily for the benefit of the security area directors.  = Document editors and WG chairs should treat these comments just like any = other last call comments.
 
This draft, a proposed update to RFC 2050, documents = current policies and processes used in the Internet Numbers Registry = System for the assignment of the Internet Protocol (IP) address space = and autonomous system (AS) numbers. It does not propose any changes to = the Internet Numbers Registry System.
 
After reviewing this = informational document I do not have any security-related = concerns.
 
Sincerely,
Dave = Waltermire
 , draft-ietf-6man-rfc3484bis@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 12 Jun 2013 06:55:08 -0000 --047d7b3390172e8d8804deef7e08 Content-Type: text/plain; charset=ISO-8859-1 Hi, 2013/6/12 Dan Harkins > > Hi Ole, > > On Tue, June 11, 2013 2:24 am, Ole Troan wrote: > > Dan, > > > > let me chime in as the document shepherd. > > (thank you very much for the thorough comments by the way). > > > >> For instance, while I think I understand the policy override of RFC > >> 6724, having the Automatic Row Additions Flag be part of the address > >> selection options seems problematic. If it is set to zero, then what are > >> the semantics of such a message? "Here's an address selection option > >> but don't you dare use it!"? What is the point? Me, as a node, can have > >> this as part of my policy state which would allow me to ignore such > >> an update but to have the bit be part of the option to update does > >> not seem to make much sense. The semantics of the message needs > >> to be explained much more clearly, or the bit needs to be removed > >> from the message. > > > > my reading of the meaning of the A flag is a little different. (I have > > cc'ed the authors of rfc6724 for confirmation.) > > > > an implementation of RFC6724 may automatically add entries in the policy > > table based on addresses configured on the node. > > e.g. the node has an interface with a ULA address. > > > > RFC6724 also says: > > An implementation SHOULD provide a means (the Automatic Row Additions > > flag) for an administrator to disable > > automatic row additions. > > That makes perfect sense. A client implementation SHOULD provide a > means to disable automatic row additions. So it has some knob that can > be turned on or off locally that would allow for update of its policy table > by receiving policy options (enable) or forbid received policy options from > updating the policy table (disable). > > > the A-flag in draft-ietf-6man-addr-select-opt provides the means. > > So this is where I'm confused. The sender of the policy option should > not have the ability to control the knob that an implementation added > locally to satisfy RFC 6724. If a client implementation sets its knob to > "disable" then it forbids policy option updates to its policy table. It > shouldn't inspect the received option update to decide whether it > should override the setting of its local knob. > > This seems like a security issue to me. There's a reason why an > implementation would choose to disable updates of its policy table > and allowing the sender of policy updates to override that seems > wrong. > In my understanding, - RFC 6724 defines a knob for switching automatic row addition. - addr-select-opt defines a knob for switching whether accepting automatic row addition flag delivered or not. and, if the second knob is switched to "accept", then the first knob is overridden by a delivered flag. This is common case in moderen user OS settings, such that the DNS server configuration can be switched to automatic(delivered from network), or to locally configured to some value. > > > it does not affect the policy entries that is contained in the DHCP > > option. > > the A-flag only affects the RFC6724 behaviour of adding entries based on > > address configuration on the node. > > Again, according to the draft a message can be received by a client > implementation that provides policy update options to its policy table > with semantics of "you SHOULD NOT use these!" So what is the point > of sending that message? Why not just refrain from sending the message > if that's what the message is? > > Would you ever tell someone, "disregard what I am about to tell you"? I > can't see why. And that's what the semantics of this message seem to be. > As I mentioned in the previous e-mail, that I sent 10 June, when this A flag is turned on, the DHCP option should not carry policy table, and a receiver should ignore it, which I have to add some text in the rev. Thanks. > > regards, > > Dan. > > > --047d7b3390172e8d8804deef7e08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

2013/6/12 Dan Harkins <dharkins@lounge.org>

=A0 Hi Ole,

On Tue, June 11, 2013 2:24 am, Ole Troan wrote:
> Dan,
>
> let me chime in as the document shepherd.
> (thank you very much for the thorough comments by the way).
>
>> =A0For instance, while I think I understand the policy override of= RFC
>> 6724, having the Automatic Row Additions Flag be part of the addre= ss
>> selection options seems problematic. If it is set to zero, then wh= at are
>> the semantics of such a message? "Here's an address selec= tion option
>> but don't you dare use it!"? What is the point? Me, as a = node, can have
>> this as part of my policy state which would allow me to ignore suc= h
>> an update but to have the bit be part of the option to update does=
>> not seem to make much sense. The semantics of the message needs >> to be explained much more clearly, or the bit needs to be removed<= br> >> from the message.
>
> my reading of the meaning of the A flag is a little different. (I have=
> cc'ed the authors of rfc6724 for confirmation.)
>
> an implementation of RFC6724 may automatically add entries in the poli= cy
> table based on addresses configured on the node.
> e.g. the node has an interface with a ULA address.
>
> RFC6724 also says:
> =A0 =A0An implementation SHOULD provide a means (the Automatic Row Add= itions
> flag) for an administrator to disable
> =A0 =A0automatic row additions.

=A0 That makes perfect sense. A client implementation SHOULD provide = a
means to disable automatic row additions. So it has some knob that can
be turned on or off locally that would allow for update of its policy table=
by receiving policy options (enable) or forbid received policy options from=
updating the policy table (disable).

> the A-flag in draft-ietf-6man-addr-select-opt provides the means.

=A0 So this is where I'm confused. The sender of the policy optio= n should
not have the ability to control the knob that an implementation added
locally to satisfy RFC 6724. If a client implementation sets its knob to "disable" then it forbids policy option updates to its policy tab= le. It
shouldn't inspect the received option update to decide whether it
should override the setting of its local knob.

=A0 This seems like a security issue to me. There's a reason why an
implementation would choose to disable updates of its policy table
and allowing the sender of policy updates to override that seems
wrong.

In my understanding,
=
- RFC 6724 defines a knob for switching automatic row addition.<= /div>
- addr-select-opt defines a knob for switching whether acce= pting automatic row addition flag delivered or not.

and, if the second knob is switched to &quo= t;accept", then the first knob is overridden by a delivered flag.

This is common case in moderen user OS settings,= such that the DNS server configuration can be
switched to automatic(delivered from network), or to locally con= figured to some value.

=A0

> it does not affect the policy entries that is contained in the DHCP > option.
> the A-flag only affects the RFC6724 behaviour of adding entries based = on
> address configuration on the node.

=A0 Again, according to the draft a message can be received by a clie= nt
implementation that provides policy update options to its policy table
with semantics of "you SHOULD NOT use these!" So what is the poin= t
of sending that message? Why not just refrain from sending the message
if that's what the message is?

=A0 Would you ever tell someone, "disregard what I am about to tell yo= u"? I
can't see why. And that's what the semantics of this message seem t= o be.

As I mentioned in the previ= ous e-mail, that I sent 10 June,
when this A flag is turned= on, the DHCP option should not carry policy table,
and a receiver should ignore it, which I have to add some text i= n the rev.=A0

Thanks.
=A0

=A0 regards,

=A0 Dan.



--047d7b3390172e8d8804deef7e08-- From dharkins@lounge.org Wed Jun 12 01:06:08 2013 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 5FE1421F9BFD; Wed, 12 Jun 2013 01:06:08 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdoWTa0QUa0Y; Wed, 12 Jun 2013 01:06:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E72E321F9C02; Wed, 12 Jun 2013 01:06:00 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3B177A888008; Wed, 12 Jun 2013 01:06:00 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 12 Jun 2013 01:06:00 -0700 (PDT) Message-ID: In-Reply-To: References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> Date: Wed, 12 Jun 2013 01:06:00 -0700 (PDT) From: "Dan Harkins" To: "Arifumi Matsumoto" 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 Cc: secdir@ietf.org, "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , draft-ietf-6man-rfc3484bis@tools.ietf.org, Ole Troan , iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 12 Jun 2013 08:06:08 -0000 Hi, On Tue, June 11, 2013 11:55 pm, Arifumi Matsumoto wrote: > Hi, > > 2013/6/12 Dan Harkins > >> >> Hi Ole, >> >> On Tue, June 11, 2013 2:24 am, Ole Troan wrote: >> > Dan, >> > >> > let me chime in as the document shepherd. >> > (thank you very much for the thorough comments by the way). >> > >> >> For instance, while I think I understand the policy override of RFC >> >> 6724, having the Automatic Row Additions Flag be part of the address >> >> selection options seems problematic. If it is set to zero, then what >> are >> >> the semantics of such a message? "Here's an address selection option >> >> but don't you dare use it!"? What is the point? Me, as a node, can >> have >> >> this as part of my policy state which would allow me to ignore such >> >> an update but to have the bit be part of the option to update does >> >> not seem to make much sense. The semantics of the message needs >> >> to be explained much more clearly, or the bit needs to be removed >> >> from the message. >> > >> > my reading of the meaning of the A flag is a little different. (I have >> > cc'ed the authors of rfc6724 for confirmation.) >> > >> > an implementation of RFC6724 may automatically add entries in the >> policy >> > table based on addresses configured on the node. >> > e.g. the node has an interface with a ULA address. >> > >> > RFC6724 also says: >> > An implementation SHOULD provide a means (the Automatic Row >> Additions >> > flag) for an administrator to disable >> > automatic row additions. >> >> That makes perfect sense. A client implementation SHOULD provide a >> means to disable automatic row additions. So it has some knob that can >> be turned on or off locally that would allow for update of its policy >> table >> by receiving policy options (enable) or forbid received policy options >> from >> updating the policy table (disable). >> >> > the A-flag in draft-ietf-6man-addr-select-opt provides the means. >> >> So this is where I'm confused. The sender of the policy option should >> not have the ability to control the knob that an implementation added >> locally to satisfy RFC 6724. If a client implementation sets its knob to >> "disable" then it forbids policy option updates to its policy table. It >> shouldn't inspect the received option update to decide whether it >> should override the setting of its local knob. >> >> This seems like a security issue to me. There's a reason why an >> implementation would choose to disable updates of its policy table >> and allowing the sender of policy updates to override that seems >> wrong. >> > > In my understanding, > - RFC 6724 defines a knob for switching automatic row addition. > - addr-select-opt defines a knob for switching whether accepting automatic > row addition flag delivered or not. > > and, if the second knob is switched to "accept", then the first knob is > overridden by a delivered flag. So you're saying that the local knob can be overridden by the bit in the message? That begs the question: why would one send a message with the "delivered flag" set to "don't accept", meaning "don't accept this update"? How is that different than omitting this "don't accept" information from the message in the first place? > This is common case in moderen user OS settings, such that the DNS server > configuration can be > switched to automatic(delivered from network), or to locally configured to > some value. But why would the network set an option indicating that the recipient should not use this configuration"? If the recipient has a knob indicating that local policy cannot be updated then the bit has no effect and if the recipient has a knob indicating that the policy can be updated then setting the the bit in the message should be meaningless. >> >> > it does not affect the policy entries that is contained in the DHCP >> > option. >> > the A-flag only affects the RFC6724 behaviour of adding entries based >> on >> > address configuration on the node. >> >> Again, according to the draft a message can be received by a client >> implementation that provides policy update options to its policy table >> with semantics of "you SHOULD NOT use these!" So what is the point >> of sending that message? Why not just refrain from sending the message >> if that's what the message is? >> >> Would you ever tell someone, "disregard what I am about to tell you"? >> I >> can't see why. And that's what the semantics of this message seem to be. >> > > As I mentioned in the previous e-mail, that I sent 10 June, > when this A flag is turned on, the DHCP option should not carry policy > table, > and a receiver should ignore it, which I have to add some text in the rev. But why would a server send an address selection option that said, "don't use this"? Once again, it makes no sense to have these semantics. If you notice, this question seems to be repeated over and over yet I have not yet received an answer why or an statement that I don't understand the semantics of the message. So what is it? Do I not understand (in which you should explain exactly why) or is this message meaningless (in which case why is it part of your draft)? regards, Dan. From n@arifumi.net Wed Jun 12 01:17:47 2013 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 DCD5C21F9C1F for ; Wed, 12 Jun 2013 01:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgrVUOBDOYXL for ; Wed, 12 Jun 2013 01:17:38 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA26521F9C07 for ; Wed, 12 Jun 2013 01:17:37 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so6019801pdj.17 for ; Wed, 12 Jun 2013 01:17:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=LKANy6UzNsySl54YD/0vwK8qR0Loq5JhHgOoe7qyD7A=; b=P3fVQOxZkD6mE2BG/ErN+qTzb5Og5BOobjd7EowOtgdIKqHwSAV0mYShum02FrGipD MR7RxttA3IOHWeF6dFH6JN+ur7hCvR1Y8qfgdHXUqNIesTF5PY6baR541KHCqWsZF3cU PTiWvlh+As4cnHtBjAR5K8g/ViKXRMuOnU8GZlY0N2ogpWUnzGSo5+61LvqBsWAIV6jX Q045zTKwattgUp6+HVufFtiZoKnUPAYb07uHke7WBhT9rWkP3TygvqQnZ1OhymYO/81y 0GL+Jtwr9XKY5I6D60AH7ZeU3BDV5CzQRdz/bBQoVIQjE536jQZEt5eg/+ucQFTG32aV jWvg== MIME-Version: 1.0 X-Received: by 10.66.145.34 with SMTP id sr2mr15868332pab.94.1371025055494; Wed, 12 Jun 2013 01:17:35 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.194.198 with HTTP; Wed, 12 Jun 2013 01:17:35 -0700 (PDT) X-Originating-IP: [2001:df0:45:20::61] In-Reply-To: References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> Date: Wed, 12 Jun 2013 17:17:35 +0900 X-Google-Sender-Auth: xvBkPp6vL5na5M9_SLcsFQf62k8 Message-ID: From: Arifumi Matsumoto To: Dan Harkins Content-Type: multipart/alternative; boundary=047d7b6d7e3269479d04def0a586 X-Gm-Message-State: ALoCoQlsjm5ezga1vt3nKNNmNE9tFOhMypaSFsbnG7nidU25JZ07N1BloIYxmetgaW6zqyG7DwjQ Cc: secdir@ietf.org, "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , draft-ietf-6man-rfc3484bis@tools.ietf.org, Ole Troan , iesg@ietf.org, Arifumi Matsumoto Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 12 Jun 2013 08:17:47 -0000 --047d7b6d7e3269479d04def0a586 Content-Type: text/plain; charset=ISO-8859-1 Hi, 2013/6/12 Dan Harkins > > Hi, > > On Tue, June 11, 2013 11:55 pm, Arifumi Matsumoto wrote: > > Hi, > > > > 2013/6/12 Dan Harkins > > > >> > >> Hi Ole, > >> > >> On Tue, June 11, 2013 2:24 am, Ole Troan wrote: > >> > Dan, > >> > > >> > let me chime in as the document shepherd. > >> > (thank you very much for the thorough comments by the way). > >> > > >> >> For instance, while I think I understand the policy override of RFC > >> >> 6724, having the Automatic Row Additions Flag be part of the address > >> >> selection options seems problematic. If it is set to zero, then what > >> are > >> >> the semantics of such a message? "Here's an address selection option > >> >> but don't you dare use it!"? What is the point? Me, as a node, can > >> have > >> >> this as part of my policy state which would allow me to ignore such > >> >> an update but to have the bit be part of the option to update does > >> >> not seem to make much sense. The semantics of the message needs > >> >> to be explained much more clearly, or the bit needs to be removed > >> >> from the message. > >> > > >> > my reading of the meaning of the A flag is a little different. (I have > >> > cc'ed the authors of rfc6724 for confirmation.) > >> > > >> > an implementation of RFC6724 may automatically add entries in the > >> policy > >> > table based on addresses configured on the node. > >> > e.g. the node has an interface with a ULA address. > >> > > >> > RFC6724 also says: > >> > An implementation SHOULD provide a means (the Automatic Row > >> Additions > >> > flag) for an administrator to disable > >> > automatic row additions. > >> > >> That makes perfect sense. A client implementation SHOULD provide a > >> means to disable automatic row additions. So it has some knob that can > >> be turned on or off locally that would allow for update of its policy > >> table > >> by receiving policy options (enable) or forbid received policy options > >> from > >> updating the policy table (disable). > >> > >> > the A-flag in draft-ietf-6man-addr-select-opt provides the means. > >> > >> So this is where I'm confused. The sender of the policy option should > >> not have the ability to control the knob that an implementation added > >> locally to satisfy RFC 6724. If a client implementation sets its knob to > >> "disable" then it forbids policy option updates to its policy table. It > >> shouldn't inspect the received option update to decide whether it > >> should override the setting of its local knob. > >> > >> This seems like a security issue to me. There's a reason why an > >> implementation would choose to disable updates of its policy table > >> and allowing the sender of policy updates to override that seems > >> wrong. > >> > > > > In my understanding, > > - RFC 6724 defines a knob for switching automatic row addition. > > - addr-select-opt defines a knob for switching whether accepting > automatic > > row addition flag delivered or not. > > > > and, if the second knob is switched to "accept", then the first knob is > > overridden by a delivered flag. > > So you're saying that the local knob can be overridden by the bit in > the message? That begs the question: why would one send a message with > the "delivered flag" set to "don't accept", meaning "don't accept this > update"? > How is that different than omitting this "don't accept" information from > the > message in the first place? > No, these *two* knobs are *local*. So, "don't accept" cannot be delivered over network. I failed to mention about it. Sorry for confusion. This misunderstanding lead to the following further confusions. Sorry about that. Regards, > > > This is common case in moderen user OS settings, such that the DNS server > > configuration can be > > switched to automatic(delivered from network), or to locally configured > to > > some value. > > But why would the network set an option indicating that the recipient > should > not use this configuration"? If the recipient has a knob indicating that > local > policy cannot be updated then the bit has no effect and if the recipient > has a > knob indicating that the policy can be updated then setting the the bit in > the > message should be meaningless. > > >> > >> > it does not affect the policy entries that is contained in the DHCP > >> > option. > >> > the A-flag only affects the RFC6724 behaviour of adding entries based > >> on > >> > address configuration on the node. > >> > >> Again, according to the draft a message can be received by a client > >> implementation that provides policy update options to its policy table > >> with semantics of "you SHOULD NOT use these!" So what is the point > >> of sending that message? Why not just refrain from sending the message > >> if that's what the message is? > >> > >> Would you ever tell someone, "disregard what I am about to tell you"? > >> I > >> can't see why. And that's what the semantics of this message seem to be. > >> > > > > As I mentioned in the previous e-mail, that I sent 10 June, > > when this A flag is turned on, the DHCP option should not carry policy > > table, > > and a receiver should ignore it, which I have to add some text in the > rev. > > But why would a server send an address selection option that said, "don't > use this"? Once again, it makes no sense to have these semantics. > > If you notice, this question seems to be repeated over and over yet I > have > not yet received an answer why or an statement that I don't understand > the semantics of the message. So what is it? Do I not understand (in which > you should explain exactly why) or is this message meaningless (in which > case why is it part of your draft)? > > regards, > > Dan. > > > --047d7b6d7e3269479d04def0a586 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


2013/6/12 Dan Harkins <dharkins@lounge.org>
=

=A0 Hi,

On Tue, June 11, 2013 11:55 pm, Arifumi Matsumoto wrote:
> Hi,
>
> 2013/6/12 Dan Harkins <dhark= ins@lounge.org>
>
>>
>> =A0 Hi Ole,
>>
>> On Tue, June 11, 2013 2:24 am, Ole Troan wrote:
>> > Dan,
>> >
>> > let me chime in as the document shepherd.
>> > (thank you very much for the thorough comments by the way). >> >
>> >> =A0For instance, while I think I understand the policy ov= erride of RFC
>> >> 6724, having the Automatic Row Additions Flag be part of = the address
>> >> selection options seems problematic. If it is set to zero= , then what
>> are
>> >> the semantics of such a message? "Here's an addr= ess selection option
>> >> but don't you dare use it!"? What is the point? = Me, as a node, can
>> have
>> >> this as part of my policy state which would allow me to i= gnore such
>> >> an update but to have the bit be part of the option to up= date does
>> >> not seem to make much sense. The semantics of the message= needs
>> >> to be explained much more clearly, or the bit needs to be= removed
>> >> from the message.
>> >
>> > my reading of the meaning of the A flag is a little different= . (I have
>> > cc'ed the authors of rfc6724 for confirmation.)
>> >
>> > an implementation of RFC6724 may automatically add entries in= the
>> policy
>> > table based on addresses configured on the node.
>> > e.g. the node has an interface with a ULA address.
>> >
>> > RFC6724 also says:
>> > =A0 =A0An implementation SHOULD provide a means (the Automati= c Row
>> Additions
>> > flag) for an administrator to disable
>> > =A0 =A0automatic row additions.
>>
>> =A0 That makes perfect sense. A client implementation SHOULD provi= de a
>> means to disable automatic row additions. So it has some knob that= can
>> be turned on or off locally that would allow for update of its pol= icy
>> table
>> by receiving policy options (enable) or forbid received policy opt= ions
>> from
>> updating the policy table (disable).
>>
>> > the A-flag in draft-ietf-6man-addr-select-opt provides the me= ans.
>>
>> =A0 So this is where I'm confused. The sender of the policy op= tion should
>> not have the ability to control the knob that an implementation ad= ded
>> locally to satisfy RFC 6724. If a client implementation sets its k= nob to
>> "disable" then it forbids policy option updates to its p= olicy table. It
>> shouldn't inspect the received option update to decide whether= it
>> should override the setting of its local knob.
>>
>> =A0 This seems like a security issue to me. There's a reason w= hy an
>> implementation would choose to disable updates of its policy table=
>> and allowing the sender of policy updates to override that seems >> wrong.
>>
>
> In my understanding,
> - RFC 6724 defines a knob for switching automatic row addition.
> - addr-select-opt defines a knob for switching whether accepting autom= atic
> row addition flag delivered or not.
>
> and, if the second knob is switched to "accept", then the fi= rst knob is
> overridden by a delivered flag.

=A0 So you're saying that the local knob can be overridden = by the bit in
the message? That begs the question: why would one send a message with
the "delivered flag" set to "don't accept", meaning= "don't accept this
update"?
How is that different than omitting this "don't accept" infor= mation from the
message in the first place?

No, t= hese *two* knobs are *local*.
So, "don't accept&qu= ot; cannot be delivered over network.
I failed to mention a= bout it. Sorry for confusion.

This misunderstanding lead to the following= further confusions.
Sorry about that.

=
Regards,
=A0

> This is common case in moderen user OS settings, such that the DNS ser= ver
> configuration can be
> switched to automatic(delivered from network), or to locally configure= d to
> some value.

=A0 But why would the network set an option indicating that the recip= ient
should
not use this configuration"? If the recipient has a knob indicating th= at
local
policy cannot be updated then the bit has no effect and if the recipient has a
knob indicating that the policy can be updated then setting the the bit in<= br> the
message should be meaningless.

>>
>> > it does not affect the policy entries that is contained in th= e DHCP
>> > option.
>> > the A-flag only affects the RFC6724 behaviour of adding entri= es based
>> on
>> > address configuration on the node.
>>
>> =A0 Again, according to the draft a message can be received by a c= lient
>> implementation that provides policy update options to its policy t= able
>> with semantics of "you SHOULD NOT use these!" So what is= the point
>> of sending that message? Why not just refrain from sending the mes= sage
>> if that's what the message is?
>>
>> =A0 Would you ever tell someone, "disregard what I am about t= o tell you"?
>> I
>> can't see why. And that's what the semantics of this messa= ge seem to be.
>>
>
> As I mentioned in the previous e-mail, that I sent 10 June,
> when this A flag is turned on, the DHCP option should not carry policy=
> table,
> and a receiver should ignore it, which I have to add some text in the = rev.

=A0 But why would a server send an address selection option that said= , "don't
use this"? Once again, it makes no sense to have these semantics.

=A0 If you notice, this question seems to be repeated over and over yet I h= ave
not yet received an answer why or an statement that I don't understand<= br> the semantics of the message. So what is it? Do I not understand (in which<= br> you should explain exactly why) or is this message meaningless (in which case why is it part of your draft)?

=A0 regards,

=A0 Dan.



--047d7b6d7e3269479d04def0a586-- From jari.arkko@piuha.net Wed Jun 12 02:31:04 2013 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 436E821F9A3F; Wed, 12 Jun 2013 02:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-b-XHpBAfZR; Wed, 12 Jun 2013 02:30:59 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id CE87921F9A6F; Wed, 12 Jun 2013 02:30:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 273412CC60; Wed, 12 Jun 2013 12:30:58 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uavm5b2uptA3; Wed, 12 Jun 2013 12:30:56 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D111F2CC3C; Wed, 12 Jun 2013 12:30:56 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jari Arkko In-Reply-To: Date: Wed, 12 Jun 2013 12:30:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <437CC7FC-727A-428C-96F3-B8F887536AFA@piuha.net> References: To: "Waltermire, David A." X-Mailer: Apple Mail (2.1503) Cc: "draft-housley-rfc2050bis-01.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-housley-rfc2050bis-01 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, 12 Jun 2013 09:31:04 -0000 Dave: Thanks for the review! Jari On Jun 11, 2013, at 9:54 PM, "Waltermire, David A." = wrote: > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. > =20 > This draft, a proposed update to RFC 2050, documents current policies = and processes used in the Internet Numbers Registry System for the = assignment of the Internet Protocol (IP) address space and autonomous = system (AS) numbers. It does not propose any changes to the Internet = Numbers Registry System. > =20 > After reviewing this informational document I do not have any = security-related concerns. > =20 > Sincerely, > Dave Waltermire > =20 From n@arifumi.net Wed Jun 12 02:56:02 2013 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 D740E21F9B99 for ; Wed, 12 Jun 2013 02:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtdbyP6eF+am for ; Wed, 12 Jun 2013 02:56:02 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id A74DD21F9BB9 for ; Wed, 12 Jun 2013 02:56:00 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so3539903pdi.41 for ; Wed, 12 Jun 2013 02:56:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=BaKHGQV8C+grSTKKj3+/wM01mix7qgdrXT0c20K+bUU=; b=L5V67m16JNloTjvH80PHlnKBOmc28fzfm8DeNXkPO+Y1O/HoDraVG0ATTG7auNEBT1 Xkc2rZ7uBO4lKdxuHCCwYCAlpvlZPD4P+zmiz7yg/J99AutptmK6F3nEjHeso+ToRrMp kWkC5jQ3h4l33qcVfRnEwaQPFr8rh1AWRkNrDfwFOE3yJko6dVHIT2u+/iNN5QQ2n4QM UcOyF/Zol28k7Xg2ghfib3fPmVO1X/Yk0hVzcMIeiv01txawpY6fyDErg8g7aAEaGhMN SPG+uWs95gVpM+bLyJZcBmQiH/ISs68jhTELtOh5tq1j1lFl5ewXE6fDrDtB3Ai3tKnb SP8Q== MIME-Version: 1.0 X-Received: by 10.66.160.101 with SMTP id xj5mr23076434pab.5.1371030960255; Wed, 12 Jun 2013 02:56:00 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.194.198 with HTTP; Wed, 12 Jun 2013 02:56:00 -0700 (PDT) X-Originating-IP: [2001:df0:45:20::61] In-Reply-To: References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> Date: Wed, 12 Jun 2013 18:56:00 +0900 X-Google-Sender-Auth: 7V5X3qlJLBS7BK67mYr7ydsY4Yo Message-ID: From: Arifumi Matsumoto To: Dan Harkins Content-Type: multipart/alternative; boundary=047d7b6dccf85cbb0e04def2058a X-Gm-Message-State: ALoCoQmrqAJaH2FumK/0tYHqw+zMMYkkOHmVLA2QWBB8Kkrg9hPYNTy9AqY4BW/T4kmXf5AKRjgW Cc: secdir@ietf.org, "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , draft-ietf-6man-rfc3484bis@tools.ietf.org, Ole Troan , iesg@ietf.org, Arifumi Matsumoto Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 12 Jun 2013 09:56:03 -0000 --047d7b6dccf85cbb0e04def2058a Content-Type: text/plain; charset=ISO-8859-1 Dan, to summarize my statement, a host's behavior will look like: i) a host is configured to accept A-flag and policy table from network a) A-flag in DHCP option is 0 (disable automatic row addition) 1) DHCP option includes policy table host should disable automatic row addition, and use delivered policy table. 2) DHCP option does not include policy table host should disable automatic row addition. no change on host's policy table. b) A-flag in DHCP option is 1 (no effect on host's A-flag) 1) DHCP option includes policy table host should disable automatic row addition, and use delivered policy table. 2) DHCP option does not include policy table host does nothing. ii) a host is configured not to accept A-flag nor policy table from network host does nothing. Hope this helps. 2013/6/12 Dan Harkins > > Hi, > > On Tue, June 11, 2013 11:55 pm, Arifumi Matsumoto wrote: > > Hi, > > > > 2013/6/12 Dan Harkins > > > >> > >> Hi Ole, > >> > >> On Tue, June 11, 2013 2:24 am, Ole Troan wrote: > >> > Dan, > >> > > >> > let me chime in as the document shepherd. > >> > (thank you very much for the thorough comments by the way). > >> > > >> >> For instance, while I think I understand the policy override of RFC > >> >> 6724, having the Automatic Row Additions Flag be part of the address > >> >> selection options seems problematic. If it is set to zero, then what > >> are > >> >> the semantics of such a message? "Here's an address selection option > >> >> but don't you dare use it!"? What is the point? Me, as a node, can > >> have > >> >> this as part of my policy state which would allow me to ignore such > >> >> an update but to have the bit be part of the option to update does > >> >> not seem to make much sense. The semantics of the message needs > >> >> to be explained much more clearly, or the bit needs to be removed > >> >> from the message. > >> > > >> > my reading of the meaning of the A flag is a little different. (I have > >> > cc'ed the authors of rfc6724 for confirmation.) > >> > > >> > an implementation of RFC6724 may automatically add entries in the > >> policy > >> > table based on addresses configured on the node. > >> > e.g. the node has an interface with a ULA address. > >> > > >> > RFC6724 also says: > >> > An implementation SHOULD provide a means (the Automatic Row > >> Additions > >> > flag) for an administrator to disable > >> > automatic row additions. > >> > >> That makes perfect sense. A client implementation SHOULD provide a > >> means to disable automatic row additions. So it has some knob that can > >> be turned on or off locally that would allow for update of its policy > >> table > >> by receiving policy options (enable) or forbid received policy options > >> from > >> updating the policy table (disable). > >> > >> > the A-flag in draft-ietf-6man-addr-select-opt provides the means. > >> > >> So this is where I'm confused. The sender of the policy option should > >> not have the ability to control the knob that an implementation added > >> locally to satisfy RFC 6724. If a client implementation sets its knob to > >> "disable" then it forbids policy option updates to its policy table. It > >> shouldn't inspect the received option update to decide whether it > >> should override the setting of its local knob. > >> > >> This seems like a security issue to me. There's a reason why an > >> implementation would choose to disable updates of its policy table > >> and allowing the sender of policy updates to override that seems > >> wrong. > >> > > > > In my understanding, > > - RFC 6724 defines a knob for switching automatic row addition. > > - addr-select-opt defines a knob for switching whether accepting > automatic > > row addition flag delivered or not. > > > > and, if the second knob is switched to "accept", then the first knob is > > overridden by a delivered flag. > > So you're saying that the local knob can be overridden by the bit in > the message? That begs the question: why would one send a message with > the "delivered flag" set to "don't accept", meaning "don't accept this > update"? > How is that different than omitting this "don't accept" information from > the > message in the first place? > > > This is common case in moderen user OS settings, such that the DNS server > > configuration can be > > switched to automatic(delivered from network), or to locally configured > to > > some value. > > But why would the network set an option indicating that the recipient > should > not use this configuration"? If the recipient has a knob indicating that > local > policy cannot be updated then the bit has no effect and if the recipient > has a > knob indicating that the policy can be updated then setting the the bit in > the > message should be meaningless. > > >> > >> > it does not affect the policy entries that is contained in the DHCP > >> > option. > >> > the A-flag only affects the RFC6724 behaviour of adding entries based > >> on > >> > address configuration on the node. > >> > >> Again, according to the draft a message can be received by a client > >> implementation that provides policy update options to its policy table > >> with semantics of "you SHOULD NOT use these!" So what is the point > >> of sending that message? Why not just refrain from sending the message > >> if that's what the message is? > >> > >> Would you ever tell someone, "disregard what I am about to tell you"? > >> I > >> can't see why. And that's what the semantics of this message seem to be. > >> > > > > As I mentioned in the previous e-mail, that I sent 10 June, > > when this A flag is turned on, the DHCP option should not carry policy > > table, > > and a receiver should ignore it, which I have to add some text in the > rev. > > But why would a server send an address selection option that said, "don't > use this"? Once again, it makes no sense to have these semantics. > > If you notice, this question seems to be repeated over and over yet I > have > not yet received an answer why or an statement that I don't understand > the semantics of the message. So what is it? Do I not understand (in which > you should explain exactly why) or is this message meaningless (in which > case why is it part of your draft)? > > regards, > > Dan. > > > --047d7b6dccf85cbb0e04def2058a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,

to summarize my statement, a host&= #39;s behavior will look like:

i) a host is configured to accept A= -flag and policy table from network
=A0 a) A-flag in= DHCP option is 0 (disable automatic row addition)
=A0 =A0 1) DHCP option includes pol= icy table
=A0 =A0 =A0 =A0h= ost should disable automatic row addition, and use delivered policy table.<= /div>
=A0 = =A0 2) DHCP option does not include policy table
=A0 =A0 =A0 =A0host should disable automatic row addition. no cha= nge on host's policy table.

=
=A0 b) A-flag in= DHCP option is 1 (no effect on host's A-flag)
=A0 =A0 1) = DHCP option includes policy table
=A0 =A0 =A0 =A0 host should dis= able=A0automatic row addition, and use delivered policy table.
= =A0 =A0 2) DHCP option does not include policy table
=A0 =A0 =A0 =A0 host does nothing.

ii) a= host is configured not to accept A-flag nor policy table from network
=A0 =A0 =A0 =A0 host does nothing.

Hope this helps.

2013/6/12 Dan Harkins <dharkins@lounge.org>

=A0 Hi,

On Tue, June 11, 2013 11:55 pm, Arifumi Matsumoto wrote:
> Hi,
>
> 2013/6/12 Dan Harkins <dhark= ins@lounge.org>
>
>>
>> =A0 Hi Ole,
>>
>> On Tue, June 11, 2013 2:24 am, Ole Troan wrote:
>> > Dan,
>> >
>> > let me chime in as the document shepherd.
>> > (thank you very much for the thorough comments by the way). >> >
>> >> =A0For instance, while I think I understand the policy ov= erride of RFC
>> >> 6724, having the Automatic Row Additions Flag be part of = the address
>> >> selection options seems problematic. If it is set to zero= , then what
>> are
>> >> the semantics of such a message? "Here's an addr= ess selection option
>> >> but don't you dare use it!"? What is the point? = Me, as a node, can
>> have
>> >> this as part of my policy state which would allow me to i= gnore such
>> >> an update but to have the bit be part of the option to up= date does
>> >> not seem to make much sense. The semantics of the message= needs
>> >> to be explained much more clearly, or the bit needs to be= removed
>> >> from the message.
>> >
>> > my reading of the meaning of the A flag is a little different= . (I have
>> > cc'ed the authors of rfc6724 for confirmation.)
>> >
>> > an implementation of RFC6724 may automatically add entries in= the
>> policy
>> > table based on addresses configured on the node.
>> > e.g. the node has an interface with a ULA address.
>> >
>> > RFC6724 also says:
>> > =A0 =A0An implementation SHOULD provide a means (the Automati= c Row
>> Additions
>> > flag) for an administrator to disable
>> > =A0 =A0automatic row additions.
>>
>> =A0 That makes perfect sense. A client implementation SHOULD provi= de a
>> means to disable automatic row additions. So it has some knob that= can
>> be turned on or off locally that would allow for update of its pol= icy
>> table
>> by receiving policy options (enable) or forbid received policy opt= ions
>> from
>> updating the policy table (disable).
>>
>> > the A-flag in draft-ietf-6man-addr-select-opt provides the me= ans.
>>
>> =A0 So this is where I'm confused. The sender of the policy op= tion should
>> not have the ability to control the knob that an implementation ad= ded
>> locally to satisfy RFC 6724. If a client implementation sets its k= nob to
>> "disable" then it forbids policy option updates to its p= olicy table. It
>> shouldn't inspect the received option update to decide whether= it
>> should override the setting of its local knob.
>>
>> =A0 This seems like a security issue to me. There's a reason w= hy an
>> implementation would choose to disable updates of its policy table=
>> and allowing the sender of policy updates to override that seems >> wrong.
>>
>
> In my understanding,
> - RFC 6724 defines a knob for switching automatic row addition.
> - addr-select-opt defines a knob for switching whether accepting autom= atic
> row addition flag delivered or not.
>
> and, if the second knob is switched to "accept", then the fi= rst knob is
> overridden by a delivered flag.

=A0 So you're saying that the local knob can be overridden = by the bit in
the message? That begs the question: why would one send a message with
the "delivered flag" set to "don't accept", meaning= "don't accept this
update"?
How is that different than omitting this "don't accept" infor= mation from the
message in the first place?

> This is common case in moderen user OS settings, such that the DNS ser= ver
> configuration can be
> switched to automatic(delivered from network), or to locally configure= d to
> some value.

=A0 But why would the network set an option indicating that the recip= ient
should
not use this configuration"? If the recipient has a knob indicating th= at
local
policy cannot be updated then the bit has no effect and if the recipient has a
knob indicating that the policy can be updated then setting the the bit in<= br> the
message should be meaningless.

>>
>> > it does not affect the policy entries that is contained in th= e DHCP
>> > option.
>> > the A-flag only affects the RFC6724 behaviour of adding entri= es based
>> on
>> > address configuration on the node.
>>
>> =A0 Again, according to the draft a message can be received by a c= lient
>> implementation that provides policy update options to its policy t= able
>> with semantics of "you SHOULD NOT use these!" So what is= the point
>> of sending that message? Why not just refrain from sending the mes= sage
>> if that's what the message is?
>>
>> =A0 Would you ever tell someone, "disregard what I am about t= o tell you"?
>> I
>> can't see why. And that's what the semantics of this messa= ge seem to be.
>>
>
> As I mentioned in the previous e-mail, that I sent 10 June,
> when this A flag is turned on, the DHCP option should not carry policy=
> table,
> and a receiver should ignore it, which I have to add some text in the = rev.

=A0 But why would a server send an address selection option that said= , "don't
use this"? Once again, it makes no sense to have these semantics.

=A0 If you notice, this question seems to be repeated over and over yet I h= ave
not yet received an answer why or an statement that I don't understand<= br> the semantics of the message. So what is it? Do I not understand (in which<= br> you should explain exactly why) or is this message meaningless (in which case why is it part of your draft)?

=A0 regards,

=A0 Dan.



--047d7b6dccf85cbb0e04def2058a-- From otroan@employees.org Wed Jun 12 03:06:51 2013 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 C650E21F9A6F; Wed, 12 Jun 2013 03:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCuzausLVR9e; Wed, 12 Jun 2013 03:06:44 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 896E421F9A63; Wed, 12 Jun 2013 03:06:40 -0700 (PDT) Received: from dhcp-10-61-98-253.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id D60EA5E85; Wed, 12 Jun 2013 03:06:36 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Ole Troan X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 12 Jun 2013 12:06:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F8FAF51-833A-4C75-9FFC-BE17ADF27994@employees.org> References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> To: Dan Harkins X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-6man-addr-select-opt.all@tools.ietf.org, draft-ietf-6man-rfc3484bis@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 12 Jun 2013 10:06:51 -0000 Dan, apologies for the delay, I discussed this directly with Arifumi, and I = hope his latest message clarifies the issue. to rephrase in my words; OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to = disable automatic row addition) and to carry policy table options. the A-flag is a hint to the host to disable automatic row addition. if OPTION_ADDRSEL contains policy table options the A-flag is redundant. (as policy table options and the A-flag are incompatible). if you are fine with this, I will ask the authors to update the draft to = make this behaviour explicit. Best regards, Ole >> let me chime in as the document shepherd. >> (thank you very much for the thorough comments by the way). >>=20 >>> For instance, while I think I understand the policy override of RFC >>> 6724, having the Automatic Row Additions Flag be part of the address >>> selection options seems problematic. If it is set to zero, then what = are >>> the semantics of such a message? "Here's an address selection option >>> but don't you dare use it!"? What is the point? Me, as a node, can = have >>> this as part of my policy state which would allow me to ignore such >>> an update but to have the bit be part of the option to update does >>> not seem to make much sense. The semantics of the message needs >>> to be explained much more clearly, or the bit needs to be removed >>> from the message. >>=20 >> my reading of the meaning of the A flag is a little different. (I = have >> cc'ed the authors of rfc6724 for confirmation.) >>=20 >> an implementation of RFC6724 may automatically add entries in the = policy >> table based on addresses configured on the node. >> e.g. the node has an interface with a ULA address. >>=20 >> RFC6724 also says: >> An implementation SHOULD provide a means (the Automatic Row = Additions >> flag) for an administrator to disable >> automatic row additions. >=20 > That makes perfect sense. A client implementation SHOULD provide a > means to disable automatic row additions. So it has some knob that can > be turned on or off locally that would allow for update of its policy = table > by receiving policy options (enable) or forbid received policy options = from > updating the policy table (disable). >=20 >> the A-flag in draft-ietf-6man-addr-select-opt provides the means. >=20 > So this is where I'm confused. The sender of the policy option should > not have the ability to control the knob that an implementation added > locally to satisfy RFC 6724. If a client implementation sets its knob = to > "disable" then it forbids policy option updates to its policy table. = It > shouldn't inspect the received option update to decide whether it > should override the setting of its local knob. >=20 > This seems like a security issue to me. There's a reason why an > implementation would choose to disable updates of its policy table > and allowing the sender of policy updates to override that seems > wrong. >=20 >> it does not affect the policy entries that is contained in the DHCP >> option. >> the A-flag only affects the RFC6724 behaviour of adding entries based = on >> address configuration on the node. >=20 > Again, according to the draft a message can be received by a client > implementation that provides policy update options to its policy table > with semantics of "you SHOULD NOT use these!" So what is the point > of sending that message? Why not just refrain from sending the message > if that's what the message is? >=20 > Would you ever tell someone, "disregard what I am about to tell you"? = I > can't see why. And that's what the semantics of this message seem to = be. From dharkins@lounge.org Wed Jun 12 20:17:37 2013 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 3103321F9921; Wed, 12 Jun 2013 20:17:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcJQorLJlNwt; Wed, 12 Jun 2013 20:17:31 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id AD18A21F9814; Wed, 12 Jun 2013 20:17:31 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E203E1022400A; Wed, 12 Jun 2013 20:17:30 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 12 Jun 2013 20:17:31 -0700 (PDT) Message-ID: <5ffd0e5973e67c773b8ce3d345010c8f.squirrel@www.trepanning.net> In-Reply-To: <5F8FAF51-833A-4C75-9FFC-BE17ADF27994@employees.org> References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> <5F8FAF51-833A-4C75-9FFC-BE17ADF27994@employees.org> Date: Wed, 12 Jun 2013 20:17:31 -0700 (PDT) From: "Dan Harkins" To: "Ole Troan" 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 Cc: draft-ietf-6man-addr-select-opt.all@tools.ietf.org, secdir@ietf.org, draft-ietf-6man-rfc3484bis@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 13 Jun 2013 03:17:37 -0000 Hi Ole, Yes, I am fine with Arifumi's clarification. Thanks. regards, Dan. On Wed, June 12, 2013 3:06 am, Ole Troan wrote: > Dan, > > apologies for the delay, I discussed this directly with Arifumi, and I > hope his latest message clarifies the issue. > > to rephrase in my words; > OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to disable > automatic row addition) > and to carry policy table options. > the A-flag is a hint to the host to disable automatic row addition. > if OPTION_ADDRSEL contains policy table options the A-flag is redundant. > (as policy table options and the A-flag are incompatible). > > if you are fine with this, I will ask the authors to update the draft to > make this behaviour explicit. > > Best regards, > Ole > >>> let me chime in as the document shepherd. >>> (thank you very much for the thorough comments by the way). >>> >>>> For instance, while I think I understand the policy override of RFC >>>> 6724, having the Automatic Row Additions Flag be part of the address >>>> selection options seems problematic. If it is set to zero, then what >>>> are >>>> the semantics of such a message? "Here's an address selection option >>>> but don't you dare use it!"? What is the point? Me, as a node, can >>>> have >>>> this as part of my policy state which would allow me to ignore such >>>> an update but to have the bit be part of the option to update does >>>> not seem to make much sense. The semantics of the message needs >>>> to be explained much more clearly, or the bit needs to be removed >>>> from the message. >>> >>> my reading of the meaning of the A flag is a little different. (I have >>> cc'ed the authors of rfc6724 for confirmation.) >>> >>> an implementation of RFC6724 may automatically add entries in the >>> policy >>> table based on addresses configured on the node. >>> e.g. the node has an interface with a ULA address. >>> >>> RFC6724 also says: >>> An implementation SHOULD provide a means (the Automatic Row Additions >>> flag) for an administrator to disable >>> automatic row additions. >> >> That makes perfect sense. A client implementation SHOULD provide a >> means to disable automatic row additions. So it has some knob that can >> be turned on or off locally that would allow for update of its policy >> table >> by receiving policy options (enable) or forbid received policy options >> from >> updating the policy table (disable). >> >>> the A-flag in draft-ietf-6man-addr-select-opt provides the means. >> >> So this is where I'm confused. The sender of the policy option should >> not have the ability to control the knob that an implementation added >> locally to satisfy RFC 6724. If a client implementation sets its knob to >> "disable" then it forbids policy option updates to its policy table. It >> shouldn't inspect the received option update to decide whether it >> should override the setting of its local knob. >> >> This seems like a security issue to me. There's a reason why an >> implementation would choose to disable updates of its policy table >> and allowing the sender of policy updates to override that seems >> wrong. >> >>> it does not affect the policy entries that is contained in the DHCP >>> option. >>> the A-flag only affects the RFC6724 behaviour of adding entries based >>> on >>> address configuration on the node. >> >> Again, according to the draft a message can be received by a client >> implementation that provides policy update options to its policy table >> with semantics of "you SHOULD NOT use these!" So what is the point >> of sending that message? Why not just refrain from sending the message >> if that's what the message is? >> >> Would you ever tell someone, "disregard what I am about to tell you"? I >> can't see why. And that's what the semantics of this message seem to be. > > > > From otroan@employees.org Thu Jun 13 01:45:45 2013 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 5A11E21F9A97; Thu, 13 Jun 2013 01:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc7h8T-Ifitk; Thu, 13 Jun 2013 01:45:39 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9516821F8B21; Thu, 13 Jun 2013 01:45:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGiGuVGQ/khR/2dsb2JhbABbgwm/Wn8WdIIjAQEEAXkFCwUGDjhXBiSHdwa7Jo9DB4J/YQOpAoMROg X-IronPort-AV: E=Sophos;i="4.87,857,1363132800"; d="scan'208";a="14669488" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 13 Jun 2013 08:45:35 +0000 Received: from dhcp-10-61-110-245.cisco.com (dhcp-10-61-110-245.cisco.com [10.61.110.245]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5D8jVYD009340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Jun 2013 08:45:32 GMT Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Ole Troan X-Priority: 3 (Normal) In-Reply-To: <5ffd0e5973e67c773b8ce3d345010c8f.squirrel@www.trepanning.net> Date: Thu, 13 Jun 2013 10:45:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2B1856F1-537D-4268-A104-BDC180A4EC54@employees.org> References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> <5F8FAF51-833A-4C75-9FFC-BE17ADF27994@employees.org> <5ffd0e5973e67c773b8ce3d345010c8f.squirrel@www.trepanning.net> To: "Dan Harkins" X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-6man-addr-select-opt.all@tools.ietf.org, draft-ietf-6man-rfc3484bis@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 13 Jun 2013 08:45:45 -0000 Dan, > Yes, I am fine with Arifumi's clarification. Thanks. splendid, thanks for the help! Best regards, Ole >> Dan, >> >> apologies for the delay, I discussed this directly with Arifumi, and I >> hope his latest message clarifies the issue. >> >> to rephrase in my words; >> OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to disable >> automatic row addition) >> and to carry policy table options. >> the A-flag is a hint to the host to disable automatic row addition. >> if OPTION_ADDRSEL contains policy table options the A-flag is redundant. >> (as policy table options and the A-flag are incompatible). >> >> if you are fine with this, I will ask the authors to update the draft to >> make this behaviour explicit. >> >> Best regards, >> Ole >> >>>> let me chime in as the document shepherd. >>>> (thank you very much for the thorough comments by the way). >>>> >>>>> For instance, while I think I understand the policy override of RFC >>>>> 6724, having the Automatic Row Additions Flag be part of the address >>>>> selection options seems problematic. If it is set to zero, then what >>>>> are >>>>> the semantics of such a message? "Here's an address selection option >>>>> but don't you dare use it!"? What is the point? Me, as a node, can >>>>> have >>>>> this as part of my policy state which would allow me to ignore such >>>>> an update but to have the bit be part of the option to update does >>>>> not seem to make much sense. The semantics of the message needs >>>>> to be explained much more clearly, or the bit needs to be removed >>>>> from the message. >>>> >>>> my reading of the meaning of the A flag is a little different. (I have >>>> cc'ed the authors of rfc6724 for confirmation.) >>>> >>>> an implementation of RFC6724 may automatically add entries in the >>>> policy >>>> table based on addresses configured on the node. >>>> e.g. the node has an interface with a ULA address. >>>> >>>> RFC6724 also says: >>>> An implementation SHOULD provide a means (the Automatic Row Additions >>>> flag) for an administrator to disable >>>> automatic row additions. >>> >>> That makes perfect sense. A client implementation SHOULD provide a >>> means to disable automatic row additions. So it has some knob that can >>> be turned on or off locally that would allow for update of its policy >>> table >>> by receiving policy options (enable) or forbid received policy options >>> from >>> updating the policy table (disable). >>> >>>> the A-flag in draft-ietf-6man-addr-select-opt provides the means. >>> >>> So this is where I'm confused. The sender of the policy option should >>> not have the ability to control the knob that an implementation added >>> locally to satisfy RFC 6724. If a client implementation sets its knob to >>> "disable" then it forbids policy option updates to its policy table. It >>> shouldn't inspect the received option update to decide whether it >>> should override the setting of its local knob. >>> >>> This seems like a security issue to me. There's a reason why an >>> implementation would choose to disable updates of its policy table >>> and allowing the sender of policy updates to override that seems >>> wrong. >>> >>>> it does not affect the policy entries that is contained in the DHCP >>>> option. >>>> the A-flag only affects the RFC6724 behaviour of adding entries based >>>> on >>>> address configuration on the node. >>> >>> Again, according to the draft a message can be received by a client >>> implementation that provides policy update options to its policy table >>> with semantics of "you SHOULD NOT use these!" So what is the point >>> of sending that message? Why not just refrain from sending the message >>> if that's what the message is? >>> >>> Would you ever tell someone, "disregard what I am about to tell you"? I >>> can't see why. And that's what the semantics of this message seem to be. >> >> >> >> > From kivinen@iki.fi Thu Jun 13 03:59:21 2013 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 A3B3521F9A50 for ; Thu, 13 Jun 2013 03:59:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3I8KgJxuK7c for ; Thu, 13 Jun 2013 03:59:21 -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 723FF21F9A4B for ; Thu, 13 Jun 2013 03:59:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r5DAxFMo024829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Jun 2013 13:59:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r5DAxF3w022250; Thu, 13 Jun 2013 13:59:15 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20921.42499.52563.753728@fireball.kivinen.iki.fi> Date: Thu, 13 Jun 2013 13:59:15 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 8 min X-Total-Time: 12 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, 13 Jun 2013 10:59:21 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tobias Gondrom is next in the rotation. For telechat 2013-06-13 Reviewer LC end Draft Alan DeKok T 2013-05-06 draft-ietf-geopriv-held-measurements-07 David Harrington T 2013-05-09 draft-ietf-6man-impatient-nud-06 For telechat 2013-06-27 Derek Atkins T 2013-06-24 draft-ietf-pkix-est-07 Hilarie Orman T 2013-06-25 draft-thornburgh-adobe-rtmfp-07 Joe Salowey T 2013-06-06 draft-ietf-l3vpn-virtual-hub-06 Yaron Sheffer T 2013-06-07 draft-ietf-pce-gmpls-aps-req-08 Carl Wallace T 2013-06-21 draft-ietf-ipsecme-ad-vpn-problem-07 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland - draft-ietf-httpbis-p5-range-22 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Donald Eastlake 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Shawn Emery 2013-05-31 draft-ietf-xrblock-rtcp-xr-jb-11 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-10 Julien Laganier - draft-ietf-avtcore-rtp-security-options-03 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Kathleen Moriarty 2013-06-03 draft-ietf-xrblock-rtcp-xr-discard-14 Sandy Murphy 2013-06-17 draft-jabley-dnsext-eui48-eui64-rrtypes-05 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-09 Ondrej Sury 2013-06-17 draft-ietf-abfab-eapapplicability-03 Tina TSOU 2013-06-20 draft-ietf-alto-server-discovery-08 David Waltermire 2013-06-19 draft-ietf-nvo3-overlay-problem-statement-03 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-10 Sam Weiler 2013-06-19 draft-ietf-ospf-manet-single-hop-mdr-03 Brian Weis 2013-06-18 draft-ietf-payload-vp8-08 Klaas Wierenga 2013-06-20 draft-ietf-rmt-sec-discussion-08 Tom Yu 2013-06-19 draft-ietf-rtgwg-cl-requirement-10 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 -- kivinen@iki.fi From new-work-bounces@ietf.org Fri Jun 14 08:42:03 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7E321F9CE2; Fri, 14 Jun 2013 08:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1371224523; bh=J9nKc6xdcPZqN9PeLtAOnFvQkm69ih5V5ArrSulP9uw=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=PRXWwfDZ16YVHjlynKQGUg6fZou5QXjf2GedutSC25wR9SsF2MciJdo5jgGmGqzaq Vz10JyiwxAD6U4g/eu6GcXUFP27gjgTFKYHBu6Lpy5E+W3B1AJwwUJ6Sh3dsGI6IL4 Gq4YIMT7D0bFQubtmIAiIciby4C6WAAUSDE8/0Wo= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2758021F9CEC; Fri, 14 Jun 2013 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OZorO7HWWYG; Fri, 14 Jun 2013 08:42:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2625021F9CB3; Fri, 14 Jun 2013 08:42:01 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130614154201.23735.7313.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2013 08:42:01 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 14 Jun 2013 09:04:26 -0700 Subject: [secdir] [new-work] WG Review: Large-Scale Measurement of Broadband Performance (lmap) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 15:42:03 -0000 A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-06-24. Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Benoit Claise Mailing list Address: lmap@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/lmap Archive: http://www.ietf.org/mail-archive/web/lmap Charter: The Large-Scale Measurement of Broadband Performance (LMAP) working group standardizes the LMAP measurement system for performance measurements of broadband access devices such as home and enterprise edge routers, personal computers, mobile devices, set top box, whether wired or wireless. Measuring portions of the Internet on a large scale is essential for accurate characterizations of performance over time and geography, for network diagnostic investigations by providers and their users, and for collecting information to support public policy development. The goal is to have the measurements (made using the same metrics and mechanisms) for a large number of points on the Internet, and to have the results collected and stored in the same form. The LMAP working group is chartered to specify an information model, the associated data models, and select/extend one or more protocols for the secure communication: 1. A Control Protocol, from a Controller to instruct Measurement Agents what performance metrics to measure, when to measure them, how/when to report the measurement results to a Collector, 2. A Report Protocol, for a Measurement Agent to report the results to the Collector. The data models should be extensible for new and additional measurements. LMAP will consider re-use of existing data models languages. A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator). However, the components of an LMAP measurement system can be deployed in administrative domains that are not owned by the measuring organization. Thus, the system of functions deployed by a single organization constitutes a single LMAP domain which may span ownership or other administrative boundaries. The LMAP architecture will allow for measurements that utilize either IPv4 or IPv6, or possibly both. Devices containing Measurement Agents may have several interfaces using different link technologies. Multiple address families and interfaces must be considered in the Control and Report protocols. It is assumed that different organization's LMAP measurement domains can overlap, and that active measurement packets appear along with normal user traffic when crossing another organization's network. There is no requirement to specify a mechanism for coordination between the LMAP measurements in overlapping domains (for instance a home network with MAs on the home gateway, set top box and laptop). In principle, there are no restrictions on the type of device in which the MA function resides. Both active and passive measurements are in scope, although there may be differences in their applicability to specific use cases, or in the security measures needed according to the threats specific to each measurement category. LMAP will not standardize performance metrics. The LMAP WG will consider privacy as a core requirement and will ensure that by default measurement and collection mechanisms and protocols standardized operate in a privacy-sensitive manner, for example, ensuring that measurements are not personally identifying except where permission for such has been granted by identified subjects. Note that this does not mean that all uses of LMAP need to turn on all privacy features but it does mean that privacy features do need to be at least well-defined. Standardizing control of end users Measurement Agents is out of scope. However, end users can obtain an MA to run measurement tasks if desired and report their results to whomever they want, most likely the supplier of the MA. This provides for user-initiated on-demand measurement, which is an important component of the ISP use case. Inter-organization communication of results is out of scope of the LMAP charter. The management protocol to bootstrap the MAs in measurement devices is out of scope of the LMAP charter. Service parameters, such as product category, can be useful to decide which measurements to run and how to interpret the results. These parameters are already gathered and stored by existing operations systems. Discovering the service parameters on the MAs or sharing the service parameters between MAs are out of the scope. However, if the service parameters are available to the MAs, they could be reported with the measurement results in the Report Protocol. Deciding the set of measurements to run is a business decision and is out of scope of the LMAP charter. Protection against the intentional or malicious insertion of inaccuracies into the overall system or measurement process (sometimes known as "gaming the system") is outside the scope of work. The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the information model, and with other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics. The LMAP WG will produce the following work items: 1. The LMAP Framework - provides common terminology, basic architecture elements, and justifies the simplifying constraints 2. The LMAP Use Cases - provides the motivating use cases as a basis for the work 3. Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes * The metric(s) that can be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed) * The schedule: when the measurement should be run and how the results should be reported (when and to which Collector) * The report: the metric(s) measured and when, the actual result, and supporting metadata such as location. Result reports may be organized in batches or may be reported immediately, such as for an on-demand measurement. 4. The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This may be a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or NETCONF). 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). Milestones: Sep 2013 Initial WG I-D for the LMAP Framework including terminology Sep 2013 Initial WG I-D for the LMAP Use cases Dec 2013 Submit the LMAP Framework I-D to the IESG for consideration as Informational RFC Dec 2013 Submit I-D on the LMAP Use cases to the IESG for consideration as Informational RFC Jan 2014 Initial WG I-D for LMAP Information models Apr 2014 Initial WG I-D for the Control protocol Apr 2014 Initial WG I-D for the Report protocol Apr 2014 Initial WG I-D for a Data model for LMAP control information Apr 2014 Initial WG I-D for a Data model for LMAP report information Jul 2014 Submit the LMAP Information models I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Control protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Report protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Data model for LMAP control I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Data model for LMAP report I-D to the IESG for consideration as Standards track RFC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Jun 14 14:56:16 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2540521E805E; Fri, 14 Jun 2013 14:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1371246976; bh=ChGRxMQR9I3IGaTIDDwqAZ1nlwQzFP0cKWBn4eFYOWM=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=sx1Gyfa8O6K6yUAD2bQPlHIPXUp4fIjRuSnYfRHv0XP45g0JZtaXpbk/FdtL3pL0X JvORSwlMAk6r/4DNVTe72XxCKkANiKeisu2RRglwKGgvDxxhpTUo4WX52kKDQs/4tH 1Zony4mxV+JUiaiwLr472BPOqkDpA82MaWeuW+LQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0721E805E for ; Fri, 14 Jun 2013 14:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0O57R4qQNWW for ; Fri, 14 Jun 2013 14:56:09 -0700 (PDT) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) by ietfa.amsl.com (Postfix) with ESMTP id F278121E805A for ; Fri, 14 Jun 2013 14:55:39 -0700 (PDT) X-LoopCount0: from 10.170.28.41 X-IronPort-AV: E=Sophos;i="4.87,868,1363150800"; d="scan'208,217";a="163135239" From: To: Date: Fri, 14 Jun 2013 16:55:38 -0500 Thread-Topic: IEEE 802 New Work Under Consideration in July 2013 Thread-Index: Ac5pSeLE2KgDCknxREanbUoxLhZUvw== Message-ID: <28616F4740DDF542AA1DB7C9F5979639078A14966B@AUSX7MCPS301.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============5762394932371296793==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 14 Jun 2013 15:04:46 -0700 Subject: [secdir] [new-work] IEEE 802 New Work Under Consideration in July 2013 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 21:56:16 -0000 --===============5762394932371296793== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_28616F4740DDF542AA1DB7C9F5979639078A14966BAUSX7MCPS301A_" --_000_28616F4740DDF542AA1DB7C9F5979639078A14966BAUSX7MCPS301A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The following Project Authorization Requests (PARs) will be considered at t= he July 2013 IEEE 802 Plenary:\ * 802.1Qcc - amendment for Stream Reservation Protocol (SRP) * 802.1Qcd - amendment for Application Virtual Local Area Networks (VLAN= ) Type, Length, Value (TLV) * 802.3br - amendment for Specification and Management Parameters for In= terspersing Express Traffic * 802.15.10 - recommended practice on Layer 2 Routing The PARs can be found at http://ieee802.org/PARs.shtml along with the suppo= rting 5 criteria (i.e. the explanations of how they fit the IEEE 802 criter= ia for initiating new work) Any comments on a proposed PAR should be sent to the Working Group chair id= entified on the PAR to be received by 5:00 PM, Tuesday, July 16, 2013 (15:0= 0 UTC July 16, 2013). Regards, John D'Ambrosia IEEE 802 LMSC Recording Secretary --_000_28616F4740DDF542AA1DB7C9F5979639078A14966BAUSX7MCPS301A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

The following Project Authorization Requests (PARs) will be cons= idered at the July 2013 IEEE 802 Plenary:\

    802.1Qcc - amendment for Stream Reservat= ion Protocol (SRP) 
  • 80= 2.1Qcd - amendment for Application Virtual Local Area Networks (VLAN) Type,= Length, Value (TLV)
  • 802.3br= - amendment for Specification and Management Parameters for Interspersing = Express Traffic
  • 802.15.10 - = recommended practice on Layer 2 Routing

The PARs can be found at http://ieee802.org/PARs.shtml along with t= he supporting 5 criteria (i.e. the explanations of how they fit the IEEE 80= 2 criteria for initiating new work)

Any comments on a proposed PAR should be sent to= the Working Group chair identified on the PAR to be received by 5:00 PM, T= uesday, July 16, 2013 (15:00 UTC July 16, 2013).

Regards,

John D’Ambrosia

IEEE 802 = LMSC Recording Secretary

 

= --_000_28616F4740DDF542AA1DB7C9F5979639078A14966BAUSX7MCPS301A_-- --===============5762394932371296793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============5762394932371296793==-- From Tina.Tsou.Zouting@huawei.com Fri Jun 14 21:29:47 2013 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 0E61721F9121; Fri, 14 Jun 2013 21:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvMb77SiOLsZ; Fri, 14 Jun 2013 21:29:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDBF21F86AE; Fri, 14 Jun 2013 21:29:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASL93227; Sat, 15 Jun 2013 04:29:36 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 15 Jun 2013 05:29:21 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 15 Jun 2013 05:29:32 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.217]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Fri, 14 Jun 2013 21:29:25 -0700 From: Tina TSOU To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-alto-server-discovery@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-alto-server-discovery-08 Thread-Index: AQHOaYDqxeINscWnekecVOXJq9KhVw== Date: Sat, 15 Jun 2013 04:29:24 +0000 Message-ID: References: <9BB92CB59918E1418A06FD4E3269FABE116A4737@xmb-rcd-x06.cisco.com> In-Reply-To: <9BB92CB59918E1418A06FD4E3269FABE116A4737@xmb-rcd-x06.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [secdir] Secdir review of draft-ietf-alto-server-discovery-08 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: Sat, 15 Jun 2013 04:29:47 -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. This draft has issues that should be fixed before it moves forward. General ------- The word "suitable" appears 3-4 times in the document, but there is no defi= nition of "suitable". In fact, there does not seem to be any evaluation of = "suitability" in the procedures defined here. Either drop the word or defin= e it and take account of the definition in the procedures. Abstract --------- Well done. Says what the document is about, sets the architectural context = and limits the scope. No comment. 1. Introduction --------------- Again well done. Relates this document to other work done and in progress. = No comment other than the one on "suitable" made above. 2. ALTO Server Discovery Procedure Overview ------------------------------------------- Provides the indicated overview. One substantive issue: not consistent with= the detailed procedure given in Section 3. Please see below. You might als= o say that the procedure has to be performed for each interface, for each A= ddress Family (AF) supported on that interface. Several nits: - neccessary, neccessarily -> necessary, necessarily - "yielded" might better be "configured" or "acquired" in paragraph 2 - whishes -> wishes in paragraph 3 3. ALTO Server Discovery Procedure Specification ------------------------------------------------- Definitely you should say here that the procedure has to be performed for e= ach interface, for each Address Family (AF) supported on that interface. 3.1. Step 1: Retrieving the Domain Name 3.1.1. Step 1, Option 1: User input ------------------------------------ Begins by giving the motivation for user override, then defines an user inp= ut procedure which falls back to DHCP. Comment: That appears to contradict the summary in Section 2, which says th= at DHCP is the primary means of acquiring the domain name. If Section 2 is correct, it would seem logical to present what is now in Section 3.1.2 first, followed by the current contents of Section 3.1.1.=20 Furthermore, after the example of user override in the user input section, = perhaps say that implementations MUST allow for user input if the DHCP opti= on fails, and SHOULD allow user input to override the DHCP. On the other hand, further down it appears that the authors have assumed th= at if the user provides the domain name, it applies to all interface-AF com= binations. Is this a reasonable assumption? If so, the current order of pre= sentation is reasonable but 3.1.1 should explicitly state this assumption. 3.1.2. Step 1, Option 2: DHCP ------------------------------ Second para introduces the relevant DHCPv4 and DHCPv6 options. Third para p= rovides details with normative language. No comment. 3.2. Step 2: U-NAPTR Resolution -------------------------------- Reviews the result of the first step, gives details of the U_NAPTR lookup p= rocedure, gives an example, and discusses failure cases. Comment: the statement that an HTTPS: result is preferred is made in the ex= ample (third paragraph). That statement should be part of the normative pro= cedural description in the second paragraph. Comment: the last sentence of the final paragraph seems slightly ambiguous.= If the phrase "lookup that has failed" is expanded to "lookup of a domain = name-interface-AF combination that has failed" capture the authors' intenti= on? Editorial: the third paragraph should begin with the statement: "Here is an= example." 4. Deployment Considerations 4.1. Issues with Home Gateways ------------------------------- Notes that the home gateway could fail to pass the necessary DHCP options t= o the host because it fails to understand them. Notes further that the home= gateway could pass a local DNS name to the host in place of the name retur= ned by DHCP. In this case the procedure will fail unless the home gateway i= tself resolves the NAPTR lookup correctly. Editorial: issues -> issue in the first line of the last paragraph. 4.2. Issues with Multihoming, Mobility and Changing IP Addresses ----------------------------------------------------------------- Notes that: - manual entry could give undesirable results in the case of mobility - DHCP usage applies per interface-AF combination - Alto server(s) used should (no normative text) be that/those applicable= to the interface-AF combination selected - a change of address on an interface invalidates any prior choice of Alt= o server(s) for that interface-AF combination - a server good for one interface may not be good for another - DHCP generally not available for VPNs and mobile IP, hence manual confi= guration (of the domain of the VPN gateway or Home Agent) will be required. Comment: The first paragraph appears to assume that manual entry provides a= single domain name that applies to all interface-AF combinations. Is this = intended? (See also comment to Section 3.1.1 above.) Comment: The point about DHCP per interface-AF combination should appear ea= rlier, see comments to Section 2 and 3 above. Editorial: second paragraph, familly (line 2) and familiy (line 4) -> famil= y 5. IANA Considerations ----------------------- Registers U-NAPTR application service tag. No comment. 6. Security Considerations --------------------------- No current content. Comment: suggest that this section say that implementers and operators must= understand the security considerations presented in Section 14 of [I-D.iet= f-alto-protocol]. Further, the present section responds to the requirement = on the discovery process implied by Section 14.1.3 of [I-D.ietf-alto-protoc= ol]. 6.1. General Security Considerations ------------------------------------- Describes two failure modes: inability to get a URI at all, and getting a U= RI that points to a poor choice of Alto server or one containing the wrong = information either by misconfiguration or by malicious intent. In the latte= r case, advises operator to watch for undesirable traffic patterns or user = complaints of poor performance and terminate Alto service if they occur. Comment: this section presents no discussion of the mechanisms by which an = attacker may interfere with the Alto service. Without identifying potential= mechanisms, it is not possible to suggest mitigating measures.=20 To focus their discussion, the authors might wish to consider the organizat= ion of discussion in [I-D.ietf-alto-protocol]: "Risk Scenarios"=20 - "Protection Strategies" - "Limitations". 6.2. Security Considerations for U-NAPTR ----------------------------------------- Notes that "interception" of messages not an issue because the URI of the A= lto server in a domain is generally well known. Identifies three specific a= ttacks: falsified input domain name, DNS alteration, and actual server impe= rsonation. Suggests the use of DNSSEC to thwart DNS alteration and provides= some discussion of the use of https: to authenticate the server. Refers to= RFC 5986 for the rest. Comment: what the opening paragraph means to say is probably that message c= onfidentiality is unnecessary. Interception and modification or blocking of= messages would constitute attacks that you might discuss. Comment: once the discussion in Section 6.1 has been properly focussed, the= authors may need to reorganize the discussion to eliminate redundancy betw= een 6.1 and 6.2. Comment: most of Section 6.2 is copied from the Security Considerations sec= tion of RFC 5986. This is reasonable, since the contexts are very similar. = There is one real difference, in that, rather than suggesting administrativ= e constraints on the domain name used for the Alto server, the present docu= ment calls for the use of DNSSEC to ensure the validity of the returned URI= . Here is a suggestion for a more direct presentation of Section 6.2: - Section 5 of RFC 5986 is generally applicable to the present document, = with the substitution of the Alto server for the Location Information Serve= r (LIS). - That section identifies three attacks: falsified input domain name, DNS= alteration, and actual server impersonation, and suggests mitigating measu= res for each. Implementors and operators should read that section for detai= ls. - Rather than using the input domain provided by the user or DHCP in the = https: validation procedure (which implies administrative constraints on th= e domain name used for the Alto server), the present document recommends th= e use of DNSSEC to assure the validity of the returned URI, followed by the= use of the domain contained in the URI in the https: validation procedure. Thank you, Tina From kathleen.moriarty@emc.com Sat Jun 15 00:30:34 2013 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 6992C21F9AF5; Sat, 15 Jun 2013 00:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgnIS3C5OAjR; Sat, 15 Jun 2013 00:30:23 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9C62521F8616; Sat, 15 Jun 2013 00:30:22 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5F7Tv4V005414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Jun 2013 03:30:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 15 Jun 2013 03:29:51 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5F7TnOL029732; Sat, 15 Jun 2013 03:29:50 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Sat, 15 Jun 2013 03:29:49 -0400 From: "Moriarty, Kathleen" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-xrblock-rtcp-xr-discard.all@tools.ietf.org" Date: Sat, 15 Jun 2013 03:29:48 -0400 Thread-Topic: Secdir review of draft-ietf-xrblock-rtcp-xr-discard-14 Thread-Index: AQHOaZodlZZbCiEKO0SlKtWkEGsQsA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "sunseawq@huawei.com" , "gwz@net-zen.net" , "alan.d.clark@telchemy.com" Subject: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-discard-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: Sat, 15 Jun 2013 07:30:34 -0000 Secdir review draft-ietf-xrblock-rtcp-xr-discard-14 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. The document is ready. I agree with the security considerations section, n= o new security considerations are added from RFC3611. From yaronf.ietf@gmail.com Sun Jun 16 13:10:52 2013 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 6563821F9CF8; Sun, 16 Jun 2013 13:10:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epmzufvFNi4N; Sun, 16 Jun 2013 13:10:52 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 880AB21F9CB1; Sun, 16 Jun 2013 13:10:51 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c50so1368385eek.25 for ; Sun, 16 Jun 2013 13:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=pLn/bg6mRRj7l2yJXtE2KCn+zDfb89pt6t3GAWjoEgw=; b=SSaSJ7fB0+6obMTWBvnBMStDrlR+XW7IiS75sBKuYWb/ZpaROsxqnfQsNNjuVZ0JNq d6qxwnwFoFCwG2l5I9gZflx5ORkRuW+ja7uJRIeQDpvCp1Xc0xgHAeNMMEXYlFfuP+sk B9SdsNMCMIEPHfVSuw4WDpIR5lCco2gE3KWVlF1VZAxS5g5B6yz94nFbdOvMVMG1nfZ8 Gj/mVXzUmE/vWXqD62o5ydgIu4NmC0B1VKMht8kuRTUSlt68hzhKXUQcUzPMDtpw7R4+ GJYyh0rQMs2pjE7nOQHZUeiS+IzwU8u9fZYA/RzQSINP2fpdiI60Vn17fEJ0/iEUPmt1 SyVw== X-Received: by 10.15.44.10 with SMTP id y10mr13377777eev.5.1371413450623; Sun, 16 Jun 2013 13:10:50 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-181-121-100.red.bezeqint.net. [79.181.121.100]) by mx.google.com with ESMTPSA id bj46sm10038497eeb.13.2013.06.16.13.10.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Jun 2013 13:10:49 -0700 (PDT) Message-ID: <51BE1BC7.9080500@gmail.com> Date: Sun, 16 Jun 2013 23:10:47 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: IETF Security Directorate , The IESG , draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-pce-gmpls-aps-req-08 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, 16 Jun 2013 20:10:52 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines additional GMPLS-specific requirements on the PCE architecture. It would be an understatement to characterize this reviewer as a non-expert on PCE and GMPLS. That being said, I believe the Security Considerations are correct in saying that this document does not add any additional security issues on top of PCE. I would recommend to add a pointer to where such considerations are in fact listed, e.g. Sec. 10 of RFC 5440. Though security folks will cringe at TCP-MD5 being described as the most practical security solution in that section. Thanks, Yaron From adrian@olddog.co.uk Sun Jun 16 13:14:28 2013 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 3339321F9D18; Sun, 16 Jun 2013 13:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2ZKqx7XQvUw; Sun, 16 Jun 2013 13:14:22 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1764721F9D05; Sun, 16 Jun 2013 13:14:21 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5GKEJan011774; Sun, 16 Jun 2013 21:14:20 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5GKEI2u011761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Jun 2013 21:14:18 +0100 From: "Adrian Farrel" To: "'Yaron Sheffer'" References: <51BE1BC7.9080500@gmail.com> In-Reply-To: <51BE1BC7.9080500@gmail.com> Date: Sun, 16 Jun 2013 21:14:18 +0100 Message-ID: <010f01ce6ace$15788430$40698c90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHLh0WB0VH4mHfmMihaopBkqTJ8Y5k+jRaw Content-Language: en-gb Cc: draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org, 'The IESG' , 'IETF Security Directorate' Subject: Re: [secdir] SecDir review of draft-ietf-pce-gmpls-aps-req-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 20:14:28 -0000 Hi, Thanks Yaron. You're right about pointing to 5440. That document notes that TCP-AO should be used once it becomes available, and since it has done, a pointer to RFC 6952 would also be helpful. Cheers, Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Yaron > Sheffer > Sent: 16 June 2013 21:11 > To: IETF Security Directorate; The IESG; draft-ietf-pce-gmpls-aps- > req.all@tools.ietf.org > Subject: SecDir review of draft-ietf-pce-gmpls-aps-req-08 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This document defines additional GMPLS-specific requirements on the PCE > architecture. > > It would be an understatement to characterize this reviewer as a > non-expert on PCE and GMPLS. That being said, I believe the Security > Considerations are correct in saying that this document does not add any > additional security issues on top of PCE. > > I would recommend to add a pointer to where such considerations are in > fact listed, e.g. Sec. 10 of RFC 5440. Though security folks will cringe > at TCP-MD5 being described as the most practical security solution in > that section. > > Thanks, > Yaron From n@arifumi.net Mon Jun 17 04:28:05 2013 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 923AC21F9B95 for ; Mon, 17 Jun 2013 04:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xkUqGIoAt7s for ; Mon, 17 Jun 2013 04:28:02 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A6AE421F9B99 for ; Mon, 17 Jun 2013 04:27:41 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so2707280pbc.16 for ; Mon, 17 Jun 2013 04:27:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=TSJNrp7LuBFqbvKsU7zGKtMaAhYH5oJ7iDM1WpYy1Iw=; b=fihz2rc/fE84wPNzcen2pRTHoxjBuwFMifJv78ggSDbPYrnzd5txlw0FqmjgoKfQic q4JQUZ+6lhq0ceRE7BcMO3h7XbV9cH9+rRAWYcIktfXS8+hPDbJ5y283L+j8tR19D8ft 7vkE7ZOFPutbuuXsGWqcrInq/Pr+dVP9zRZdwtz2T9xPSVrmQNlg/SyuNnjIhdQ2yWM2 gw0VKjNkdSbxL5WLYwwHh51oKjzGfEGxcSvHziVPwwkxvffuvVSa49rbwIh1Q6Hn2GXq rPbyplRcotBnR8ADYairC+8RpvG9QdgKKaMHatfUlUrhv+VHOqeFVZm1IssxZiOtmLlI 0P4w== MIME-Version: 1.0 X-Received: by 10.68.28.232 with SMTP id e8mr12374604pbh.94.1371468459848; Mon, 17 Jun 2013 04:27:39 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.194.198 with HTTP; Mon, 17 Jun 2013 04:27:39 -0700 (PDT) X-Originating-IP: [2001:fa8:1010:0:e52f:f328:9ea2:e45d] In-Reply-To: <2B1856F1-537D-4268-A104-BDC180A4EC54@employees.org> References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> <5F8FAF51-833A-4C75-9FFC-BE17ADF27994@employees.org> <5ffd0e5973e67c773b8ce3d345010c8f.squirrel@www.trepanning.net> <2B1856F1-537D-4268-A104-BDC180A4EC54@employees.org> Date: Mon, 17 Jun 2013 20:27:39 +0900 X-Google-Sender-Auth: CF-ZfNopjv1ZLSCoPKAMqQrjsYE Message-ID: From: Arifumi Matsumoto To: Ole Troan Content-Type: multipart/mixed; boundary=bcaec520eacd5ec59604df57e280 X-Gm-Message-State: ALoCoQkZwTwaT9bnQzpGXkUpRw84cJKEeiXNGzF4tSlrEr6SG2zE7j1u3pVT+Jwp4aFwMJ8/ZPt5 Cc: "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , secdir@ietf.org, draft-ietf-6man-rfc3484bis@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 17 Jun 2013 11:28:05 -0000 --bcaec520eacd5ec59604df57e280 Content-Type: multipart/alternative; boundary=bcaec520eacd5ec59304df57e27e --bcaec520eacd5ec59304df57e27e Content-Type: text/plain; charset=ISO-8859-1 I attached a rev candidate. Hope this solves the issues pointed by Dan. Thank you very much. 2013/6/13 Ole Troan > Dan, > > > Yes, I am fine with Arifumi's clarification. Thanks. > > splendid, thanks for the help! > > Best regards, > Ole > > >> Dan, > >> > >> apologies for the delay, I discussed this directly with Arifumi, and I > >> hope his latest message clarifies the issue. > >> > >> to rephrase in my words; > >> OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to > disable > >> automatic row addition) > >> and to carry policy table options. > >> the A-flag is a hint to the host to disable automatic row addition. > >> if OPTION_ADDRSEL contains policy table options the A-flag is redundant. > >> (as policy table options and the A-flag are incompatible). > >> > >> if you are fine with this, I will ask the authors to update the draft to > >> make this behaviour explicit. > >> > >> Best regards, > >> Ole > >> > >>>> let me chime in as the document shepherd. > >>>> (thank you very much for the thorough comments by the way). > >>>> > >>>>> For instance, while I think I understand the policy override of RFC > >>>>> 6724, having the Automatic Row Additions Flag be part of the address > >>>>> selection options seems problematic. If it is set to zero, then what > >>>>> are > >>>>> the semantics of such a message? "Here's an address selection option > >>>>> but don't you dare use it!"? What is the point? Me, as a node, can > >>>>> have > >>>>> this as part of my policy state which would allow me to ignore such > >>>>> an update but to have the bit be part of the option to update does > >>>>> not seem to make much sense. The semantics of the message needs > >>>>> to be explained much more clearly, or the bit needs to be removed > >>>>> from the message. > >>>> > >>>> my reading of the meaning of the A flag is a little different. (I have > >>>> cc'ed the authors of rfc6724 for confirmation.) > >>>> > >>>> an implementation of RFC6724 may automatically add entries in the > >>>> policy > >>>> table based on addresses configured on the node. > >>>> e.g. the node has an interface with a ULA address. > >>>> > >>>> RFC6724 also says: > >>>> An implementation SHOULD provide a means (the Automatic Row Additions > >>>> flag) for an administrator to disable > >>>> automatic row additions. > >>> > >>> That makes perfect sense. A client implementation SHOULD provide a > >>> means to disable automatic row additions. So it has some knob that can > >>> be turned on or off locally that would allow for update of its policy > >>> table > >>> by receiving policy options (enable) or forbid received policy options > >>> from > >>> updating the policy table (disable). > >>> > >>>> the A-flag in draft-ietf-6man-addr-select-opt provides the means. > >>> > >>> So this is where I'm confused. The sender of the policy option should > >>> not have the ability to control the knob that an implementation added > >>> locally to satisfy RFC 6724. If a client implementation sets its knob > to > >>> "disable" then it forbids policy option updates to its policy table. It > >>> shouldn't inspect the received option update to decide whether it > >>> should override the setting of its local knob. > >>> > >>> This seems like a security issue to me. There's a reason why an > >>> implementation would choose to disable updates of its policy table > >>> and allowing the sender of policy updates to override that seems > >>> wrong. > >>> > >>>> it does not affect the policy entries that is contained in the DHCP > >>>> option. > >>>> the A-flag only affects the RFC6724 behaviour of adding entries based > >>>> on > >>>> address configuration on the node. > >>> > >>> Again, according to the draft a message can be received by a client > >>> implementation that provides policy update options to its policy table > >>> with semantics of "you SHOULD NOT use these!" So what is the point > >>> of sending that message? Why not just refrain from sending the message > >>> if that's what the message is? > >>> > >>> Would you ever tell someone, "disregard what I am about to tell you"? I > >>> can't see why. And that's what the semantics of this message seem to > be. > >> > >> > >> > >> > > > > --bcaec520eacd5ec59304df57e27e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I attached a rev candidate.
Hope this solve= s the issues pointed by Dan.

Thank you very much.<= /div>


20= 13/6/13 Ole Troan <otroan@employees.org>
Dan,

> =A0Yes, I am fine with Arifumi's clarification. Thanks.

splendid, thanks for the help!

Best regards,
Ole

>> Dan,
>>
>> apologies for the delay, I discussed this directly with Arifumi, a= nd I
>> hope his latest message clarifies the issue.
>>
>> to rephrase in my words;
>> OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to = disable
>> automatic row addition)
>> and to carry policy table options.
>> the A-flag is a hint to the host to disable automatic row addition= .
>> if OPTION_ADDRSEL contains policy table options the A-flag is redu= ndant.
>> (as policy table options and the A-flag are incompatible).
>>
>> if you are fine with this, I will ask the authors to update the dr= aft to
>> make this behaviour explicit.
>>
>> Best regards,
>> Ole
>>
>>>> let me chime in as the document shepherd.
>>>> (thank you very much for the thorough comments by the way)= .
>>>>
>>>>> For instance, while I think I understand the policy ov= erride of RFC
>>>>> 6724, having the Automatic Row Additions Flag be part = of the address
>>>>> selection options seems problematic. If it is set to z= ero, then what
>>>>> are
>>>>> the semantics of such a message? "Here's an a= ddress selection option
>>>>> but don't you dare use it!"? What is the poin= t? Me, as a node, can
>>>>> have
>>>>> this as part of my policy state which would allow me t= o ignore such
>>>>> an update but to have the bit be part of the option to= update does
>>>>> not seem to make much sense. The semantics of the mess= age needs
>>>>> to be explained much more clearly, or the bit needs to= be removed
>>>>> from the message.
>>>>
>>>> my reading of the meaning of the A flag is a little differ= ent. (I have
>>>> cc'ed the authors of rfc6724 for confirmation.)
>>>>
>>>> an implementation of RFC6724 may automatically add entries= in the
>>>> policy
>>>> table based on addresses configured on the node.
>>>> e.g. the node has an interface with a ULA address.
>>>>
>>>> RFC6724 also says:
>>>> =A0An implementation SHOULD provide a means (the Automatic= Row Additions
>>>> flag) for an administrator to disable
>>>> =A0automatic row additions.
>>>
>>> That makes perfect sense. A client implementation SHOULD provi= de a
>>> means to disable automatic row additions. So it has some knob = that can
>>> be turned on or off locally that would allow for update of its= policy
>>> table
>>> by receiving policy options (enable) or forbid received policy= options
>>> from
>>> updating the policy table (disable).
>>>
>>>> the A-flag in draft-ietf-6man-addr-select-opt provides the= means.
>>>
>>> So this is where I'm confused. The sender of the policy op= tion should
>>> not have the ability to control the knob that an implementatio= n added
>>> locally to satisfy RFC 6724. If a client implementation sets i= ts knob to
>>> "disable" then it forbids policy option updates to i= ts policy table. It
>>> shouldn't inspect the received option update to decide whe= ther it
>>> should override the setting of its local knob.
>>>
>>> This seems like a security issue to me. There's a reason w= hy an
>>> implementation would choose to disable updates of its policy t= able
>>> and allowing the sender of policy updates to override that see= ms
>>> wrong.
>>>
>>>> it does not affect the policy entries that is contained in= the DHCP
>>>> option.
>>>> the A-flag only affects the RFC6724 behaviour of adding en= tries based
>>>> on
>>>> address configuration on the node.
>>>
>>> Again, according to the draft a message can be received by a c= lient
>>> implementation that provides policy update options to its poli= cy table
>>> with semantics of "you SHOULD NOT use these!" So wha= t is the point
>>> of sending that message? Why not just refrain from sending the= message
>>> if that's what the message is?
>>>
>>> Would you ever tell someone, "disregard what I am about t= o tell you"? I
>>> can't see why. And that's what the semantics of this m= essage seem to be.
>>
>>
>>
>>
>


--bcaec520eacd5ec59304df57e27e-- --bcaec520eacd5ec59604df57e280 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-6man-addr-select-opt.txt" Content-Disposition: attachment; filename="draft-ietf-6man-addr-select-opt.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hi1ky3y80 CgoKCjZtYW4gV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEEuIE1hdHN1bW90bwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgVC4gRnVqaXNha2kKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlRUCkV4cGly ZXM6IERlY2VtYmVyIDE5LCAyMDEzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBULiBDaG93bgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFVuaXZlcnNpdHkgb2YgU291dGhhbXB0b24KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDE3LCAyMDEzCgoKICAgICAgICAgICBE aXN0cmlidXRpbmcgQWRkcmVzcyBTZWxlY3Rpb24gUG9saWN5IHVzaW5nIERIQ1B2NgogICAgICAg ICAgICAgICAgIGRyYWZ0LWlldGYtNm1hbi1hZGRyLXNlbGVjdC1vcHQtMTEudHh0CgpBYnN0cmFj dAoKICAgUkZDIDY3MjQgZGVmaW5lcyBkZWZhdWx0IGFkZHJlc3Mgc2VsZWN0aW9uIG1lY2hhbmlz bXMgZm9yIElQdjYgdGhhdAogICBhbGxvdyBub2RlcyB0byBzZWxlY3QgYW4gYXBwcm9wcmlhdGUg YWRkcmVzcyB3aGVuIGZhY2VkIHdpdGggbXVsdGlwbGUKICAgc291cmNlIGFuZC9vciBkZXN0aW5h dGlvbiBhZGRyZXNzZXMgdG8gY2hvb3NlIGJldHdlZW4uICBUaGUgUkZDIDY3MjQKICAgYWxsb3dl ZCBmb3IgdGhlIGZ1dHVyZSBkZWZpbml0aW9uIG9mIG1ldGhvZHMgdG8gYWRtaW5pc3RyYXRpdmVs eQogICBjb25maWd1cmUgdGhlIGFkZHJlc3Mgc2VsZWN0aW9uIHBvbGljeSBpbmZvcm1hdGlvbi4g IFRoaXMgZG9jdW1lbnQKICAgZGVmaW5lcyBhIG5ldyBESENQdjYgb3B0aW9uIGZvciBzdWNoIGNv bmZpZ3VyYXRpb24sIGFsbG93aW5nIGEgc2l0ZQogICBhZG1pbmlzdHJhdG9yIHRvIGRpc3RyaWJ1 dGUgYWRkcmVzcyBzZWxlY3Rpb24gcG9saWN5IG92ZXJyaWRpbmcgdGhlCiAgIGRlZmF1bHQgYWRk cmVzcyBzZWxlY3Rpb24gcGFyYW1ldGVycyBhbmQgcG9saWN5IHRhYmxlLCBhbmQgdGh1cwogICBj b250cm9sIHRoZSBhZGRyZXNzIHNlbGVjdGlvbiBiZWhhdmlvciBvZiBub2RlcyBpbiB0aGVpciBz aXRlLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJt aXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3 OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRo YXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMg YXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJh ZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVt IG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRl cm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBEZWNlbWJlciAxOSwgMjAxMy4KCkNvcHlyaWdodCBO b3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxMyBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBp ZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZl ZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRy dXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAo aHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRh dGUgb2YKCgoKTWF0c3Vtb3RvLCBldCBhbC4gICAgICAgRXhwaXJlcyBEZWNlbWJlciAxOSwgMjAx MyAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgIERIQ1B2NiBBZGRy ZXNzIFNlbGVjdGlvbiBQb2xpY3kgT3B0ICAgICAgICAgSnVuZSAyMDEzCgoKICAgcHVibGljYXRp b24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNh cmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdp dGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3Rl ZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vu c2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2Fs IFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2Ny aWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KCiAgIFRoaXMgZG9jdW1lbnQgbWF5 IGNvbnRhaW4gbWF0ZXJpYWwgZnJvbSBJRVRGIERvY3VtZW50cyBvciBJRVRGCiAgIENvbnRyaWJ1 dGlvbnMgcHVibGlzaGVkIG9yIG1hZGUgcHVibGljbHkgYXZhaWxhYmxlIGJlZm9yZSBOb3ZlbWJl cgogICAxMCwgMjAwOC4gIFRoZSBwZXJzb24ocykgY29udHJvbGxpbmcgdGhlIGNvcHlyaWdodCBp biBzb21lIG9mIHRoaXMKICAgbWF0ZXJpYWwgbWF5IG5vdCBoYXZlIGdyYW50ZWQgdGhlIElFVEYg VHJ1c3QgdGhlIHJpZ2h0IHRvIGFsbG93CiAgIG1vZGlmaWNhdGlvbnMgb2Ygc3VjaCBtYXRlcmlh bCBvdXRzaWRlIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLgogICBXaXRob3V0IG9idGFpbmlu ZyBhbiBhZGVxdWF0ZSBsaWNlbnNlIGZyb20gdGhlIHBlcnNvbihzKSBjb250cm9sbGluZwogICB0 aGUgY29weXJpZ2h0IGluIHN1Y2ggbWF0ZXJpYWxzLCB0aGlzIGRvY3VtZW50IG1heSBub3QgYmUg bW9kaWZpZWQKICAgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFyZHMgUHJvY2VzcywgYW5kIGRlcml2 YXRpdmUgd29ya3Mgb2YgaXQgbWF5CiAgIG5vdCBiZSBjcmVhdGVkIG91dHNpZGUgdGhlIElFVEYg U3RhbmRhcmRzIFByb2Nlc3MsIGV4Y2VwdCB0byBmb3JtYXQKICAgaXQgZm9yIHB1YmxpY2F0aW9u IGFzIGFuIFJGQyBvciB0byB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIKICAgdGhh biBFbmdsaXNoLgoKMS4gIEludHJvZHVjdGlvbgoKICAgW1JGQzY3MjRdIGRlc2NyaWJlcyBkZWZh dWx0IGFsZ29yaXRobXMgZm9yIHNlbGVjdGluZyBhbiBhZGRyZXNzIHdoZW4KICAgYSBub2RlIGhh cyBtdWx0aXBsZSBkZXN0aW5hdGlvbiBhbmQvb3Igc291cmNlIGFkZHJlc3NlcyB0byBjaG9vc2UK ICAgZnJvbSBieSB1c2luZyBhbiBhZGRyZXNzIHNlbGVjdGlvbiBwb2xpY3kuICBJbiBTZWN0aW9u IDIgb2YgUkZDIDY3MjQsCiAgIGl0IGlzIHN1Z2dlc3RlZCB0aGF0IHRoZSBkZWZhdWx0IHBvbGlj eSB0YWJsZSBtYXkgYmUgYWRtaW5pc3RyYXRpdmVseQogICBjb25maWd1cmVkIHRvIHN1aXQgdGhl IHNwZWNpZmljIG5lZWRzIG9mIGEgc2l0ZS4gIFRoaXMgc3BlY2lmaWNhdGlvbgogICBkZWZpbmVz IGEgbmV3IERIQ1B2NiBvcHRpb24gZm9yIHN1Y2ggY29uZmlndXJhdGlvbi4KCiAgIFNvbWUgcHJv YmxlbXMgaGF2ZSBiZWVuIGlkZW50aWZpZWQgd2l0aCB0aGUgZGVmYXVsdCBbUkZDMzQ4NF0gYWRk cmVzcwogICBzZWxlY3Rpb24gcG9saWN5LCB3aGljaCB3YXMgb2Jzb2xldGVkIGJ5IFtSRkM2NzI0 XS4gIEl0IGlzIHVubGlrZWx5CiAgIHRoYXQgYW55IGRlZmF1bHQgcG9saWN5IHdpbGwgc3VpdCBh bGwgc2NlbmFyaW9zLCBhbmQgdGh1cyBtZWNoYW5pc21zCiAgIHRvIGNvbnRyb2wgdGhlIHNvdXJj ZSBhZGRyZXNzIHNlbGVjdGlvbiBwb2xpY3kgd2lsbCBiZSBuZWNlc3NhcnkuCiAgIFJlcXVpcmVt ZW50cyBmb3IgdGhvc2UgbWVjaGFuaXNtcyBhcmUgZGVzY3JpYmVkIGluIFtSRkM1MjIxXSwgd2hp bGUKICAgc29sdXRpb25zIGFyZSBkaXNjdXNzZWQgaW4KICAgW0ktRC5pZXRmLTZtYW4tYWRkci1z ZWxlY3QtY29uc2lkZXJhdGlvbnNdLiAgVGhvc2UgZG9jdW1lbnRzIGhhdmUKICAgaGVscGVkIHNo YXBlIHRoZSBpbXByb3ZlbWVudHMgaW4gdGhlIGRlZmF1bHQgYWRkcmVzcyBzZWxlY3Rpb24KICAg YWxnb3JpdGhtIGluIFtSRkM2NzI0XSBhcyB3ZWxsIGFzIHRoZSBESENQdjYgb3B0aW9uIGRlZmlu ZWQgaW4gdGhpcwogICBzcGVjaWZpY2F0aW9uLgoKMS4xLiAgQ29udmVudGlvbnMgVXNlZCBpbiBU aGlzIERvY3VtZW50CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJS RUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFy ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKMS4yLiAgVGVy bWlub2xvZ3kKCgoKCgpNYXRzdW1vdG8sIGV0IGFsLiAgICAgICBFeHBpcmVzIERlY2VtYmVyIDE5 LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgREhDUHY2 IEFkZHJlc3MgU2VsZWN0aW9uIFBvbGljeSBPcHQgICAgICAgICBKdW5lIDIwMTMKCgogICBUaGlz IGRvY3VtZW50IHVzZXMgdGhlIHRlcm1pbm9sb2d5IGRlZmluZWQgaW4gW1JGQzI0NjBdIGFuZCB0 aGUKICAgREhDUHY2IHNwZWNpZmljYXRpb24gZGVmaW5lZCBpbiBbUkZDMzMxNV0KCjIuICBBZGRy ZXNzIFNlbGVjdGlvbiBvcHRpb25zCgogICBUaGUgQWRkcmVzcyBTZWxlY3Rpb24gb3B0aW9uIHBy b3ZpZGVzIHRoZSBhZGRyZXNzIHNlbGVjdGlvbiBwb2xpY3kKICAgdGFibGUsIGFuZCBzb21lIG90 aGVyIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycy4KCiAgIEFuIEFkZHJlc3MgU2VsZWN0aW9uIG9w dGlvbiBjb250YWlucyB6ZXJvIG9yIG1vcmUgcG9saWN5IHRhYmxlCiAgIG9wdGlvbnMuICBNdWx0 aXBsZSBQb2xpY3kgVGFibGUgb3B0aW9ucyBpbiBhbiBBZGRyZXNzIFNlbGVjdGlvbgogICBvcHRp b24gY29uc3RpdHV0ZSBhIHNpbmdsZSBwb2xpY3kgdGFibGUuICBXaGVuIGl0IGRvZXMgbm90IGNv bnRhaW4KICAgcG9saWN5IHRhYmxlIG9wdGlvbiwgaXQgaXMgdXNlZCB0byBjb252ZXkgdGhlIEEg YW5kIFAgZmxhZ3MuCgogICBUaGUgZm9ybWF0IG9mIHRoZSBBZGRyZXNzIFNlbGVjdGlvbiBvcHRp b24gaXMgZ2l2ZW4gYmVsb3cuCgogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgICAgIHwgICAgICAgICAgT1BUSU9OX0FERFJTRUwgICAgICAgfCAgICAgICAgIG9wdGlv bi1sZW4gICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgIFJlc2VydmVkIHxBfFB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICst Ky0rLSstKy0rLSstKy0rICAgICBQT0xJQ1kgVEFCTEUgT1BUSU9OUyAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgKHZhcmlhYmxlIGxlbmd0aCkgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICAg ICAgICAgICAgICAgIEZpZ3VyZSAxOiBBZGRyZXNzIFNlbGVjdGlvbiBvcHRpb24gZm9ybWF0CgoK CiAgIG9wdGlvbi1jb2RlOiAgT1BUSU9OX0FERFJTRUwgKFRCRCkuCgoKICAgb3B0aW9uLWxlbjog IFRoZSB0b3RhbCBsZW5ndGggb2YgdGhlIFJlc2VydmVkIGZpZWxkLCBBLCBQIGZsYWdzLCBhbmQK ICAgICAgICBQT0xJQ1kgVEFCTEUgT1BUSU9OUyBpbiBvY3RldHMuCgoKICAgUmVzZXJ2ZWQ6ICBS ZXNlcnZlZCBmaWVsZC4gIFNlcnZlciBNVVNUIHNldCB0aGlzIHZhbHVlIHRvIHplcm8gYW5kCiAg ICAgICAgY2xpZW50IE1VU1QgaWdub3JlIGl0cyBjb250ZW50LgoKCiAgIEE6ICAgQXV0b21hdGlj IFJvdyBBZGRpdGlvbiBmbGFnLiAgVGhpcyBmbGFnIHRvZ2dsZXMgdGhlIEF1dG9tYXRpYwogICAg ICAgIFJvdyBBZGRpdGlvbiBmbGFnIGF0IGNsaWVudCBob3N0cywgd2hpY2ggaXMgZGVzY3JpYmVk IGluIHRoZQogICAgICAgIHNlY3Rpb24gMi4xIGluIFtSRkM2NzI0XS4gIElmIHRoaXMgZmxhZyBp cyBzZXQgdG8gMSwgaXQgZG9lcyBub3QKICAgICAgICBjaGFuZ2UgY2xpZW50IGhvc3QgYmVoYXZp b3IsIHRoYXQgaXMsIGEgY2xpZW50IE1BWSBhdXRvbWF0aWNhbGx5CiAgICAgICAgYWRkIGFkZGl0 aW9uYWwgc2l0ZS1zcGVjaWZpYyByb3dzIHRvIHRoZSBwb2xpY3kgdGFibGUuICBJZiBzZXQKICAg ICAgICB0byAwLCB0aGUgQXV0b21hdGljIFJvdyBBZGRpdGlvbiBmbGFnIGlzIGRpc2FibGVkLCBh bmQgYSBjbGllbnQKICAgICAgICBTSE9VTEQgTk9UIGF1dG9tYXRpY2FsbHkgYWRkIHJvd3MgdG8g dGhlIHBvbGljeSB0YWJsZS4gIElmIHRoZQoKCgpNYXRzdW1vdG8sIGV0IGFsLiAgICAgICBFeHBp cmVzIERlY2VtYmVyIDE5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1E cmFmdCAgICAgREhDUHY2IEFkZHJlc3MgU2VsZWN0aW9uIFBvbGljeSBPcHQgICAgICAgICBKdW5l IDIwMTMKCgogICAgICAgIG9wdGlvbiBjb250YWlucyBhIFBPTElDWSBUQUJMRSBvcHRpb24sIHRo aXMgZmxhZyBpcyBtZWFuaW5nbGVzcywKICAgICAgICBhbmQgYXV0b21hdGljIHJvdyBhZGRpdGlv biBTSE9VTEQgTk9UIGJlIHBlcmZvcm1lZCBhZ2FpbnN0IHRoZQogICAgICAgIGRpc3RyaWJ1dGVk IHBvbGljeSB0YWJsZS4KCgogICBQOiAgIFByaXZhY3kgUHJlZmVyZW5jZSBmbGFnLiAgVGhpcyBm bGFnIHRvZ2dsZXMgdGhlIFByaXZhY3kKICAgICAgICBQcmVmZXJlbmNlIGZsYWcgYXQgY2xpZW50 IGhvc3RzLCB3aGljaCBpcyBkZXNjcmliZWQgaW4gdGhlCiAgICAgICAgc2VjdGlvbiA1IGluIFtS RkM2NzI0XS4gIElmIHRoaXMgZmxhZyBpcyBzZXQgdG8gMSwgaXQgZG9lcyBub3QKICAgICAgICBj aGFuZ2UgY2xpZW50IGhvc3QgYmVoYXZpb3IsIHRoYXQgaXMsIGEgY2xpZW50IHdpbGwgcHJlZmVy CiAgICAgICAgdGVtcG9yYXJ5IGFkZHJlc3Nlcy4gIElmIHNldCB0byAwLCB0aGUgUHJpdmFjeSBQ cmVmZXJlbmNlIGZsYWcKICAgICAgICBpcyBkaXNhYmxlZCwgYW5kIGEgY2xpZW50IHdpbGwgcHJl ZmVyIHB1YmxpYyBhZGRyZXNzZXMuCgoKICAgUE9MSUNZIFRBQkxFIE9QVElPTlM6ICBaZXJvIG9y IG1vcmUgQWRkcmVzcyBTZWxlY3Rpb24gUG9saWN5IFRhYmxlCiAgICAgICAgb3B0aW9ucyBkZXNj cmliZWQgYmVsb3cuICBUaGlzIG9wdGlvbiBjb3JyZXNwb25kcyB0byBhIHJvdyBpbgogICAgICAg IHRoZSBwb2xpY3kgdGFibGUgZGVmaW5lZCBpbiB0aGUgc2VjdGlvbiAyLjEgaW4gW1JGQzY3MjRd LgoKCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgICAgICAzCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAg T1BUSU9OX0FERFJTRUxfVEFCTEUgICAgICB8ICAgICAgICAgb3B0aW9uLWxlbiAgICAgICAgICAg IHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICBsYWJlbCAgICAgIHwgIHByZWNlZGVuY2UgICB8 ICAgcHJlZml4LWxlbiAgfCAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgIHwKICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICBwcmVmaXggICAodmFyaWFibGUgbGVuZ3Ro KSAgICAgICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAg ICAgICAgIEZpZ3VyZSAyOiBBZGRyZXNzIFNlbGVjdGlvbiBQb2xpY3kgVGFibGUgb3B0aW9uIGZv cm1hdAoKCgogICBvcHRpb24tY29kZTogIE9QVElPTl9BRERSU0VMX1RBQkxFIChUQkQpLgoKCiAg IG9wdGlvbi1sZW46ICBUaGUgdG90YWwgbGVuZ3RoIG9mIHRoZSBsYWJlbCBmaWVsZCwgcHJlY2Vk ZW5jZSBmaWVsZCwKICAgICAgICBwcmVmaXgtbGVuIGZpZWxkLCBhbmQgcHJlZml4IGZpZWxkLgoK CiAgIGxhYmVsOiAgQW4gOC1iaXQgdW5zaWduZWQgaW50ZWdlcjsgdGhpcyB2YWx1ZSBpcyBmb3Ig Y29ycmVsYXRpb24gb2YKICAgICAgICBzb3VyY2UgYWRkcmVzcyBwcmVmaXhlcyBhbmQgZGVzdGlu YXRpb24gYWRkcmVzcyBwcmVmaXhlcy4gIFRoaXMKICAgICAgICBmaWVsZCBpcyB1c2VkIHRvIGRl bGl2ZXIgYSBsYWJlbCB2YWx1ZSBpbiBbUkZDNjcyNF0gcG9saWN5CiAgICAgICAgdGFibGUuCgoK CgoKCk1hdHN1bW90bywgZXQgYWwuICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTksIDIwMTMgICAg ICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICBESENQdjYgQWRkcmVzcyBT ZWxlY3Rpb24gUG9saWN5IE9wdCAgICAgICAgIEp1bmUgMjAxMwoKCiAgIHByZWNlZGVuY2U6ICBB biA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyOyB0aGlzIHZhbHVlIGlzIHVzZWQgZm9yCiAgICAgICAg c29ydGluZyBkZXN0aW5hdGlvbiBhZGRyZXNzZXMuICBUaGlzIGZpZWxkIGlzIHVzZWQgdG8gdG8g ZGVsaXZlcgogICAgICAgIGEgcHJlY2VkZW5jZSB2YWx1ZSBpbiBbUkZDNjcyNF0gcG9saWN5IHRh YmxlLgoKCiAgIHByZWZpeC1sZW46ICBBbiA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyOyB0aGUgbnVt YmVyIG9mIGxlYWRpbmcgYml0cyBpbgogICAgICAgIHRoZSBwcmVmaXggdGhhdCBhcmUgdmFsaWQu ICBUaGUgdmFsdWUgcmFuZ2VzIGZyb20gMCB0byAxMjguCgoKICAgcHJlZml4OiAgQSB2YXJpYWJs ZS1sZW5ndGggZmllbGQgY29udGFpbmluZyBhbiBJUCBhZGRyZXNzIG9yIHRoZQogICAgICAgIHBy ZWZpeCBvZiBhbiBJUCBhZGRyZXNzLiAgQW4gSVB2NC1tYXBwZWQgYWRkcmVzcyBbUkZDNDI5MV0g bXVzdAogICAgICAgIGJlIHVzZWQgdG8gcmVwcmVzZW50IGFuIElQdjQgYWRkcmVzcyBhcyBhIHBy ZWZpeCB2YWx1ZS4gIFRoaXMKICAgICAgICBmaWVsZCBpcyBwYWRkZWQgd2l0aCB6ZXJvcyB1cCB0 byB0aGUgbmVhcmVzdCBvY3RldCBib3VuZGFyeSB3aGVuCiAgICAgICAgcHJlZml4Ni1sZW4gaXMg bm90IGRpdmlzaWJsZSBieSA4LiAgVGhpcyBjYW4gYmUgZXhwcmVzc2VkIHVzaW5nCiAgICAgICAg dGhlIGZvbGxvd2luZyBlcXVhdGlvbjogKHByZWZpeC1sZW4rNykvOCBTbyB0aGUgbGVuZ3RoIG9m IHRoaXMKICAgICAgICBmaWVsZCBzaG91bGQgYmUgYmV0d2VlbiAwIGFuZCAxNiBieXRlcy4gIEZv ciBleGFtcGxlLCB0aGUgcHJlZml4CiAgICAgICAgMjAwMTpkYjg6Oi82MCB3b3VsZCBiZSBlbmNv ZGVkIHdpdGggYW4gcHJlZml4LWxlbiBvZiA2MCwgdGhlCiAgICAgICAgcHJlZml4IHdvdWxkIGJl IDggb2N0ZXRzIGFuZCB3b3VsZCBjb250YWlucyBvY3RldHMgMjAgMDEgMGQgYjgKICAgICAgICAw MCAwMCAwMCAwMC4KCgozLiAgUHJvY2Vzc2luZyB0aGUgQWRkcmVzcyBTZWxlY3Rpb24gb3B0aW9u CgogICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGhvdyB0byBwcm9jZXNzIHJlY2VpdmVkIEFkZHJl c3MgU2VsZWN0aW9uCiAgIG9wdGlvbiBhdCB0aGUgREhDUHY2IGNsaWVudC4KCiAgIFRoaXMgb3B0 aW9uJ3MgY29uY2VwdCBpcyB0byBzZXJ2ZSBhcyBhIGhpbnQgZm9yIGEgbm9kZSBhYm91dCBob3cg dG8KICAgYmVoYXZlIGluIHRoZSBuZXR3b3JrLiAgVWx0aW1hdGVseSwgaXQgY2FuIGJlIGNvbnRy b2xsZWQgYnkgdGhlCiAgIG5vZGUncyBhZG1pbmlzdHJhdG9yIGhvdyB0byBkZWFsIHdpdGggdGhl IHJlY2VpdmVkIHBvbGljeQogICBpbmZvcm1hdGlvbiwgYnV0IHRoZSBpbXBsZW1lbnRhdGlvbiBT SE9VTEQgZm9sbG93IHRoZSB3YXkgZGVzY3JpYmVkCiAgIGJlbG93IHVuaWZvcm1seSB0byBlYXNl IGRpYWdub3NlIGJyb2tlbm5lc3MgYW5kIHRvIHJlZHVjZSBvcGVyYXRpb25hbAogICBjb3N0cy4K CjMuMS4gIEhhbmRsaW5nIG9mIHRoZSBsb2NhbCBjb25maWd1cmF0aW9ucwoKICAgW1JGQzY3MjRd IGRlZmluZXMgdGhlIHR3byBmbGFncyBhbmQgdGhlIGRlZmF1bHQgcG9saWN5IHRhYmxlLiAgQWxz bywKICAgdXNlcnMgYXJlIHVzdWFsbHkgYWJsZSB0byBjb25maWd1cmUgdGhlIGZsYWdzIGFuZCB0 aGUgcG9saWN5IHRhYmxlIHRvCiAgIHNhdGlzZnkgdGhlaXIgb3duIHJlcXVpcmVtZW50cy4KCiAg IFRoZSBjbGllbnQgaW1wbGVtZW50YXRpb24gU0hPVUxEIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBj aG9pY2VzIHRvIHRoZQogICB1c2VyLiAgQ2hvaWNlIChhKSBTSE9VTEQgYmUgZGVmYXVsdCwgYXMg ZmFyIGFzIHRoZSBwb2xpY3kgdGFibGUgaXMKICAgbm90IGNvbmZpZ3VyZWQgYnkgdGhlIHVzZXIu CgogICAoYSkgIHJlcGxhY2UgdGhlIGV4aXN0aW5nIGZsYWdzIGFuZCBhY3RpdmUgcG9saWN5IHRh YmxlIHdpdGggdGhlCiAgICAgIERIQ1B2NiBkaXN0cmlidXRlZCBmbGFncyBhbmQgcG9saWN5IHRh YmxlLgoKICAgKGIpICBwcmVzZXJ2ZSB0aGUgZXhpc3RpbmcgZmxhZ3MgYW5kIGFjdGl2ZSBwb2xp Y3kgdGFibGUsIHdoZXRoZXIKICAgICAgdGhpcyBiZSB0aGUgZGVmYXVsdCBwb2xpY3kgdGFibGUs IG9yIHVzZXIgY29uZmlndXJlZCBwb2xpY3kuCgoKCk1hdHN1bW90bywgZXQgYWwuICAgICAgIEV4 cGlyZXMgRGVjZW1iZXIgMTksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0 LURyYWZ0ICAgICBESENQdjYgQWRkcmVzcyBTZWxlY3Rpb24gUG9saWN5IE9wdCAgICAgICAgIEp1 bmUgMjAxMwoKCjMuMi4gIEhhbmRsaW5nIG9mIHRoZSBzdGFsZSBwb2xpY3kgdGFibGUKCiAgIFdo ZW4gdGhlIGluZm9ybWF0aW9uIGZyb20gdGhlIERIQ1Agc2VydmVyIGdvZXMgc3RhbGUsIHRoZSBw b2xpY3kKICAgcmVjZWl2ZWQgZnJvbSB0aGUgREhDUCBzZXJ2ZXIgU0hPVUxEIGJlIGRlcHJlY2F0 ZWQuCgogICBUaGUgcmVjZWl2ZWQgaW5mb3JtYXRpb24gY2FuIGJlIGNvbnNpZGVyZWQgc3RhbGUg aW4gc2V2ZXJhbCBjYXNlcywKICAgc3VjaCBhcywgd2hlbiB0aGUgaW50ZXJmYWNlIGdvZXMgZG93 biwgdGhlIERIQ1Agc2VydmVyIGRvZXMgbm90CiAgIHJlc3BvbmQgZm9yIGEgY2VydGFpbiBhbW91 bnQgb2YgdGltZSwgYW5kIHRoZSBJbmZvcm1hdGlvbiBSZWZyZXNoCiAgIFRpbWUgaXMgZXhwaXJl ZC4KCjMuMy4gIE11bHRpLWludGVyZmFjZSBzaXR1YXRpb24KCiAgIFRoZSBwb2xpY3kgdGFibGUs IGFuZCBvdGhlciBwYXJhbWV0ZXJzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGFyZQogICBu b2RlLWdsb2JhbCBpbmZvcm1hdGlvbiBieSB0aGVpciBuYXR1cmUuICBPbmUgcmVhc29uIGJlaW5n IHRoYXQgdGhlCiAgIG91dGJvdW5kIGludGVyZmFjZSBpcyB1c3VhbGx5IGNob3NlbiBhZnRlciBk ZXN0aW5hdGlvbiBhZGRyZXNzCiAgIHNlbGVjdGlvbi4gIFNvLCBhIGhvc3QgY2Fubm90IG1ha2Ug dXNlIG9mIG11bHRpcGxlIGFkZHJlc3Mgc2VsZWN0aW9uCiAgIHBvbGljaWVzIGV2ZW4gaWYgdGhl eSBhcmUgc3RvcmVkIHBlciBpbnRlcmZhY2UuCgogICBUaGUgcG9saWN5IHRhYmxlIGlzIGRlZmlu ZWQgYXMgYSB3aG9sZSwgc28gdGhlIHNsaWdodGVzdCBhZGRpdGlvbi8KICAgZGVsZXRpb24gZnJv bSB0aGUgcG9saWN5IHRhYmxlIGJyaW5ncyBhIGNoYW5nZSBpbiBzZW1hbnRpY3Mgb2YgdGhlCiAg IHBvbGljeS4KCiAgIEl0IGFsc28gc2hvdWxkIGJlIG5vdGVkIHRoYXQgYWJzZW5jZSBvZiB0aGUg ZGlzdHJpYnV0ZWQgcG9saWN5IGZyb20gYQogICBjZXJ0YWluIG5ldHdvcmsgaW50ZXJmYWNlIHNo b3VsZCBub3QgYmUgZGV0ZXJtaW5lZCB0aGF0IHRoZSBuZXR3b3JrCiAgIGRvZXMgbm90IGNhcmUg YWJvdXQgYWRkcmVzcyBzZWxlY3Rpb24gcG9saWN5IGF0IGFsbCwgYmVjYXVzZSBpdCBtYXkKICAg bWVhbiBwcmVmZXJlbmNlIGZvciB0aGUgZGVmYXVsdCBhZGRyZXNzIHNlbGVjdGlvbiBwb2xpY3ku ICBTbywgaXQKICAgc2hvdWxkIGJlIHNhZmUgdG8gYXNzdW1lIHRoYXQgc3VjaCBhIG5ldHdvcmsg cHJlZmVycyB0aGUgZGVmYXVsdAogICBhZGRyZXNzIHNlbGVjdGlvbiBwb2xpY3kuCgogICBVbmRl ciB0aGUgYWJvdmUgYXNzdW1wdGlvbnMsIGhvdyB0byBoYW5kbGUgcmVjZWl2ZWQgcG9saWN5IGlz CiAgIHNwZWNpZmllZCBiZWxvdy4KCiAgIEluIHRoZSBhYnNlbmNlIG9mIGRpc3RyaWJ1dGVkIHBv bGljeSBmb3IgYSBjZXJ0YWluIG5ldHdvcmsgaW50ZXJmYWNlLAogICB0aGUgZGVmYXVsdCBhZGRy ZXNzIHNlbGVjdGlvbiBwb2xpY3kgU0hPVUxEIGJlIHVzZWQuICBBIG5vZGUgc2hvdWxkCiAgIHVz ZSBBZGRyZXNzIFNlbGVjdGlvbiBvcHRpb25zIGJ5IGRlZmF1bHQgaW4gYW55IG9mIHRoZSBmb2xs b3dpbmcgdHdvCiAgIGNhc2VzOgoKICAgMTogQSBzaW5nbGUtaG9tZWQgaG9zdCBTSE9VTEQgdXNl IGRlZmF1bHQgYWRkcmVzcyBzZWxlY3Rpb24gb3B0aW9ucywKICAgICAgd2hlcmUgdGhlIGhvc3Qg YmVsb25ncyB0byBvbmUgYWRtaW5pc3RyYXRpdmUgbmV0d29yayBkb21haW4KICAgICAgZXhjbHVz aXZlbHkgdXN1YWxseSB0aHJvdWdoIG9uZSBhY3RpdmUgbmV0d29yayBpbnRlcmZhY2UuCgogICAy OiBIb3N0IHRoYXQgdXNlIGFkdmFuY2VkIGhldXJpc3RpY3MgdG8gZGVhbCB3aXRoIG11bHRpcGxl IHJlY2VpdmVkCiAgICAgIHBvbGljeSB0aGF0IGFyZSBkZWZpbmVkIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQgU0hPVUxECiAgICAgIHVzZSBBZGRyZXNzIFNlbGVjdGlvbiBvcHRp b25zLgoKICAgSW1wbGVtZW50YXRpb25zIE1BWSBwcm92aWRlIGNvbmZpZ3VyYXRpb24gb3B0aW9u cyB0byBlbmFibGUgdGhpcwogICBwcm90b2NvbCBvbiBhIHBlciBpbnRlcmZhY2UgYmFzaXMuCgoK CgpNYXRzdW1vdG8sIGV0IGFsLiAgICAgICBFeHBpcmVzIERlY2VtYmVyIDE5LCAyMDEzICAgICAg ICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgREhDUHY2IEFkZHJlc3MgU2Vs ZWN0aW9uIFBvbGljeSBPcHQgICAgICAgICBKdW5lIDIwMTMKCgogICBJbXBsZW1lbnRhdGlvbnMg TUFZIHN0b3JlIGRpc3RyaWJ1dGVkIGFkZHJlc3Mgc2VsZWN0aW9uIHBvbGljaWVzIHBlcgogICBp bnRlcmZhY2UuICBUaGV5IGNhbiBiZSB1c2VkIGVmZmVjdGl2ZWx5IG9uIHN1Y2ggaW1wbGVtZW50 YXRpb25zIHRoYXQKICAgYWRvcHQgcGVyLWFwcGxpY2F0aW9uIGludGVyZmFjZSBzZWxlY3Rpb24u Cgo0LiAgSW1wbGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMKCiAgIG8gIFRoZSB2YWx1ZSAnbGFi ZWwnIGlzIHBhc3NlZCBhcyBhbiB1bnNpZ25lZCBpbnRlZ2VyLCBidXQgdGhlcmUgaXMKICAgICAg bm8gc3BlY2lhbCBtZWFuaW5nIGZvciB0aGUgdmFsdWUsIHRoYXQgaXMgd2hldGhlciBpdCBpcyBh IGxhcmdlIG9yCiAgICAgIHNtYWxsIG51bWJlci4gIEl0IGlzIHVzZWQgdG8gc2VsZWN0IGEgcHJl ZmVycmVkIHNvdXJjZSBhZGRyZXNzCiAgICAgIHByZWZpeCBjb3JyZXNwb25kaW5nIHRvIGEgZGVz dGluYXRpb24gYWRkcmVzcyBwcmVmaXggYnkgbWF0Y2hpbmcKICAgICAgdGhlIHNhbWUgbGFiZWwg dmFsdWUgd2l0aGluIHRoZSBESENQIG1lc3NhZ2UuICBESENQdjYgY2xpZW50cwogICAgICBTSE9V TEQgY29udmVydCB0aGlzIGxhYmVsIHRvIGEgcmVwcmVzZW50YXRpb24gYXBwcm9wcmlhdGUgZm9y IHRoZQogICAgICBsb2NhbCBpbXBsZW1lbnRhdGlvbiAoZS5nLiwgc3RyaW5nKS4KCgogICBvICBD dXJyZW50bHksIHRoZSBsYWJlbCBhbmQgcHJlY2VkZW5jZSB2YWx1ZXMgYXJlIGRlZmluZWQgYXMg OC1iaXQKICAgICAgdW5zaWduZWQgaW50ZWdlcnMuICBJbiBhbG1vc3QgYWxsIGNhc2VzLCB0aGlz IHZhbHVlIHdpbGwgYmUKICAgICAgZW5vdWdoLgoKCiAgIG8gIFRoZSBtYXhpbXVtIG51bWJlciBv ZiBhZGRyZXNzIHNlbGVjdGlvbiBydWxlcyB0aGF0IG1heSBiZSBjb252ZXllZAogICAgICBpbiBv bmUgREhDUHY2IG1lc3NhZ2UgZGVwZW5kcyBvbiB0aGUgcHJlZml4IGxlbmd0aCBvZiBlYWNoIHJ1 bGUKICAgICAgYW5kIHRoZSBtYXhpbXVtIERIQ1B2NiBtZXNzYWdlIHNpemUgZGVmaW5lZCBpbiBb UkZDMzMxNV0uICBJdCBpcwogICAgICBwb3NzaWJsZSB0byBjYXJyeSBvdmVyIDMsMDAwIHJ1bGVz IGluIG9uZSBESENQdjYgbWVzc2FnZSAobWF4aW11bQogICAgICBVRFAgbWVzc2FnZSBzaXplKS4g IEhvd2V2ZXIsIGl0IHNob3VsZCBub3QgYmUgZXhwZWN0ZWQgdGhhdCBESENQCiAgICAgIGNsaWVu dHMsIHNlcnZlcnMgYW5kIHJlbGF5IGFnZW50cyBjYW4gaGFuZGxlIFVEUCBmcmFnbWVudGF0aW9u LgogICAgICBOZXR3b3JrIGFkaW1pbmlzdHJhdG9ycyBTSE9VTEQgY29uc2lkZXIgbG9jYWwgbGlt aXRhdGlvbnMgdG8gdGhlCiAgICAgIG1heGltdW0gREhDUHY2IG1lc3NhZ2Ugc2l6ZSB0aGF0IGNh biBiZSByZWxpYWJseSB0cmFuc3BvcnRlZCB2aWEKICAgICAgdGhlaXIgc3BlY2lmaWMgbG9jYWwg aW5mcmFzdHJ1Y3R1cmUgdG8gZW5kIG5vZGVzOyBhbmQgdGhlcmVmb3JlCiAgICAgIHRoZXkgU0hP VUxEIGNvbnNpZGVyIHRoZSBudW1iZXIgb2Ygb3B0aW9ucywgdGhlIHRvdGFsIHNpemUgb2YgdGhl CiAgICAgIG9wdGlvbnMsIGFuZCB0aGUgcmVzdWx0aW5nIERIQ1B2NiBtZXNzYWdlIHNpemUsIHdo ZW4gZGVmaW5pbmcKICAgICAgdGhlaXIgUG9saWN5IFRhYmxlLgoKCjUuICBTZWN1cml0eSBDb25z aWRlcmF0aW9ucwoKICAgQSByb2d1ZSBESENQdjYgc2VydmVyIGNvdWxkIGlzc3VlIGJvZ3VzIGFk ZHJlc3Mgc2VsZWN0aW9uIHBvbGljaWVzIHRvCiAgIGEgY2xpZW50LiAgVGhpcyBtaWdodCBsZWFk IHRvIGluY29ycmVjdCBhZGRyZXNzIHNlbGVjdGlvbiBieSB0aGUKICAgY2xpZW50LCBhbmQgdGhl IGFmZmVjdGVkIHBhY2tldHMgbWlnaHQgYmUgYmxvY2tlZCBhdCBhbiBvdXRnb2luZyBJU1AKICAg YmVjYXVzZSBvZiBpbmdyZXNzIGZpbHRlcmluZywgaW5jdXIgYWRkaXRpb25hbCBuZXR3b3JrIGNo YXJnZXMsIG9yIGJlCiAgIG1pc2RpcmVjdGVkIHRvIGFuIGF0dGFja2VyJ3MgbWFjaGluZS4gIEFs dGVybmF0aXZlbHksIGFuIElQdjYKICAgdHJhbnNpdGlvbiBtZWNoYW5pc20gbWlnaHQgYmUgcHJl ZmVycmVkIG92ZXIgbmF0aXZlIElQdjYsIGV2ZW4gaWYgaXQKICAgaXMgYXZhaWxhYmxlLiAgVG8g Z3VhcmQgYWdhaW5zdCBzdWNoIGF0dGFja3MsIGEgbGVnaXRpbWF0ZSBESENQdjYKICAgc2VydmVy IHNob3VsZCBjb21tdW5pY2F0ZSB0aHJvdWdoIGEgc2VjdXJlLCB0cnVzdGVkIGNoYW5uZWwsIHN1 Y2ggYXMKICAgYSBjaGFubmVsIHByb3RlY3RlZCBieSBJUHNlYywgU0VORCBhbmQgREhDUCBhdXRo ZW50aWNhdGlvbiwgYXMKICAgZGVzY3JpYmVkIGluIHNlY3Rpb24gMjEgb2YgW1JGQzMzMTVdLAoK CgoKCk1hdHN1bW90bywgZXQgYWwuICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTksIDIwMTMgICAg ICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICBESENQdjYgQWRkcmVzcyBT ZWxlY3Rpb24gUG9saWN5IE9wdCAgICAgICAgIEp1bmUgMjAxMwoKCiAgIEFub3RoZXIgdGhyZWF0 IGlzIGFib3V0IHByaXZhY3kgY29uY2Vybi4gIEFzIGluIHRoZSBzZWN1cml0eQogICBjb25zaWRl cmF0aW9uIHNlY3Rpb24gb2YgW1JGQzY3MjRdLCBhdCBsZWFzdCBhIHBhcnQgb2YsIHRoZSBhZGRy ZXNzCiAgIHNlbGVjdGlvbiBwb2xpY3kgc3RvcmVkIGluIGEgaG9zdCBjYW4gYmUgbGVha2VkIGJ5 IGEgcGFja2V0IGZyb20gYQogICByZW1vdGUgaG9zdC4gIFRoaXMgaXNzdWUgd2lsbCBub3QgYmUg bW9kaWZpZWQgYnkgdGhlIGludHJvZHVjdGlvbiBvZgogICB0aGlzIG9wdGlvbiwgcmVnYXJkbGVz cyBvZiB3aGV0aGVyIHRoZSBob3N0IGlzIG11bHRpaG9tZWQgb3Igbm90LgoKNi4gIElBTkEgQ29u c2lkZXJhdGlvbnMKCiAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFzc2lnbiBvcHRpb24gY29kZXMg dG8gT1BUSU9OX0FERFJTRUwgYW5kCiAgIE9QVElPTl9BRERSU0VMX1RBQkxFIGZyb20gdGhlICJE SENQIE9wdGlvbiBDb2RlcyIgcmVnaXN0cnkgKGh0dHA6Ly8KICAgd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL2RoY3B2Ni1wYXJhbWV0ZXJzL2RoY3B2Ni1wYXJhbWV0ZXJzLnhtbCkuCgo3LiAgUmVm ZXJlbmNlcwoKNy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5l ciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAg ICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAg IFtSRkMzMzE1XSAgRHJvbXMsIFIuLCBCb3VuZCwgSi4sIFZvbHosIEIuLCBMZW1vbiwgVC4sIFBl cmtpbnMsIEMuLAogICAgICAgICAgICAgIGFuZCBNLiBDYXJuZXksICJEeW5hbWljIEhvc3QgQ29u ZmlndXJhdGlvbiBQcm90b2NvbCBmb3IKICAgICAgICAgICAgICBJUHY2IChESENQdjYpIiwgUkZD IDMzMTUsIEp1bHkgMjAwMy4KCiAgIFtSRkM2NzI0XSAgVGhhbGVyLCBELiwgRHJhdmVzLCBSLiwg TWF0c3Vtb3RvLCBBLiwgYW5kIFQuIENob3duLAogICAgICAgICAgICAgICJEZWZhdWx0IEFkZHJl c3MgU2VsZWN0aW9uIGZvciBJbnRlcm5ldCBQcm90b2NvbCBWZXJzaW9uIDYKICAgICAgICAgICAg ICAoSVB2NikiLCBSRkMgNjcyNCwgU2VwdGVtYmVyIDIwMTIuCgo3LjIuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzCgogICBbSS1ELmlldGYtNm1hbi1hZGRyLXNlbGVjdC1jb25zaWRlcmF0aW9uc10K ICAgICAgICAgICAgICBDaG93biwgVC4gYW5kIEEuIE1hdHN1bW90bywgIkNvbnNpZGVyYXRpb25z IGZvciBJUHY2CiAgICAgICAgICAgICAgQWRkcmVzcyBTZWxlY3Rpb24gUG9saWN5IENoYW5nZXMi LCBkcmFmdC1pZXRmLTZtYW4tYWRkci0KICAgICAgICAgICAgICBzZWxlY3QtY29uc2lkZXJhdGlv bnMtMDUgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBBcHJpbCAyMDEzLgoKICAgW1JGQzI0NjBdICBEZWVy aW5nLCBTLiBhbmQgUi4gSGluZGVuLCAiSW50ZXJuZXQgUHJvdG9jb2wsIFZlcnNpb24gNgogICAg ICAgICAgICAgIChJUHY2KSBTcGVjaWZpY2F0aW9uIiwgUkZDIDI0NjAsIERlY2VtYmVyIDE5OTgu CgogICBbUkZDMzQ4NF0gIERyYXZlcywgUi4sICJEZWZhdWx0IEFkZHJlc3MgU2VsZWN0aW9uIGZv ciBJbnRlcm5ldAogICAgICAgICAgICAgIFByb3RvY29sIHZlcnNpb24gNiAoSVB2NikiLCBSRkMg MzQ4NCwgRmVicnVhcnkgMjAwMy4KCiAgIFtSRkM0MjkxXSAgSGluZGVuLCBSLiBhbmQgUy4gRGVl cmluZywgIklQIFZlcnNpb24gNiBBZGRyZXNzaW5nCiAgICAgICAgICAgICAgQXJjaGl0ZWN0dXJl IiwgUkZDIDQyOTEsIEZlYnJ1YXJ5IDIwMDYuCgogICBbUkZDNDk0MV0gIE5hcnRlbiwgVC4sIERy YXZlcywgUi4sIGFuZCBTLiBLcmlzaG5hbiwgIlByaXZhY3kKICAgICAgICAgICAgICBFeHRlbnNp b25zIGZvciBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiBpbgogICAgICAgICAg ICAgIElQdjYiLCBSRkMgNDk0MSwgU2VwdGVtYmVyIDIwMDcuCgoKCgoKTWF0c3Vtb3RvLCBldCBh bC4gICAgICAgRXhwaXJlcyBEZWNlbWJlciAxOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDhd CgwKSW50ZXJuZXQtRHJhZnQgICAgIERIQ1B2NiBBZGRyZXNzIFNlbGVjdGlvbiBQb2xpY3kgT3B0 ICAgICAgICAgSnVuZSAyMDEzCgoKICAgW1JGQzUyMjBdICBNYXRzdW1vdG8sIEEuLCBGdWppc2Fr aSwgVC4sIEhpcm9taSwgUi4sIGFuZCBLLiBLYW5heWFtYSwKICAgICAgICAgICAgICAiUHJvYmxl bSBTdGF0ZW1lbnQgZm9yIERlZmF1bHQgQWRkcmVzcyBTZWxlY3Rpb24gaW4gTXVsdGktCiAgICAg ICAgICAgICAgUHJlZml4IEVudmlyb25tZW50czogT3BlcmF0aW9uYWwgSXNzdWVzIG9mIFJGQyAz NDg0CiAgICAgICAgICAgICAgRGVmYXVsdCBSdWxlcyIsIFJGQyA1MjIwLCBKdWx5IDIwMDguCgog ICBbUkZDNTIyMV0gIE1hdHN1bW90bywgQS4sIEZ1amlzYWtpLCBULiwgSGlyb21pLCBSLiwgYW5k IEsuIEthbmF5YW1hLAogICAgICAgICAgICAgICJSZXF1aXJlbWVudHMgZm9yIEFkZHJlc3MgU2Vs ZWN0aW9uIE1lY2hhbmlzbXMiLCBSRkMgNTIyMSwKICAgICAgICAgICAgICBKdWx5IDIwMDguCgpB cHBlbmRpeCBBLiAgQWNrbm93bGVkZ2VtZW50cwoKICAgQXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRo YW5rIHRvIERhdmUgVGhhbGVyLCBQZWtrYSBTYXZvbGEsIFJlbWkgRGVuaXMtCiAgIENvdXJtb250 LCBGcmFuY29pcy1YYXZpZXIgTGUgQmFpbCwgT2xlIFRyb2FuLCBCb2IgSGluZGVuLCBEbWl0cnkK ICAgQW5pcGtvLCBSYXkgSHVudGVyLCBSdWkgUGF1bG8sIEJyaWFuIEUgQ2FycGVudGVyLCBUb20g UGV0Y2gsIGFuZCB0aGUKICAgbWVtYmVycyBvZiA2bWFuJ3MgYWRkcmVzcyBzZWxlY3Rpb24gZGVz aWduIHRlYW0gZm9yIHRoZWlyIGludmFsdWFibGUKICAgY29udHJpYnV0aW9ucyB0byB0aGlzIGRv Y3VtZW50LgoKQXBwZW5kaXggQi4gIEV4YW1wbGVzCgogICBbUkZDNTIyMF0gZ2l2ZXMgc2V2ZXJh bCBjYXNlcyB3aGVyZSBhZGRyZXNzIHNlbGVjdGlvbiBwcm9ibGVtcwogICBoYXBwZW4uICBUaGlz IHNlY3Rpb24gY29udGFpbnMgc2V2ZXJhbCBleGFtcGxlcyBmb3Igc29sdmluZyB0aG9zZQogICBj YXNlcyBieSB1cGRhdGluZyBob3N0cycgcG9saWN5IHRhYmxlLgoKQi4xLiAgSW5ncmVzcyBGaWx0 ZXJpbmcgUHJvYmxlbQoKICAgSW4gdGhlIGNhc2UgZGVzY3JpYmVkIGluIDIuMS4yIGluIFtSRkM1 MjIwXSwgdGhlIGZvbGxvd2luZyBwb2xpY3kKICAgdGFibGUgc2hvdWxkIGJlIGRpc3RyaWJ1dGVk LCB3aGVuIFJvdXRlciBwZXJmb3JtcyBzdGF0aWMgcm91dGluZyBhbmQKICAgZGlyZWN0IHRoZSBk ZWZhdWx0IHJvdXRlIHRvIElTUDEgaW4gdGhpcyBGaWd1cmUgMi4gIEJ5IHB1dHRpbmcgdGhlCiAg IHNhbWUgbGFiZWwgdmFsdWUgdG8gYWxsIHRoZSBJUHY2IGFkZHJlc3Nlcyg6Oi8wKSBhbmQgdGhl IGxvY2FsCiAgIHN1Ym5ldCgyMDAxOmRiODoxMDAwOjE6Oi82NCksIGEgaG9zdCBwaWNrcyBhIHNv dXJjZSBhZGRyZXNzIGluIHRoaXMKICAgc3VibmV0IHRvIHNlbmQgYSBwYWNrZXQgdmlhIHRoZSBk ZWZhdWx0IHJvdXRlLgoKICAgICAgUHJlZml4ICAgICAgICBQcmVjZWRlbmNlIExhYmVsCiAgICAg IDo6MS8xMjggICAgICAgICAgICAgICA1MCAgICAgMAogICAgICA6Oi8wICAgICAgICAgICAgICAg ICAgNDAgICAgIDEKICAgICAgMjAwMTpkYjg6MTAwMDoxOjovNjQgIDQ1ICAgICAxCiAgICAgIDIw MDE6ZGI4OjgwMDA6MTo6LzY0ICA0NSAgICAxNAogICAgICA6OmZmZmY6MDowLzk2ICAgICAgICAg MzUgICAgIDQKICAgICAgMjAwMjo6LzE2ICAgICAgICAgICAgIDMwICAgICAyCiAgICAgIDIwMDE6 Oi8zMiAgICAgICAgICAgICAgNSAgICAgNQogICAgICBmYzAwOjovNyAgICAgICAgICAgICAgIDMg ICAgMTMKICAgICAgOjovOTYgICAgICAgICAgICAgICAgICAxICAgICAzCiAgICAgIGZlYzA6Oi8x MCAgICAgICAgICAgICAgMSAgICAxMQogICAgICAzZmZlOjovMTYgICAgICAgICAgICAgIDEgICAg MTIKCgpCLjIuICBIYWxmLUNsb3NlZCBOZXR3b3JrIFByb2JsZW0KCgoKCk1hdHN1bW90bywgZXQg YWwuICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA5 XQoMCkludGVybmV0LURyYWZ0ICAgICBESENQdjYgQWRkcmVzcyBTZWxlY3Rpb24gUG9saWN5IE9w dCAgICAgICAgIEp1bmUgMjAxMwoKCiAgIEluIHRoZSBjYXNlIGRlc2NyaWJlZCBpbiAyLjEuMyBp biBbUkZDNTIyMF0sIHRoZSBmb2xsb3dpbmcgcG9saWN5CiAgIHRhYmxlIHNob3VsZCBiZSBkaXN0 cmlidXRlZC4gIEJ5IHNwbGl0dGluZyB0aGUgY2xvc2VkIG5ldHdvcmsKICAgcHJlZml4KDIwMDE6 ZGI4OjgwMDA6Oi8zNikgZnJvbSBhbGwgdGhlIElQdjYgYWRkcmVzc2VzKDo6LzApIGFuZAogICBn aXZpbmcgZGlmZmVyZW50IGxhYmVscywgdGhlIGNsb3NlZCBuZXR3b3JrIHByZWZpeCB3aWxsIGJl IHVzZWQgb25seQogICB3aGVuIGRlc3RpbmVkIGZvciB0aGUgY2xvc2VkIG5ldHdvcmsuCgogICAg ICBQcmVmaXggICAgICAgIFByZWNlZGVuY2UgTGFiZWwKICAgICAgOjoxLzEyOCAgICAgICAgICAg ICAgIDUwICAgICAwCiAgICAgIDo6LzAgICAgICAgICAgICAgICAgICA0MCAgICAgMQogICAgICAy MDAxOmRiODo4MDAwOjovMzYgICAgNDUgICAgMTQKICAgICAgOjpmZmZmOjA6MC85NiAgICAgICAg IDM1ICAgICA0CiAgICAgIDIwMDI6Oi8xNiAgICAgICAgICAgICAzMCAgICAgMgogICAgICAyMDAx OjovMzIgICAgICAgICAgICAgIDUgICAgIDUKICAgICAgZmMwMDo6LzcgICAgICAgICAgICAgICAz ICAgIDEzCiAgICAgIDo6Lzk2ICAgICAgICAgICAgICAgICAgMSAgICAgMwogICAgICBmZWMwOjov MTAgICAgICAgICAgICAgIDEgICAgMTEKICAgICAgM2ZmZTo6LzE2ICAgICAgICAgICAgICAxICAg IDEyCgoKQi4zLiAgSVB2NCBvciBJUHY2IFByaW9yaXRpemF0aW9uCgogICBJbiB0aGUgY2FzZSBk ZXNjcmliZWQgaW4gMi4yLjEgaW4gW1JGQzUyMjBdLCB0aGUgZm9sbG93aW5nIHBvbGljeQogICB0 YWJsZSBzaG91bGQgYmUgZGlzdHJpYnV0ZWQgdG8gcHJpb3JpdGl6ZSBJUHY2LiAgVGhpcyBjYXNl IGlzIGFsc28KICAgZGVzY3JpYmVkIGluIFtSRkM2NzI0XQoKICAgICAgUHJlZml4ICAgICAgICBQ cmVjZWRlbmNlIExhYmVsCiAgICAgIDo6MS8xMjggICAgICAgICAgICAgICA1MCAgICAgMAogICAg ICA6Oi8wICAgICAgICAgICAgICAgICAgNDAgICAgIDEKICAgICAgOjpmZmZmOjA6MC85NiAgICAg ICAgMTAwICAgICA0CiAgICAgIDIwMDI6Oi8xNiAgICAgICAgICAgICAzMCAgICAgMgogICAgICAy MDAxOjovMzIgICAgICAgICAgICAgIDUgICAgIDUKICAgICAgZmMwMDo6LzcgICAgICAgICAgICAg ICAzICAgIDEzCiAgICAgIDo6Lzk2ICAgICAgICAgICAgICAgICAgMSAgICAgMwogICAgICBmZWMw OjovMTAgICAgICAgICAgICAgIDEgICAgMTEKICAgICAgM2ZmZTo6LzE2ICAgICAgICAgICAgICAx ICAgIDEyCgoKQi40LiAgVUxBIG9yIEdsb2JhbCBQcmlvcml0aXphdGlvbgoKICAgSW4gdGhlIGNh c2UgZGVzY3JpYmVkIGluIDIuMi4zIGluIFtSRkM1MjIwXSwgdGhlIGZvbGxvd2luZyBwb2xpY3kK ICAgdGFibGUgc2hvdWxkIGJlIGRpc3RyaWJ1dGVkLCBvciBBdXRvbWF0aWMgUm93IEFkZGl0aW9u IGZsYWcgc2hvdWxkIGJlCiAgIHNldCB0byAxLiAgQnkgc3BsaXR0aW5nIHRoZSBVTEEgaW4gdGhp cyBzaXRlIChmYzEyOjM0NTY6Nzg5YTo6LzQ4KQogICBmcm9tIGFsbCB0aGUgSVB2NiBhZGRyZXNz ZXMoOjovMCkgYW5kIGdpdmluZyBoaWdoZXIgcHJlY2VuZGVuY2UsIHRoZQogICBVTEEgd2lsbCBi ZSB1c2VkIHRvIGNvbm5lY3QgdG8gc2VydmVycyBpbiB0aGlzIHNpdGUuCgogICAgICBQcmVmaXgg ICAgICAgIFByZWNlZGVuY2UgTGFiZWwKICAgICAgOjoxLzEyOCAgICAgICAgICAgICAgIDUwICAg ICAwCiAgICAgIDo6LzAgICAgICAgICAgICAgICAgICA0MCAgICAgMQoKCgpNYXRzdW1vdG8sIGV0 IGFsLiAgICAgICBFeHBpcmVzIERlY2VtYmVyIDE5LCAyMDEzICAgICAgICAgICAgICBbUGFnZSAx MF0KDApJbnRlcm5ldC1EcmFmdCAgICAgREhDUHY2IEFkZHJlc3MgU2VsZWN0aW9uIFBvbGljeSBP cHQgICAgICAgICBKdW5lIDIwMTMKCgogICAgICBmYzEyOjM0NTY6Nzg5YTo6LzQ4ICAgNDUgICAg MTQKICAgICAgOjpmZmZmOjA6MC85NiAgICAgICAgIDM1ICAgICA0CiAgICAgIDIwMDI6Oi8xNiAg ICAgICAgICAgICAzMCAgICAgMgogICAgICAyMDAxOjovMzIgICAgICAgICAgICAgIDUgICAgIDUK ICAgICAgZmMwMDo6LzcgICAgICAgICAgICAgICAzICAgIDEzCiAgICAgIDo6Lzk2ICAgICAgICAg ICAgICAgICAgMSAgICAgMwogICAgICBmZWMwOjovMTAgICAgICAgICAgICAgIDEgICAgMTEKICAg ICAgM2ZmZTo6LzE2ICAgICAgICAgICAgICAxICAgIDEyCgoKQXV0aG9ycycgQWRkcmVzc2VzCgog ICBBcmlmdW1pIE1hdHN1bW90bwogICBOVFQgTlQgTGFiCiAgIDMtOS0xMSBNaWRvcmktQ2hvCiAg IE11c2FzaGluby1zaGksIFRva3lvICAxODAtODU4NQogICBKYXBhbgoKICAgUGhvbmU6ICs4MSA0 MjIgNTkgMzMzNAogICBFbWFpbDogYXJpZnVtaUBudHR2Ni5uZXQKCgogICBUb21vaGlybyBGdWpp c2FraQogICBOVFQgTlQgTGFiCiAgIDMtOS0xMSBNaWRvcmktQ2hvCiAgIE11c2FzaGluby1zaGks IFRva3lvICAxODAtODU4NQogICBKYXBhbgoKICAgUGhvbmU6ICs4MSA0MjIgNTkgNzM1MQogICBF bWFpbDogZnVqaXNha2lAbnR0djYubmV0CgoKICAgVGltIENob3duCiAgIFVuaXZlcnNpdHkgb2Yg U291dGhhbXB0b24KICAgU291dGhhbXB0b24sIEhhbXBzaGlyZSAgU08xNyAxQkoKICAgVW5pdGVk IEtpbmdkb20KCiAgIEVtYWlsOiB0amNAZWNzLnNvdG9uLmFjLnVrCgoKCgoKCgoKCgoKCgpNYXRz dW1vdG8sIGV0IGFsLiAgICAgICBFeHBpcmVzIERlY2VtYmVyIDE5LCAyMDEzICAgICAgICAgICAg ICBbUGFnZSAxMV0K --bcaec520eacd5ec59604df57e280-- From derek@ihtfp.com Mon Jun 17 13:16:08 2013 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 DC1F921F938E; Mon, 17 Jun 2013 13:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl6Zi88+stgA; Mon, 17 Jun 2013 13:16:04 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id AFC6521F9962; Mon, 17 Jun 2013 13:16:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C466F260248; Mon, 17 Jun 2013 16:16:02 -0400 (EDT) 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 28711-01; Mon, 17 Jun 2013 16:15:58 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [12.208.167.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 1C9A226023C; Mon, 17 Jun 2013 16:15:57 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id r5HKFoKj031843; Mon, 17 Jun 2013 16:15:50 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Mon, 17 Jun 2013 16:15:50 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: peter@akayla.com, pkix-chairs@tools.ietf.org, dharkins@arubanetworks.com, pritikin@cisco.com Subject: [secdir] sec-dir review of draft-ietf-pkix-est-07.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, 17 Jun 2013 20:16:09 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificate(s). It also supports client-generated public/ private key pairs as well as key pairs generated by the CA. The document claims that trust anchor distribution is out of scope, and continues on that authenticity cannot be inferred until an out-of-band, non-specified mechinsm is used to verify. This just seems like it's kicking the can down the road to the next protocol that would need to define how to securely distribute the authentication information. If you have to preconfigure then why not just leverage that existing preconfiguration to distribute the certificates? Even section 2.2 continues with this; it assumes a pre-distributed authentication credential (or leverages a user's existing credential). For the user credential case there's still a missing trust link between the user and the target of the new certificate. For example, if you're trying to issue a machine (device?) certificate based on a user credential then all the EST server can intuit is that the user is requesting it but there is no authentication tying that user to the target device; you're still taking a leap of faith which would need to be audited after the fact. Certificate renewal, (e.g. leveraging an existing certificate) has already been solved by e.g. SCEP and other protocols. In 2.6, the additional CSR attributes are non-verifiable data. E.g., if a client puts a MAC address into its CSR, there is no way for the EST server or CA to validate that input. The client can easily insert any data it wants into that request, which can lead to MAC stealing or other impersonation attacks. The CA should never put any normative information into the certificate that it cannot validate from a trusted source. In 3.3.2, if the EST client already has a certificate with which it can athenticate then why would it need to enroll? It's already enrolled; the only interesting problem (IMHO) at that point is renewal. In short, I'm not sure I would call this "Enrollment" as opposed to a way to leverage an existing authentication mechanism and turn it into a certificate. Perhaps that is your definition of enrollment? In essense it just feels like SCEP, redone using REST. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From bew@cisco.com Mon Jun 17 16:34:46 2013 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 DA10321E804B; Mon, 17 Jun 2013 16:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfYX9qhRXjPB; Mon, 17 Jun 2013 16:34:40 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 51FCA21F9E63; Mon, 17 Jun 2013 16:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1922; q=dns/txt; s=iport; t=1371512080; x=1372721680; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=E3qGuq0QktksxbH5xiYvBOj/mv46Uwjd/MxIk1kNVdQ=; b=h56E1zYltQ3f2zTJlCjvVibVqH+cSMuDBajUUJw8Vbi1X66+VDEJQwLb MK6el5bjo1E7S2IHDB+grUs2ysT8ao+eFJKTVSgg868D1X/vLvhCOPCsW vG2ID+yW5KMgyav0AuQh5z8OEQB1pS3PnR7g+q0w0/TargBhgd9Nr7bkG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFABCcv1GrRDoI/2dsb2JhbABbgwm/fX4WdIJkP4E+AYgfAbpWj0eDBmEDiSCOIZFDgy8 X-IronPort-AV: E=Sophos;i="4.87,884,1363132800"; d="scan'208";a="83685241" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 17 Jun 2013 23:34:39 +0000 Received: from dhcp-128-107-147-43.cisco.com (dhcp-128-107-147-43.cisco.com [128.107.147.43]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5HNYclV029592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 23:34:38 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2013 16:34:38 -0700 Message-Id: <20FBAD75-A2FC-4E2A-BB9B-3D8A2931FC5B@cisco.com> To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-payload-vp8.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-payload-vp8-08 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, 17 Jun 2013 23:34:46 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document describes an RTP payload specification applicable to the = transmission of video streams encoded using the VP8 video codec defined = in RFC 6386. It defines how the RTP header is used, and describes the = format of a VP8 payload including sender and receiver semantics. The Security Considerations document points to the Security = Considerations of RFC 3550 (RTP), which seems appropriate since the = codec fits entirely within the RTP framework. It does specifically call = out protections that should be applied to the RTP packets, and notes = that there a number of application-specific mechanisms that can provide = those protections. I just have a couple minor comments/questions on this = section. 1. Unless the SRTP recommendation in lower case was a WG consensus item = I would suggest using upper-case RECOMMENDED to better convey the = importance of protecting the RTP traffic. 2. The penultimate sentence makes a claim about the payload format being = "unlikely to pose a denial-of-service threat due to the receipt of = pathological data." I'm not sure what threat this is describing. If one = is worried about a denial-of-service threat then the packet should be = integrity protected and include a replay protection method (e.g., using = SRTP). A non-key holder (e.g., man-in-the-middle) will not be able to = create a correctly formed protected data packet so the denial-of-service = properties of the data itself should be moot. Is there another threat = here that I'm missing that makes this worth mentioning? Brian= From kwiereng@cisco.com Tue Jun 18 01:57:11 2013 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 AF3C921F9DAC; Tue, 18 Jun 2013 01:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVwVQ1bcjqU2; Tue, 18 Jun 2013 01:57:06 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0E59221F9D05; Tue, 18 Jun 2013 01:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1786; q=dns/txt; s=iport; t=1371545826; x=1372755426; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wW8JAURf937t+ChtUO9vn2up/re+egX8DMTwmzU5tRg=; b=B4flEaaikW+PRimNWmu7/K8oJzkgTcPoAiYHWYTkmZPr54NSObiFSxC4 6zvsLnWfpV4KDqytCZBE5cc2JYYp/+w0DqZpVLwtL3IJlef0BBds21lnc bcZOu7eykyQnxovGTJsamV9I3L6mf8ROagxDjkD1qlEto/H7580MdjzGL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAIYfwFGtJXG//2dsb2JhbABZgwl6vwh+FnSCJQEEOlEBKhRCJwQBGgyHerpSjg2BB4M3YQOpBIMPgWhA X-IronPort-AV: E=Sophos;i="4.87,887,1363132800"; d="scan'208";a="224113514" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jun 2013 08:57:05 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5I8v53i010239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 08:57:05 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.172]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 03:57:05 -0500 From: "Klaas Wierenga (kwiereng)" To: "draft-ietf-rmt-sec-discussion.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-rmt-sec-discussion-08 Thread-Index: AQHObAHOl4S6lR2FLUaMd9vNT8HF9w== Date: Tue, 18 Jun 2013 08:57:05 +0000 Message-ID: <7E1636E02F313F4BA69A428B314B77C708BD6892@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.84] 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-rmt-sec-discussion-08 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, 18 Jun 2013 08:57:11 -0000 Hi, 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. This document describes general security considerations for Reliable Multicast Transport (RMT) building blocks and protocols. However the discus= sion is not limited to RMT per se but is rather a discussion in general abo= ut security issues that may influence the overall security of RMT. I have one major issue with this draft, I interpret the discussion sort of = as a lengthy security considerations section for RMT. And while I applaud t= he effort that has gone into producing this draft I don't understand why yo= u have not looked at RFC3552 (guidelines for writing security consideration= s) and take that as the starting point of your discussion. It appears to me= that that would have been a more rigorous approach (for example, it is unc= lear to me why you have a discussion about IPSec, but not about TLS, to nam= e an example). It would also have meant that you could reuse much of the te= xt there or simply refer to it. We now end up with 2 documents that write a= bout the same sort of issues but in different wording and in the case of th= is draft, far less scrutiny from the security community. In the current inc= antation I don't support forwarding the document, either it will have to be= more rigorous (but still with the concern about doubling the work) or shou= ld refer to RFC3552 and just discuss the RMT specific issues and implementa= tion choices. Hope this helps, Klaas From kent@bbn.com Tue Jun 18 08:51:00 2013 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 78E0121F9955 for ; Tue, 18 Jun 2013 08:51:00 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m+CYkI5liIT for ; Tue, 18 Jun 2013 08:50:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB8521F9815 for ; Tue, 18 Jun 2013 08:50:45 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49476) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UoyB5-000Dvc-GO; Tue, 18 Jun 2013 11:50:39 -0400 Message-ID: <51C081CF.6060208@bbn.com> Date: Tue, 18 Jun 2013 11:50:39 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Black, David" References: <507F45BE.2040900@bbn.com> <8D3D17ACE214DC429325B2B98F3AE7120E04B01F@MX15A.corp.emc.com> <50983EB5.2010501@bbn.com> <8D3D17ACE214DC429325B2B98F3AE712980CA080@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980CA080@MX15A.corp.emc.com> Content-Type: multipart/alternative; boundary="------------080706070301050905020006" Cc: "mkosjc@gmail.com" , Mallikarjun Chadalapaka , "ttalpey@microsoft.com" , secdir , "nezhinsky@gmail.com" , "alexandern@mellanox.com" , "spencerdawkins.ietf@gmail.com" , "martin.stiemerling@neclab.eu" Subject: Re: [secdir] draft-ietf-storm-iser and IPsec version requirements 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, 18 Jun 2013 15:51:00 -0000 This is a multi-part message in MIME format. --------------080706070301050905020006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David, Thanks for the followup note. I've been on vacation, so I just read your message. I assume everything is OK now. Steve ---- On 6/6/13 7:03 PM, Black, David wrote: > > Steve, > > This is a much delayed follow-up on the IPsec version concern noted > > in the secdir review of draft-ietf-storm-iser found. After further > > investigation, it turns out that the iSER draft implicitly used > > different sets of IPsec requirements for the iSCSI vs. RDMA layers > > of the iSER protocol stack. That was not a good approach, as the > > protocol stack is iSER/RDMA/TCP/IP, so a single common IPsec > > implementation is likely to be used for both iSER and RDMA, but > > doing the proverbial "right thing" has taken a while. > > Getting to a single common set of IPsec requirements required a new > > draft. That new storm WG draft has just been posted; it updates > > RFC 3723's IPsec requirements to encompass IPsec v3 (4301 series RFCs). > > That update covers iSCSI, iSER, the iWARP RDMA protocols, and all other > > protocols that use the IPsec requirements for IP Storage in RFC 3723: > > http://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update/ > > Yaron Sheffer's prompt review of that draft (thank you!) found a > > few minor problems, which will be addressed in a -01 version to be > > posted in the next few days. > > The just-posted -14 version of the iSER draft contains a normative > > reference to that ipsec-ips-update draft, with the result that the IPsec > > requirements are now consistent and include IPsec v3 (4301 series RFCs). > > Everything else noted in the secdir review has been addressed in that > > new -14 version. > > Thanks, > --David > > *From:*Stephen Kent [mailto:kent@bbn.com] > *Sent:* Monday, November 05, 2012 5:33 PM > *To:* Black, David > *Cc:* mkosjc@gmail.com; alexandern@mellanox.com; nezhinsky@gmail.com; > secdir; wes@mti-systems.com; martin.stiemerling@neclab.eu; > ttalpey@microsoft.com; Mallikarjun Chadalapaka; Steve Kent > *Subject:* Re: secdir review of draft-ietf-storm-iser-12.txt > > 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 > --------------080706070301050905020006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David,

Thanks for the followup note. I've been on vacation, so I just read your message. 
I assume everything is OK now.

Steve
----
On 6/6/13 7:03 PM, Black, David wrote:

Steve,

 

This is a much delayed follow-up on the IPsec version concern noted

in the secdir review of draft-ietf-storm-iser found.  After further

investigation, it turns out that the iSER draft implicitly used

different sets of IPsec requirements for the iSCSI vs. RDMA layers

of the iSER protocol stack.  That was not a good approach, as the

protocol stack is iSER/RDMA/TCP/IP, so a single common IPsec

implementation is likely to be used for both iSER and RDMA, but

doing the proverbial “right thing” has taken a while.

 

Getting to a single common set of IPsec requirements required a new

draft.  That new storm WG draft has just been posted; it updates

RFC 3723’s IPsec requirements to encompass IPsec v3 (4301 series RFCs).

That update covers iSCSI, iSER, the iWARP RDMA protocols, and all other

protocols that use the IPsec requirements for IP Storage in RFC 3723:

 

http://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update/

 

Yaron Sheffer’s prompt review of that draft (thank you!) found a

few minor problems, which will be addressed in a -01 version to be

posted in the next few days.

 

The just-posted -14 version of the iSER draft contains a normative

reference to that ipsec-ips-update draft, with the result that the IPsec

requirements are now consistent and include IPsec v3 (4301 series RFCs).

Everything else noted in the secdir review has been addressed in that

new -14 version.

 

Thanks,
--David

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Monday, November 05, 2012 5:33 PM
To: Black, David
Cc: mkosjc@gmail.com; alexandern@mellanox.com; nezhinsky@gmail.com; secdir; wes@mti-systems.com; martin.stiemerling@neclab.eu; ttalpey@microsoft.com; Mallikarjun Chadalapaka; Steve Kent
Subject: Re: secdir review of draft-ietf-storm-iser-12.txt

 

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


--------------080706070301050905020006-- From tlyu@mit.edu Wed Jun 19 20:58:34 2013 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 5226B11E80F4; Wed, 19 Jun 2013 20:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxow8ws1GZEr; Wed, 19 Jun 2013 20:58:26 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62311E80F6; Wed, 19 Jun 2013 20:58:25 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-12-51c27de1f28c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A2.AE.02387.1ED72C15; Wed, 19 Jun 2013 23:58:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r5K3wOvj005984; Wed, 19 Jun 2013 23:58:24 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r5K3wLL3020491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 23:58:23 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r5K3wL4j024735; Wed, 19 Jun 2013 23:58:21 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org From: Tom Yu Date: Wed, 19 Jun 2013 23:58:21 -0400 Message-ID: Lines: 30 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixG6nrvuw9lCgwduLihY7urQtZvyZyGzx YeFDFgdmjyVLfjJ5fLn8mS2AKYrLJiU1J7MstUjfLoEro+/iZfaCPTwVlz6eYWlgXMbVxcjB ISFgIjHpc3YXIyeQKSZx4d56ti5GLg4hgX2MEltOt7CBJIQENjJKrF8eDZE4xyRxYtdqFgin i1FiystL7CBVIgLxEr86+8BsYQEbiS/X5rKCbGATkJY4urgMJMwioCrxbW4LO0iYV8BC4sDX ApAwjwCnxKOzl5lAbF4BQYmTM5+wgNjMAloSN/69ZJrAyDcLSWoWktQCRqZVjLIpuVW6uYmZ OcWpybrFyYl5ealFuiZ6uZkleqkppZsYQUHGKcm/g/HbQaVDjAIcjEo8vBqXDwYKsSaWFVfm HmKU5GBSEuW9WHEoUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb0IqUI43JbGyKrUoHyYlzcGi JM4rdmtnoJBAemJJanZqakFqEUxWhoNDSYL3TQ1Qo2BRanpqRVpmTglCmomDE2Q4D9DwTyA1 vMUFibnFmekQ+VOMilLivAdBEgIgiYzSPLheWBJ4xSgO9Iow70+QKh5gAoHrfgU0mAlosND3 fSCDSxIRUlINjGy3HJdnzomRFPgs8uPplkrnwOwFrv+dpij7TrUqNPvnyLSl0lemTPTqgZpX W74eOfHRZMNC7SDuV6tETQWtN4Uan/m684/bqSqZjTLxjDkNUY0REj9P5mR0WnxQMuORUBc5 m7raJMT/hM7/WaqJvKaT43ZNUe1cfeVLgV/4361ffu76LsrEq8RSnJFoqMVcVJwIAAobFS/d AgAA Subject: [secdir] secdir review of draft-ietf-rtgwg-cl-requirement-10 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, 20 Jun 2013 03:58:34 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document states many requirements on properties of proposed solutions, but it seems that none of these requirements is a security requirement. If nodes need to send new information that existing routing or signaling protocols do not currently send, what level of protection does that information require? In the Security Considerations section, I'm not sure what the intent is in using the phrasing "man-in-the-middle confidentiality breach". I generally consider "man-in-the-middle" to mean an active attacker (one that can receive, suppress, modify, and transmit arbitrary data); this type of attacker primarily has consequences for integrity. (An active attacker could also compromise the confidentiality of a channel that is secure against passive attackers). A passive attack is often sufficient to compromise confidentiality, especially if a protocol sends information in the clear. What scope of compromise does "provider breach" designate? Editorial: This document uses many acronyms without expanding them -- almost all of them, from what I can see. Some of the more prominent ones include DSCP, LDP, LSP, PW, RSVP-TE. Arguably terms such as MPLS, VLAN, and VPN count as well-known acronyms in the IETF community. From n@arifumi.net Wed Jun 19 21:31:29 2013 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 A52C221E80A3 for ; Wed, 19 Jun 2013 21:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZv7S419VeNh for ; Wed, 19 Jun 2013 21:31:28 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3311E80F7 for ; Wed, 19 Jun 2013 21:31:28 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so5754167pbb.6 for ; Wed, 19 Jun 2013 21:31:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=Xj/PFEToUh7gINfjFOVaExjMVyPc1brH7TV73bVGCIw=; b=lJkxpt2s3vAqmLpo20iYLk//OtS9tGXFm1zAbj3jmcuMW/HDFvU8IVA+pTj7bkGAau 0KikHAXHw3ex3XULsZMzmxfrPvRBdn5LszjdLpBhKhfKhGluDymA3zATAwLlSUt7fot6 sCx8fJEHHkbTah0XQMAqTgLPsVuqZAmXvOevLeUGr+fnL3XH/R9iD1mW2gJiW+t/VVAZ qxkcDCXEmCFhvPtmXXjy3O7XbikTajiwzqVW0nWkO7IZmF0m3tuHbs/UDNrLxR3G+a1M gxSNbJGrCHT7oFLe6uOgBIcJkq8AU4FSTfFS3VqX6KJkYvOoQkY1cTRkuaWp60aKiT1s ZeUw== MIME-Version: 1.0 X-Received: by 10.66.27.172 with SMTP id u12mr9530016pag.209.1371702688154; Wed, 19 Jun 2013 21:31:28 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.194.198 with HTTP; Wed, 19 Jun 2013 21:31:28 -0700 (PDT) X-Originating-IP: [2001:fa8:1010:0:20d5:98e0:2752:e5c0] In-Reply-To: References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> <5F8FAF51-833A-4C75-9FFC-BE17ADF27994@employees.org> <5ffd0e5973e67c773b8ce3d345010c8f.squirrel@www.trepanning.net> <2B1856F1-537D-4268-A104-BDC180A4EC54@employees.org> Date: Thu, 20 Jun 2013 13:31:28 +0900 X-Google-Sender-Auth: oqGFuRIP31PdTGZcpNNSYN8aa5Y Message-ID: From: Arifumi Matsumoto To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=bcaec5299d297719d604df8e6bb4 X-Gm-Message-State: ALoCoQlCvQqzyfMHYh9z1X7kaQnryNQ5PSHK28Y/Kwko0fEW5LtESltOTXYMnUZfyBGI3M+dL7xl Cc: secdir@ietf.org, "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , draft-ietf-6man-rfc3484bis@tools.ietf.org, Ole Troan , iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 20 Jun 2013 04:31:29 -0000 --bcaec5299d297719d604df8e6bb4 Content-Type: text/plain; charset=ISO-8859-1 Dan, this is diff from the previous version, as requested by Ole. https://bitbucket.org/arifumi/draft-addr-select-opt/diff/draft-ietf-6man- addr-select-opt.txt?diff2=2e7efc634b5a&at=master Thanks. 2013/6/17 Arifumi Matsumoto > I attached a rev candidate. > Hope this solves the issues pointed by Dan. > > Thank you very much. > > > 2013/6/13 Ole Troan > >> Dan, >> >> > Yes, I am fine with Arifumi's clarification. Thanks. >> >> splendid, thanks for the help! >> >> Best regards, >> Ole >> >> >> Dan, >> >> >> >> apologies for the delay, I discussed this directly with Arifumi, and I >> >> hope his latest message clarifies the issue. >> >> >> >> to rephrase in my words; >> >> OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to >> disable >> >> automatic row addition) >> >> and to carry policy table options. >> >> the A-flag is a hint to the host to disable automatic row addition. >> >> if OPTION_ADDRSEL contains policy table options the A-flag is >> redundant. >> >> (as policy table options and the A-flag are incompatible). >> >> >> >> if you are fine with this, I will ask the authors to update the draft >> to >> >> make this behaviour explicit. >> >> >> >> Best regards, >> >> Ole >> >> >> >>>> let me chime in as the document shepherd. >> >>>> (thank you very much for the thorough comments by the way). >> >>>> >> >>>>> For instance, while I think I understand the policy override of RFC >> >>>>> 6724, having the Automatic Row Additions Flag be part of the address >> >>>>> selection options seems problematic. If it is set to zero, then what >> >>>>> are >> >>>>> the semantics of such a message? "Here's an address selection option >> >>>>> but don't you dare use it!"? What is the point? Me, as a node, can >> >>>>> have >> >>>>> this as part of my policy state which would allow me to ignore such >> >>>>> an update but to have the bit be part of the option to update does >> >>>>> not seem to make much sense. The semantics of the message needs >> >>>>> to be explained much more clearly, or the bit needs to be removed >> >>>>> from the message. >> >>>> >> >>>> my reading of the meaning of the A flag is a little different. (I >> have >> >>>> cc'ed the authors of rfc6724 for confirmation.) >> >>>> >> >>>> an implementation of RFC6724 may automatically add entries in the >> >>>> policy >> >>>> table based on addresses configured on the node. >> >>>> e.g. the node has an interface with a ULA address. >> >>>> >> >>>> RFC6724 also says: >> >>>> An implementation SHOULD provide a means (the Automatic Row >> Additions >> >>>> flag) for an administrator to disable >> >>>> automatic row additions. >> >>> >> >>> That makes perfect sense. A client implementation SHOULD provide a >> >>> means to disable automatic row additions. So it has some knob that can >> >>> be turned on or off locally that would allow for update of its policy >> >>> table >> >>> by receiving policy options (enable) or forbid received policy options >> >>> from >> >>> updating the policy table (disable). >> >>> >> >>>> the A-flag in draft-ietf-6man-addr-select-opt provides the means. >> >>> >> >>> So this is where I'm confused. The sender of the policy option should >> >>> not have the ability to control the knob that an implementation added >> >>> locally to satisfy RFC 6724. If a client implementation sets its knob >> to >> >>> "disable" then it forbids policy option updates to its policy table. >> It >> >>> shouldn't inspect the received option update to decide whether it >> >>> should override the setting of its local knob. >> >>> >> >>> This seems like a security issue to me. There's a reason why an >> >>> implementation would choose to disable updates of its policy table >> >>> and allowing the sender of policy updates to override that seems >> >>> wrong. >> >>> >> >>>> it does not affect the policy entries that is contained in the DHCP >> >>>> option. >> >>>> the A-flag only affects the RFC6724 behaviour of adding entries based >> >>>> on >> >>>> address configuration on the node. >> >>> >> >>> Again, according to the draft a message can be received by a client >> >>> implementation that provides policy update options to its policy table >> >>> with semantics of "you SHOULD NOT use these!" So what is the point >> >>> of sending that message? Why not just refrain from sending the message >> >>> if that's what the message is? >> >>> >> >>> Would you ever tell someone, "disregard what I am about to tell you"? >> I >> >>> can't see why. And that's what the semantics of this message seem to >> be. >> >> >> >> >> >> >> >> >> > >> >> > --bcaec5299d297719d604df8e6bb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,

this is diff from the previo= us version, as requested by Ole.

Thanks.



2013/6/17 = Arifumi Matsumoto <arifumi@nttv6.net>
I attached a rev candi= date.
Hope this solves the issues pointed by Dan.

<= /div>
Thank you very much.


2013/6/13 O= le Troan <otroan@employees.org>
Dan,

> =A0Yes, I am fine with Arifumi's clarification. Thanks.

splendid, thanks for the help!

Best regards,
Ole

>> Dan,
>>
>> apologies for the delay, I discussed this directly with Arifumi, a= nd I
>> hope his latest message clarifies the issue.
>>
>> to rephrase in my words;
>> OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to = disable
>> automatic row addition)
>> and to carry policy table options.
>> the A-flag is a hint to the host to disable automatic row addition= .
>> if OPTION_ADDRSEL contains policy table options the A-flag is redu= ndant.
>> (as policy table options and the A-flag are incompatible).
>>
>> if you are fine with this, I will ask the authors to update the dr= aft to
>> make this behaviour explicit.
>>
>> Best regards,
>> Ole
>>
>>>> let me chime in as the document shepherd.
>>>> (thank you very much for the thorough comments by the way)= .
>>>>
>>>>> For instance, while I think I understand the policy ov= erride of RFC
>>>>> 6724, having the Automatic Row Additions Flag be part = of the address
>>>>> selection options seems problematic. If it is set to z= ero, then what
>>>>> are
>>>>> the semantics of such a message? "Here's an a= ddress selection option
>>>>> but don't you dare use it!"? What is the poin= t? Me, as a node, can
>>>>> have
>>>>> this as part of my policy state which would allow me t= o ignore such
>>>>> an update but to have the bit be part of the option to= update does
>>>>> not seem to make much sense. The semantics of the mess= age needs
>>>>> to be explained much more clearly, or the bit needs to= be removed
>>>>> from the message.
>>>>
>>>> my reading of the meaning of the A flag is a little differ= ent. (I have
>>>> cc'ed the authors of rfc6724 for confirmation.)
>>>>
>>>> an implementation of RFC6724 may automatically add entries= in the
>>>> policy
>>>> table based on addresses configured on the node.
>>>> e.g. the node has an interface with a ULA address.
>>>>
>>>> RFC6724 also says:
>>>> =A0An implementation SHOULD provide a means (the Automatic= Row Additions
>>>> flag) for an administrator to disable
>>>> =A0automatic row additions.
>>>
>>> That makes perfect sense. A client implementation SHOULD provi= de a
>>> means to disable automatic row additions. So it has some knob = that can
>>> be turned on or off locally that would allow for update of its= policy
>>> table
>>> by receiving policy options (enable) or forbid received policy= options
>>> from
>>> updating the policy table (disable).
>>>
>>>> the A-flag in draft-ietf-6man-addr-select-opt provides the= means.
>>>
>>> So this is where I'm confused. The sender of the policy op= tion should
>>> not have the ability to control the knob that an implementatio= n added
>>> locally to satisfy RFC 6724. If a client implementation sets i= ts knob to
>>> "disable" then it forbids policy option updates to i= ts policy table. It
>>> shouldn't inspect the received option update to decide whe= ther it
>>> should override the setting of its local knob.
>>>
>>> This seems like a security issue to me. There's a reason w= hy an
>>> implementation would choose to disable updates of its policy t= able
>>> and allowing the sender of policy updates to override that see= ms
>>> wrong.
>>>
>>>> it does not affect the policy entries that is contained in= the DHCP
>>>> option.
>>>> the A-flag only affects the RFC6724 behaviour of adding en= tries based
>>>> on
>>>> address configuration on the node.
>>>
>>> Again, according to the draft a message can be received by a c= lient
>>> implementation that provides policy update options to its poli= cy table
>>> with semantics of "you SHOULD NOT use these!" So wha= t is the point
>>> of sending that message? Why not just refrain from sending the= message
>>> if that's what the message is?
>>>
>>> Would you ever tell someone, "disregard what I am about t= o tell you"? I
>>> can't see why. And that's what the semantics of this m= essage seem to be.
>>
>>
>>
>>
>



--bcaec5299d297719d604df8e6bb4-- From kivinen@iki.fi Thu Jun 20 04:12:33 2013 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 C330A21F9A4A for ; Thu, 20 Jun 2013 04:12:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnCVtfDog8d0 for ; Thu, 20 Jun 2013 04:12:33 -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 D55F821F9A48 for ; Thu, 20 Jun 2013 04:12:31 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r5KBCRGi007567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 20 Jun 2013 14:12:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r5KBCRNB011202; Thu, 20 Jun 2013 14:12:27 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20930.58266.923840.594765@fireball.kivinen.iki.fi> Date: Thu, 20 Jun 2013 14:12:26 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 24.3.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, 20 Jun 2013 11:12:33 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Leif Johansson is next in the rotation. For telechat 2013-06-27 Reviewer LC end Draft Shawn Emery T 2013-05-31 draft-ietf-xrblock-rtcp-xr-jb-12 Hilarie Orman T 2013-06-25 draft-thornburgh-adobe-rtmfp-07 Joe Salowey T 2013-06-06 draft-ietf-l3vpn-virtual-hub-06 Carl Wallace T 2013-06-21 draft-ietf-ipsecme-ad-vpn-problem-07 David Waltermire T 2013-06-19 draft-ietf-nvo3-overlay-problem-statement-03 For telechat 2013-07-11 Tobias Gondrom T 2013-06-27 draft-ietf-appsawg-rfc5451bis-07 Warren Kumari T 2013-01-21 draft-ietf-lisp-mib-11 Sam Weiler T 2013-06-19 draft-ietf-ospf-manet-single-hop-mdr-03 Brian Weis TR2013-06-28 draft-ietf-ipfix-protocol-rfc5101bis-08 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland - draft-ietf-httpbis-p5-range-22 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Donald Eastlake 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Phillip Hallam-Baker 2013-06-27 draft-ietf-l2vpn-pbb-vpls-pe-model-07 Steve Hanna 2013-06-27 draft-ietf-manet-rfc6622-bis-02 Dan Harkins 2013-07-03 draft-ietf-multimob-pmipv6-ropt-06 David Harrington 2013-07-01 draft-ietf-straw-b2bua-taxonomy-02 Sam Hartman 2013-07-01 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Paul Hoffman 2013-07-16 draft-ivov-xmpp-cusax-06 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Julien Laganier - draft-ietf-avtcore-rtp-security-options-03 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Sandy Murphy 2013-07-17 draft-jabley-dnsext-eui48-eui64-rrtypes-05 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-11 Ondrej Sury 2013-06-17 draft-ietf-abfab-eapapplicability-03 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-10 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 -- kivinen@iki.fi From carl@redhoundsoftware.com Thu Jun 20 04:26:09 2013 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 EE12121F9A5E for ; Thu, 20 Jun 2013 04:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diw4HWXWbxm7 for ; Thu, 20 Jun 2013 04:26:08 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 69F1221F9A59 for ; Thu, 20 Jun 2013 04:26:08 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so3620996qcv.37 for ; Thu, 20 Jun 2013 04:26:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=5B5OwsQb6JiPPDwu++YCC7h6XghMbSMzsW/rrcaeiGk=; b=cEUHcojVMmTbwdfNk58HPIZXaYPQzYHs8ndvgR7nHN1rxhcbOCo+dPCvurW+XRMeS1 E6G+6NSqwrG4uTDofkAdgznUNBuJ/ss4QCtSxCJ6I4y4HhAmMNoTcI1XzYyUf3ORa7CR RGCBMHuqUSuaawGM7w6DCIVL3TytpbYkoFJm5YW7t42Q8cKJ7hI94RUnZUhUeSf1cyiE rzl1q+S83I4iCSbpVYyS9OdJAoZDFLCWTIoABEDygp/TBLxkboaaYoUEVAJSn0U3u+cd 3zNnHAqHza5GY47IS/rUZkRvGwM2QxQmm0I6l4eALi4MK4VQumJUiZZwIkjmbDe8HwT7 HxnA== X-Received: by 10.49.118.166 with SMTP id kn6mr8989630qeb.39.1371727567502; Thu, 20 Jun 2013 04:26:07 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-116-61.washdc.fios.verizon.net. [173.79.116.61]) by mx.google.com with ESMTPSA id j5sm305229qan.7.2013.06.20.04.26.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 20 Jun 2013 04:26:06 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Thu, 20 Jun 2013 07:26:06 -0400 From: Carl Wallace To: , , Message-ID: Thread-Topic: secdir review for draft-ietf-ipsecme-ad-vpn-problem-07 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnAGfhBExd57mvqEfmg4Nk+Gy3wX1hQlDG2mUKJCmGs4eOoxJy1B0BqBgCEsF5DQ070aULC Subject: [secdir] secdir review for draft-ietf-ipsecme-ad-vpn-problem-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: Thu, 20 Jun 2013 11:26:09 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the problem of enabling a large number of systems to communicate directly using IPSec and defines requirements for prospective solutions. As a problem statement, it does not introduce any new security concerns. I have no new use cases, requirements or security concerns to contribute. I had one minor nit. The use cases specifically call out a need for an authentication mechanism. The requirements do not (other than implicitly through requirement 5). From curtis@ipv6.occnc.com Thu Jun 20 10:19:03 2013 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 CF8CD21F9D98; Thu, 20 Jun 2013 10:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdT64bDH8RSy; Thu, 20 Jun 2013 10:18:58 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9D85921F9E8B; Thu, 20 Jun 2013 10:18:54 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r5KHHaaW004832; Thu, 20 Jun 2013 13:17:38 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201306201717.r5KHHaaW004832@gateway1.orleans.occnc.com> To: Tom Yu From: Curtis Villamizar In-reply-to: Your message of "Wed, 19 Jun 2013 23:58:21 EDT." Date: Thu, 20 Jun 2013 13:17:36 -0400 X-Mailman-Approved-At: Thu, 20 Jun 2013 10:20:13 -0700 Cc: draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-rtgwg-cl-requirement-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:19:04 -0000 In message Tom Yu writes: > > 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 states many requirements on properties of proposed > solutions, but it seems that none of these requirements is a security > requirement. If nodes need to send new information that existing > routing or signaling protocols do not currently send, what level of > protection does that information require? Hi Tom, > In the Security Considerations section, I'm not sure what the intent > is in using the phrasing "man-in-the-middle confidentiality breach". > I generally consider "man-in-the-middle" to mean an active attacker > (one that can receive, suppress, modify, and transmit arbitrary data); > this type of attacker primarily has consequences for integrity. (An > active attacker could also compromise the confidentiality of a channel > that is secure against passive attackers). A passive attack is often > sufficient to compromise confidentiality, especially if a protocol > sends information in the clear. The entire one paragraph section is: This document specifies a set of requirements. The requirements themselves do not pose a security threat. If these requirements are met using MPLS signaling as commonly practiced today with authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, then the requirement to provide additional information in this communication presents additional information that could conceivably be gathered in a man-in-the-middle confidentiality breach. Such an attack would require a capability to monitor this signaling either through a provider breach or access to provider physical transmission infrastructure. A provider breach already poses a threat of numerous tpes of attacks which are of far more serious consequence. Encrption of the signaling can prevent or render more difficult any confidentiality breach that otherwise might occur by means of access to provider physical transmission infrastructure. What is meant by "man-in-the-middle confidentiality breach" is a man-in-the-middle situation in which the extent of damage is loss of confidentiality due to routing protocols generally being authenticated but in the clear, in this case the OSPF-TE and ISIS-TE. This is no different, except now additional information is present, such as delay. Providers already feel that topology is sensitive information that they would prefer competitors didn't have and delay would be at least as sensitive. The sentence in question is the first third "If these requirements are met using MPLS signaling as commonly practiced today with authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, then the requirement to provide additional information in this communication presents additional information that could conceivably be gathered in a man-in-the-middle confidentiality breach." > What scope of compromise does "provider breach" designate? What is meant by "provider breach" is any breach in which equipment used in the provider infrastructure or management of that infrastructure is fully compromised. It is well known that really bad things can happen if a router is compromised and can inject bad information. It is also well known that bad things can happen if there is a compromise of management systems and in some cases workstations involved in network management. The access to physical transmission infrastructure means being able to listen in on microwave or being able to put a bend in fiber and get som light to leak out or somehow otherwise monitoring the signal, demodulating it, and looking at anything in the clear. The entire section is acknowledging an imperfect status quo and trying to say that it makes it no worse. Perhaps is does so unclearly. Maybe we could just replace the section with the standard boilerplate: The security considerations for MPLS/GMPLS and for MPLS-TP are documented in and . This document does not impact the security of MPLS, GMPLS, or MPLS-TP. That would certainly be more clear. This type of boilerplate is in the framework document but could be moved to the requirements document. See draft-ietf-rtgwg-cl-framework. Would you prefer a wholesale replacement, or fixing up the existing wording to make it more clear? If the latter, can you please suggest text that you feel is clear. I prefer the two sentence replacement above since it is clear and simple and accurate. > Editorial: > > This document uses many acronyms without expanding them -- almost all > of them, from what I can see. Some of the more prominent ones include > DSCP, LDP, LSP, PW, RSVP-TE. Arguably terms such as MPLS, VLAN, and > VPN count as well-known acronyms in the IETF community. Stewart Bryant pointed this out and I have made changes and sent the diffs to Stewart. Curtis From warren@kumari.net Thu Jun 20 11:26:04 2013 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 D249321F8793; Thu, 20 Jun 2013 11:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DzNaWSCU5uH; Thu, 20 Jun 2013 11:26:00 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4EF21F871D; Thu, 20 Jun 2013 11:25:59 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.90]) by vimes.kumari.net (Postfix) with ESMTPSA id 2713A1B40A72; Thu, 20 Jun 2013 14:25:59 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jun 2013 14:25:58 -0400 Message-Id: To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-lisp-mib.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [secdir] secdir review of draft-ietf-lisp-mib 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, 20 Jun 2013 18:26:04 -0000 Be ye not afraid=85. 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 defines a MIB for monitoring LISP devices.=20 This set off the standard "Nooooo=85 SNMP Write=85 Noooo=85." alarm = bells, but then I skipped down to the Security Considerations section = and saw that authors had anticipated my shrieks of despair and that the = draft says that there are no read-write / read-create objects. The Security Considerations section seems well written and complete. It = makes a suggestion that SNMPv3, with crypto goodness, be used to access = this MIB. It also claims that there is no exposed objects in the MIB that are = considered sensitive. I don't LISP, and so don't know what all might be = considered sensitive, but from reading most of the descriptions, and = applying some common-sense the claim seems reasonable. ----------- Two questions / nits: 1: The DESCRIPTION for 'lispMIBTuningParametersGroup' says: "A = collection of writeable objects used to=85" but these seem Read-only. It = is possible I misunderstand the description. 2: The Security Considerations section points out that SNMP prior to V3 = doesn't have adequate security, and that there is no control who can = GET/**SET** things (emphasis mine). I suspect that this was lifted = verbatim from e.g http://tools.ietf.org/html/rfc5834. As there is no set / write in this MIB I think that removing the mention = of setting things would be clearer. s/to access and GET/SET (read/change/create/delete) the objects/to = access the objects/=20 Apologies for how late this review is. I was filtering the SecDir = assignments into an incorrect folder and so missed it completely. W -- Some people are like Slinkies......Not really good for anything but they = still bring a smile to your face when you push them down the stairs. From adrian@olddog.co.uk Thu Jun 20 14:58:30 2013 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 9B0B621F9E9E; Thu, 20 Jun 2013 14:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckBtpBNAAa89; Thu, 20 Jun 2013 14:58:26 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id A1D4621F9E62; Thu, 20 Jun 2013 14:58:25 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5KLwNbi003379; Thu, 20 Jun 2013 22:58:24 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5KLwMFr003353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Jun 2013 22:58:23 +0100 From: "Adrian Farrel" To: "'Warren Kumari'" , , , Date: Thu, 20 Jun 2013 22:58:20 +0100 Message-ID: <090501ce6e01$4779cb70$d66d6250$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5uATmYr9QkkRFnRYCcRmONQQmJ5g== Content-Language: en-gb Subject: Re: [secdir] secdir review of draft-ietf-lisp-mib X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 21:58:30 -0000 although... lispMIBTuningParametersGroup OBJECT-GROUP OBJECTS { lispFeaturesMapCacheLimit, lispFeaturesEtrMapCacheTtl } STATUS current DESCRIPTION "A collection of writeable objects used to configure LISP behavior and to tune performance." ::= { lispGroups 10 } ...might lead one to think that something here is writeable. Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Warren Kumari > Sent: 20 June 2013 19:26 > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-lisp-mib.all@tools.ietf.org > Cc: Warren Kumari > Subject: secdir review of draft-ietf-lisp-mib > > Be ye not afraid.. > > 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 defines a MIB for monitoring LISP devices. > This set off the standard "Nooooo. SNMP Write. Noooo.." alarm bells, but > then I skipped down to the Security Considerations section and saw that authors > had anticipated my shrieks of despair and that the draft says that there are no > read-write / read-create objects. > > The Security Considerations section seems well written and complete. It makes a > suggestion that SNMPv3, with crypto goodness, be used to access this MIB. > It also claims that there is no exposed objects in the MIB that are considered > sensitive. I don't LISP, and so don't know what all might be considered sensitive, > but from reading most of the descriptions, and applying some common-sense > the claim seems reasonable. > > ----------- > > Two questions / nits: > 1: The DESCRIPTION for 'lispMIBTuningParametersGroup' says: "A collection of > writeable objects used to." but these seem Read-only. It is possible I > misunderstand the description. > > 2: The Security Considerations section points out that SNMP prior to V3 doesn't > have adequate security, and that there is no control who can GET/**SET** > things (emphasis mine). I suspect that this was lifted verbatim from e.g > http://tools.ietf.org/html/rfc5834. > > As there is no set / write in this MIB I think that removing the mention of setting > things would be clearer. > s/to access and GET/SET (read/change/create/delete) the objects/to access the > objects/ > > > Apologies for how late this review is. I was filtering the SecDir assignments into an > incorrect folder and so missed it completely. > > W > > > > > -- > Some people are like Slinkies......Not really good for anything but they still bring a > smile to your face when you push them down the stairs. > From warren@kumari.net Thu Jun 20 15:50:34 2013 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 CC97B21E80A9; Thu, 20 Jun 2013 15:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob9GO9++6HFO; Thu, 20 Jun 2013 15:50:29 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B5C21E8097; Thu, 20 Jun 2013 15:50:29 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.90]) by vimes.kumari.net (Postfix) with ESMTPSA id BA6791B40088; Thu, 20 Jun 2013 18:50:27 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <090501ce6e01$4779cb70$d66d6250$@olddog.co.uk> Date: Thu, 20 Jun 2013 18:50:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9FECF25C-649B-4DD6-A99E-F15532AC5435@kumari.net> References: <090501ce6e01$4779cb70$d66d6250$@olddog.co.uk> To: X-Mailer: Apple Mail (2.1508) Cc: iesg@ietf.org, draft-ietf-lisp-mib.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-mib 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, 20 Jun 2013 22:50:35 -0000 On Jun 20, 2013, at 5:58 PM, "Adrian Farrel" = wrote: > although... >=20 > lispMIBTuningParametersGroup OBJECT-GROUP > OBJECTS { lispFeaturesMapCacheLimit, > lispFeaturesEtrMapCacheTtl > } > STATUS current > DESCRIPTION > "A collection of writeable objects used to > configure LISP behavior and to tune performance." > ::=3D { lispGroups 10 } >=20 > ...might lead one to think that something here is writeable. Yup, which I why I mentioned it=85 W >=20 > Adrian >=20 >=20 >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf = Of >> Warren Kumari >> Sent: 20 June 2013 19:26 >> To: iesg@ietf.org; secdir@ietf.org; = draft-ietf-lisp-mib.all@tools.ietf.org >> Cc: Warren Kumari >> Subject: secdir review of draft-ietf-lisp-mib >>=20 >> Be ye not afraid.. >>=20 >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >>=20 >> This draft defines a MIB for monitoring LISP devices. >> This set off the standard "Nooooo. SNMP Write. Noooo.." alarm bells, = but >> then I skipped down to the Security Considerations section and saw = that > authors >> had anticipated my shrieks of despair and that the draft says that = there are > no >> read-write / read-create objects. >>=20 >> The Security Considerations section seems well written and complete. = It makes > a >> suggestion that SNMPv3, with crypto goodness, be used to access this = MIB. >> It also claims that there is no exposed objects in the MIB that are = considered >> sensitive. I don't LISP, and so don't know what all might be = considered > sensitive, >> but from reading most of the descriptions, and applying some = common-sense >> the claim seems reasonable. >>=20 >> ----------- >>=20 >> Two questions / nits: >> 1: The DESCRIPTION for 'lispMIBTuningParametersGroup' says: "A = collection of >> writeable objects used to." but these seem Read-only. It is possible = I >> misunderstand the description. >>=20 >> 2: The Security Considerations section points out that SNMP prior to = V3 > doesn't >> have adequate security, and that there is no control who can = GET/**SET** >> things (emphasis mine). I suspect that this was lifted verbatim from = e.g >> http://tools.ietf.org/html/rfc5834. >>=20 >> As there is no set / write in this MIB I think that removing the = mention of > setting >> things would be clearer. >> s/to access and GET/SET (read/change/create/delete) the objects/to = access the >> objects/ >>=20 >>=20 >> Apologies for how late this review is. I was filtering the SecDir = assignments > into an >> incorrect folder and so missed it completely. >>=20 >> W >>=20 >>=20 >>=20 >>=20 >> -- >> Some people are like Slinkies......Not really good for anything but = they still > bring a >> smile to your face when you push them down the stairs. >>=20 >=20 >=20 -- Life is a concentration camp. You're stuck here and there's no way out = and you can only rage impotently against your persecutors. -- Woody Allen From bew@cisco.com Thu Jun 20 16:37:46 2013 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 70B5121F9FC1; Thu, 20 Jun 2013 16:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11sU8Pgq6yKh; Thu, 20 Jun 2013 16:37:40 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E40E121F9F9E; Thu, 20 Jun 2013 16:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=274; q=dns/txt; s=iport; t=1371771461; x=1372981061; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=szs+HqFFlrmtCzuxn9KUGpJ9ILSRWnQ/l7XpoG0+gl8=; b=Ia7SzyIs6GG1BITGSIMj6AeOL1t4bFkB0pEQ6778zfKBBMW3nOFAcT5X YCRRnhKWJ5aJ+OgQ0fpCh/CEpy2Ukz1vPkRE1nIxZBS4loEa7jat2JDLn RCnsb9pIqy29/l+X+aT9knLQc374onLPP/Y0sjEJLSTlN2Gxypu3EpxaA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALyRw1GrRDoJ/2dsb2JhbABbgwnAMIEAFnSCZD+BPgGIHwG8Oo9JgwdhA4khjiKRRIMv X-IronPort-AV: E=Sophos;i="4.87,908,1363132800"; d="scan'208";a="83952174" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 20 Jun 2013 23:37:40 +0000 Received: from dhcp-128-107-147-81.cisco.com (dhcp-128-107-147-81.cisco.com [128.107.147.81]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5KNbdoj014343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Jun 2013 23:37:39 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jun 2013 16:37:38 -0700 Message-Id: <712268AC-15B4-416D-82AD-5C835299E5C8@cisco.com> To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "draft-ietf-ipfix-protocol-rfc5101bis.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-ipfix-protocol-rfc5101bis-08 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, 20 Jun 2013 23:37:46 -0000 I had previously done a Secdir review of = draft-ietf-ipfix-protocol-rfc5101bis-06 and had a few minor suggestions. = They have been incorporated into = draft-ietf-ipfix-protocol-rfc5101bis-08, and believe it ready to be = published as a Standards Track RFC. Brian= From gschudel@cisco.com Thu Jun 20 16:35:54 2013 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 9784821F94D3; Thu, 20 Jun 2013 16:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOn7siBn2NOX; Thu, 20 Jun 2013 16:35:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EEC3F21E80A9; Thu, 20 Jun 2013 16:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1283; q=dns/txt; s=iport; t=1371771349; x=1372980949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NsgSYbOKaIfezBDe5ywolN2ipLApsATxoL3Ezr3WN1I=; b=BXg+R0kcKEqLneKSadPEDBj8+yYO9WRzli0UaSZxsLoBPLM+5WAB9/Ci 3TeFqRPJrA5A1/zHmK5DvGfrcsxRHOgdnqS3qg/je3VZTewmTRADFaSSY MCPsYN54sEwzna2VdtEl/e6hwXO45YP8FBe/IDTDgE3o7VGq5hHLM/QEA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHuRw1GtJV2c/2dsb2JhbABYA4MJMUm/NoEAFnSCIwEBAQMBbwoFCwIBCCIkMiUBAQQBDQUIiAAGDLwujgeBESEQAgURgm9hA6kHgw+BcTc X-IronPort-AV: E=Sophos;i="4.87,908,1363132800"; d="scan'208";a="225558675" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jun 2013 23:35:26 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5KNZQ9d032114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 23:35:26 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 18:35:25 -0500 From: "Gregg Schudel (gschudel)" To: "adrian@olddog.co.uk" , Warren Kumari Thread-Topic: secdir review of draft-ietf-lisp-mib Thread-Index: Ac5uATmYXtkwaatKH0SLzuM4iyAJ2QAN4VIA Date: Thu, 20 Jun 2013 23:35:24 +0000 Message-ID: References: <090501ce6e01$4779cb70$d66d6250$@olddog.co.uk> In-Reply-To: <090501ce6e01$4779cb70$d66d6250$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.123.107] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1BFCAEF013F9534AABDDBF06284D4E08@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 21 Jun 2013 01:39:36 -0700 Cc: "iesg@ietf.org" , "draft-ietf-lisp-mib.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-lisp-mib 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, 20 Jun 2013 23:35:54 -0000 On Jun 20, 2013, at 2:58 PM, Adrian Farrel wrote: > although... >=20 > lispMIBTuningParametersGroup OBJECT-GROUP > OBJECTS { lispFeaturesMapCacheLimit, > lispFeaturesEtrMapCacheTtl > } > STATUS current > DESCRIPTION > "A collection of writeable objects used to > configure LISP behavior and to tune performance." > ::=3D { lispGroups 10 } >=20 > ...might lead one to think that something here is writeable. >=20 > Adrian thanks all i'll re-word this in the final - it shouldnt have said that. (about writable objects) thanks for pointing it out (it's amazing how carefully these have been read and yet small details slip through=85 ;( Best regards, Gregg -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement:=20 http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From uri@mit.edu Fri Jun 21 04:16:31 2013 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 3A1BD21F90CD; Fri, 21 Jun 2013 04:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUj9-fy+ATVo; Fri, 21 Jun 2013 04:16:26 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id D360C21F9079; Fri, 21 Jun 2013 04:16:25 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-85-51c43608ec80 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A3.73.02411.80634C15; Fri, 21 Jun 2013 07:16:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r5LBGMZU003850; Fri, 21 Jun 2013 07:16:23 -0400 Received: from [192.168.11.118] ([12.15.254.140]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r5LBGJ8F032194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Jun 2013 07:16:21 -0400 References: <090501ce6e01$4779cb70$d66d6250$@olddog.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B329) From: Uri Blumenthal Date: Fri, 21 Jun 2013 06:16:20 -0500 To: "Gregg Schudel (gschudel)" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsUixG6nosthdiTQ4PgmPYsfPTeYLTZ0zmG1 uDjnBLvFjD8TmS0+LHzIYnH42GUmBzaPKb83snosWfKTyeP2jT/sHis2r2T0+HL5M1sAaxSX TUpqTmZZapG+XQJXxpHGtUwFk/kq7v/bzdjAOI27i5GTQ0LARGLdpvPsELaYxIV769m6GLk4 hAT2MUrcXHMMytnIKPHtyyIoZxGTxOULzawgLUIC1RLd67YzdjFycPAKiEtcPegDEuYU8JU4 s3I5I4jNLGAg8WLtRDYIW1ti2cLXzCA2r4CVREvzcxaQmcwCbUwS+x5uYoQ4Q0Zi8/bHYCex CShJNDdvAdslDNTQu+kEE4jNIqAqcfXxVLChIgLGEhOW/2GbwCg4C+GMWUhWz0KyegEj8ypG 2ZTcKt3cxMyc4tRk3eLkxLy81CJdc73czBK91JTSTYzgOHBR2cHYfEjpEKMAB6MSD2+A0uFA IdbEsuLK3EOMkhxMSqK8X0yOBArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4Q2+A1TOm5JYWZVa lA+TkuZgURLnFbu1M1BIID2xJDU7NbUgtQgmK8PBoSTBux9kqGBRanpqRVpmTglCmomDE2Q4 D9DwNyA1vMUFibnFmekQ+VOMuhzznmx9zyjEkpeflyolznsEpEgApCijNA9uDix9vWIUB3pL mPcVSBUPMPXBTXoFtIQJaMme1YdAlpQkIqSkGhgb/n7JjzRz2MFbbLaux9DSkum+o7NOr+XO qk/b21g2yn8KCW2ZwbVwzUT2mBdsYtd9Zt6ZLBq06udiwS9WvbI8l5gcP/sVcm3w3nR1l7DO /wO7G8Kbb7++wpSs8/JTff59rQs7shsk7L+Fu8ly7Pg5a8bXN0uebpDdnHi3pD+rbOovNaM7 O0SVWIozEg21mIuKEwEwujAyOgMAAA== Cc: "adrian@olddog.co.uk" , "iesg@ietf.org" , "draft-ietf-lisp-mib.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-lisp-mib 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, 21 Jun 2013 11:16:31 -0000 So what's the problem making these writable under SNMPv3 protection (and sta= ting this requirement)? Sent from my iPad On Jun 20, 2013, at 18:35, "Gregg Schudel (gschudel)" w= rote: >=20 > On Jun 20, 2013, at 2:58 PM, Adrian Farrel wrote: >=20 >> although... >>=20 >> lispMIBTuningParametersGroup OBJECT-GROUP >> OBJECTS { lispFeaturesMapCacheLimit, >> lispFeaturesEtrMapCacheTtl >> } >> STATUS current >> DESCRIPTION >> "A collection of writeable objects used to >> configure LISP behavior and to tune performance." >> ::=3D { lispGroups 10 } >>=20 >> ...might lead one to think that something here is writeable. >>=20 >> Adrian >=20 >=20 > thanks all >=20 > i'll re-word this in the final - it shouldnt have said that. > (about writable objects) >=20 > thanks for pointing it out > (it's amazing how carefully these have been read and yet small > details slip through=85 ;( >=20 >=20 >=20 > Best regards, > Gregg >=20 > -------------------------------------------------------------------- > .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr > cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com > -------------------------------------------------------------------- > cisco corporate legal statement:=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -------------------------------------------------------------------- >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From adrian@olddog.co.uk Fri Jun 21 08:00:52 2013 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 C2E0121E812E; Fri, 21 Jun 2013 08:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIW7lr6omrme; Fri, 21 Jun 2013 08:00:47 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id A6ECC11E81A1; Fri, 21 Jun 2013 08:00:46 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5LF0T8v004107; Fri, 21 Jun 2013 16:00:29 +0100 Received: from 950129200 (customer18280.100.kt.cust.t-mobile.co.uk [178.100.71.103] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5LF0HHZ003782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Jun 2013 16:00:21 +0100 From: "Adrian Farrel" To: "'Uri Blumenthal'" , "'Gregg Schudel \(gschudel\)'" References: <090501ce6e01$4779cb70$d66d6250$@olddog.co.uk> In-Reply-To: Date: Fri, 21 Jun 2013 16:00:09 +0100 Message-ID: <09d701ce6e90$0fa99100$2efcb300$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNJ2fjLzezWjeq+76qJDYf+9ym7jQHtuqxnAfEkD7CWKnSq8A== Content-Language: en-gb Cc: iesg@ietf.org, draft-ietf-lisp-mib.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-mib X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:00:52 -0000 Writable MIB objects are very out of fashion these days. But the Ops guys should comment more. My gripe was only that this Group says they are writable when the object definitions say they are not. Adrian > So what's the problem making these writable under SNMPv3 protection (and > stating this requirement)? > > On Jun 20, 2013, at 18:35, "Gregg Schudel (gschudel)" > wrote: > > > > > On Jun 20, 2013, at 2:58 PM, Adrian Farrel wrote: > > > >> although... > >> > >> lispMIBTuningParametersGroup OBJECT-GROUP > >> OBJECTS { lispFeaturesMapCacheLimit, > >> lispFeaturesEtrMapCacheTtl > >> } > >> STATUS current > >> DESCRIPTION > >> "A collection of writeable objects used to > >> configure LISP behavior and to tune performance." > >> ::= { lispGroups 10 } > >> > >> ...might lead one to think that something here is writeable. > > > > i'll re-word this in the final - it shouldnt have said that. > > (about writable objects) > > > > thanks for pointing it out > > (it's amazing how carefully these have been read and yet small > > details slip through. ;( From hilarie@purplestreak.com Fri Jun 21 10:07:03 2013 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 EA6C621F9F1C; Fri, 21 Jun 2013 10:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFvco3dVEsbZ; Fri, 21 Jun 2013 10:06:51 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id D010121F9F08; Fri, 21 Jun 2013 10:06:51 -0700 (PDT) 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 1Uq4nS-0007jS-8V; Fri, 21 Jun 2013 11:06:50 -0600 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 1Uq4nO-0003cW-QT; Fri, 21 Jun 2013 11:06:50 -0600 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 r5LH5R2R025410; Fri, 21 Jun 2013 11:05:27 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id r5LH5Qf2025408; Fri, 21 Jun 2013 11:05:26 -0600 Date: Fri, 21 Jun 2013 11:05:26 -0600 Message-Id: <201306211705.r5LH5Qf2025408@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; sa01 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) Cc: draft-thornburgh-adobe-rtmfp@tools.ietf.org Subject: [secdir] Security review of draft-thornburgh-adobe-rtmfp-07 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: Fri, 21 Jun 2013 17:07:04 -0000 Security review of Adobe's Secure Real-Time Media Flow Protocol draft-thornburgh-adobe-rtmfp-07 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. This is an informational RFC describing an existing Adobe protocol. It has the feature of allowing sessions to change their IP addresses and to use forwarders to help in NAT traversal. The draft does not specify the cryptographics requirements and processing in enough detail to facilitate interoperable implementations, and I don't recommend advancing it. The draft generically specifies the cryptographic features that would provide privacy and authentication. All specifics are left to the implementor. The cryptographic profiles could be trivial (rot13 and casting out nines, for example). How is the cryptographic profile specified? Is there only one, to be used by all implementations RTMFP? If not, how do two implementations agree on which profile they will use? How is the "default session key" selected? The text mentions the possibility of multiple default keys. In "Security Considerations": ... to allow for different applications of RTMFP using different Default Session Keys to (intentionally or not) share network transport addresses without interference. I don't see how this could work. What is the algorithm for encrypting with the default session key? Note that the crypto profile is supposed to determine the keys, but there is not necessarily an interface that accepts a default key and produces usable encryption and integrity/authentication keys. Is there any response for "endpoint discriminator unacceptable"? I did not see any "MUST" requirements for rejecting data that fails to pass cryptographic checks. How are message integrity and authentication achieved? Is it required? Section 2.2.3 says: "The packet encryption layer is responsible for data integrity and authenticity, for example by means of a checksum or cryptographic message authentication code." That does not seem to require that the message integrity be tied to the Endpoint Discriminator. Is there anti-replay prevention? I cannot tell. There are sequence numbers, but they could be spoofed under some definitions of the cryptographic profile. Section 2.2.2: "The 32-bit Scrambled Session ID is the 32-bit Session ID modified by performing a bitwise exclusive-or with the bitwise exclusive-or of the first two 32-bit words of the encrypted packet." This is security-by-obscurity and is not worth the trouble. The Security Considerations admit that the Default Session Key is such a weak measure that all messages that use it should be considered to be sent in the clear. It isn't worth the trouble of using it. There are robust IETF security protocols that could be layered over RTMFP. I recommend removing all references to cryptography from this document. Hilarie From yaronf.ietf@gmail.com Mon Jun 24 00:39:05 2013 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 E789E21F8E70; Mon, 24 Jun 2013 00:39:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klGX7Lpz3Wbq; Mon, 24 Jun 2013 00:39:01 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2488821F8C9F; Mon, 24 Jun 2013 00:39:00 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id l15so5936197eak.9 for ; Mon, 24 Jun 2013 00:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yAhszCSrc9Gq7XxWdaZ2AmH8pGzn4deQoomD5rukSIc=; b=AonvmHbFxJhaP3hiMpG93mneB0YahrXDXUIP5+27w5ibPGkKwd31fuHLkmQFdU5ZHD vA7lKMO1LEvXTopPqAnQ3cLL6k0UDJW3c6StijdXd7ZwI4Gbw5qncMFGHK2BO/hcW6YA m2nVMb2ZHWEU75LWsVHXpYl361spzn3l2RGspKuME7+gKhFHcZgE0HEc7pM1ad030bd6 4v90lUtBtOoEgIw5zT23qfyBnqpOLczpm4PBI0XpUs7+YhVwtlAYiCVABtT8HRP2QjJo gZ8RjK7of0o38yxG2wvvSTiF2pLfeSA1KHrpuJb8bZbjXOgTMUusX+n+qcrJPwOXsT4h 1Shw== X-Received: by 10.15.91.69 with SMTP id r45mr23382212eez.79.1372059540256; Mon, 24 Jun 2013 00:39:00 -0700 (PDT) Received: from [10.0.0.14] (109-186-101-35.bb.netvision.net.il. [109.186.101.35]) by mx.google.com with ESMTPSA id b3sm26300428eev.10.2013.06.24.00.38.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 00:38:59 -0700 (PDT) Message-ID: <51C7F789.7050201@gmail.com> Date: Mon, 24 Jun 2013 10:38:49 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Ogaki, Kenichi" References: <51BE1BC7.9080500@gmail.com> <010f01ce6ace$15788430$40698c90$@olddog.co.uk> <018101ce7071$1f659750$5e30c5f0$@kddi.com> In-Reply-To: <018101ce7071$1f659750$5e30c5f0$@kddi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: adrian@olddog.co.uk, draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org, 'The IESG' , 'IETF Security Directorate' Subject: Re: [secdir] SecDir review of draft-ietf-pce-gmpls-aps-req-08 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, 24 Jun 2013 07:39:05 -0000 Hi Kenichi, Looks good to me. Thanks, Yaron On 2013-06-24 03:23, Ogaki, Kenichi wrote: > Dear Yaron an Adrian, > > Thank you for your comments. > > To address your comments, we propose the texts for Sec. 4. Security > Considerations as follows: > > PCEP extensions to support GMPLS should be considered under the same > security as current PCE work and this extension will not change the > underlying security issues. Sec. 10 of [RFC5440] describes the list of > security considerations in PCEP. At the time [RFC5440] was published, TCP > Authentication Option (TCP-AO) had not been fully specified for securing the > TCP connections that underlie PCEP sessions. TCP-AO [RFC5925] has now been > published and PCEP implementations should fully support TCP-AO according to > [RFC6952]. > > Thanks, > Kenichi > > -- > Kenichi Ogaki > KDDI | IP Transport Network Development Dept. > +81-(0)80-5945-9138 | www.kddi.com > >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Monday, June 17, 2013 5:14 AM >> To: 'Yaron Sheffer' >> Cc: 'IETF Security Directorate'; 'The IESG'; >> draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org >> Subject: RE: SecDir review of draft-ietf-pce-gmpls-aps-req-08 >> >> Hi, >> >> Thanks Yaron. >> >> You're right about pointing to 5440. That document notes that TCP-AO > should >> be used once it becomes available, and since it has done, a pointer to RFC >> 6952 would also be helpful. >> >> Cheers, >> Adrian >> >>> -----Original Message----- >>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf >>> Of Yaron Sheffer >>> Sent: 16 June 2013 21:11 >>> To: IETF Security Directorate; The IESG; draft-ietf-pce-gmpls-aps- >>> req.all@tools.ietf.org >>> Subject: SecDir review of draft-ietf-pce-gmpls-aps-req-08 >>> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the IESG. >>> These comments were written primarily for the benefit of the security >>> area directors. Document editors and WG chairs should treat these >>> comments just like any other last call comments. >>> >>> This document defines additional GMPLS-specific requirements on the >>> PCE architecture. >>> >>> It would be an understatement to characterize this reviewer as a >>> non-expert on PCE and GMPLS. That being said, I believe the Security >>> Considerations are correct in saying that this document does not add >>> any additional security issues on top of PCE. >>> >>> I would recommend to add a pointer to where such considerations are in >>> fact listed, e.g. Sec. 10 of RFC 5440. Though security folks will >>> cringe at TCP-MD5 being described as the most practical security >>> solution in that section. >>> >>> Thanks, >>> Yaron > > From ke-oogaki@kddi.com Sun Jun 23 17:34:12 2013 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 55CEA21F9FDC; Sun, 23 Jun 2013 17:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBpsHXI6i7+Y; Sun, 23 Jun 2013 17:34:08 -0700 (PDT) Received: from UTMC1103.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id B534B21F9FD8; Sun, 23 Jun 2013 17:34:07 -0700 (PDT) Received: from UTMC1132 (unknown [10.5.16.195]) by UTMC1103.kddi.com (Postfix) with SMTP id 2725E297D; Mon, 24 Jun 2013 09:34:05 +0900 (JST) Received: from UTMC1122.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 34785174FC; Mon, 24 Jun 2013 09:33:57 +0900 (JST) Received: from LTMC1006.kddi.com (unknown [10.5.16.217]) by UTMC1122.kddi.com (Postfix) with ESMTP id 12AE9174F9; Mon, 24 Jun 2013 09:33:57 +0900 (JST) Received: from LTMC1006.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r5O0XuHv022717; Mon, 24 Jun 2013 09:33:56 +0900 Received: from LTMC1006.kddi.com.mid_18574161 (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r5O0NusQ012650; Mon, 24 Jun 2013 09:23:56 +0900 Received: from KDDI0802PC0412 ([10.200.132.0] [10.200.132.0]) by post-zip.kddi.com with ESMTPA; Mon, 24 Jun 2013 09:23:55 +0900 From: "Ogaki, Kenichi" To: , "'Yaron Sheffer'" References: <51BE1BC7.9080500@gmail.com> <010f01ce6ace$15788430$40698c90$@olddog.co.uk> In-Reply-To: <010f01ce6ace$15788430$40698c90$@olddog.co.uk> Date: Mon, 24 Jun 2013 09:23:58 +0900 Message-Id: <018101ce7071$1f659750$5e30c5f0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: ja Thread-index: AQHLh0WB0VH4mHfmMihaopBkqTJ8YwFMY//RmT9vj4A= X-SA-MID: 18574161 X-WAuditID: 1306240933570000202616 X-Mailman-Approved-At: Mon, 24 Jun 2013 02:24:45 -0700 Cc: draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org, 'The IESG' , 'IETF Security Directorate' Subject: Re: [secdir] SecDir review of draft-ietf-pce-gmpls-aps-req-08 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, 24 Jun 2013 00:34:12 -0000 Dear Yaron an Adrian, Thank you for your comments. To address your comments, we propose the texts for Sec. 4. Security Considerations as follows: PCEP extensions to support GMPLS should be considered under the same security as current PCE work and this extension will not change the underlying security issues. Sec. 10 of [RFC5440] describes the list of security considerations in PCEP. At the time [RFC5440] was published, TCP Authentication Option (TCP-AO) had not been fully specified for securing the TCP connections that underlie PCEP sessions. TCP-AO [RFC5925] has now been published and PCEP implementations should fully support TCP-AO according to [RFC6952]. Thanks, Kenichi -- Kenichi Ogaki KDDI | IP Transport Network Development Dept. +81-(0)80-5945-9138 | www.kddi.com > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Monday, June 17, 2013 5:14 AM > To: 'Yaron Sheffer' > Cc: 'IETF Security Directorate'; 'The IESG'; > draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org > Subject: RE: SecDir review of draft-ietf-pce-gmpls-aps-req-08 > > Hi, > > Thanks Yaron. > > You're right about pointing to 5440. That document notes that TCP-AO should > be used once it becomes available, and since it has done, a pointer to RFC > 6952 would also be helpful. > > Cheers, > Adrian > > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > > Of Yaron Sheffer > > Sent: 16 June 2013 21:11 > > To: IETF Security Directorate; The IESG; draft-ietf-pce-gmpls-aps- > > req.all@tools.ietf.org > > Subject: SecDir review of draft-ietf-pce-gmpls-aps-req-08 > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security > > area directors. Document editors and WG chairs should treat these > > comments just like any other last call comments. > > > > This document defines additional GMPLS-specific requirements on the > > PCE architecture. > > > > It would be an understatement to characterize this reviewer as a > > non-expert on PCE and GMPLS. That being said, I believe the Security > > Considerations are correct in saying that this document does not add > > any additional security issues on top of PCE. > > > > I would recommend to add a pointer to where such considerations are in > > fact listed, e.g. Sec. 10 of RFC 5440. Though security folks will > > cringe at TCP-MD5 being described as the most practical security > > solution in that section. > > > > Thanks, > > Yaron From hartmans@mit.edu Mon Jun 24 06:38:21 2013 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 982A621F9EDE; Mon, 24 Jun 2013 06:38:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ9Dkg3mpIku; Mon, 24 Jun 2013 06:38:15 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B196421F9EC2; Mon, 24 Jun 2013 06:38:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 77E23200E0; Mon, 24 Jun 2013 09:34:06 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTy0ix9-IkPT; Mon, 24 Jun 2013 09:34:05 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 24 Jun 2013 09:34:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9F93A80952; Mon, 24 Jun 2013 09:37:49 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org,secdir@ietf.org Date: Mon, 24 Jun 2013 09:37:49 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-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: Mon, 24 Jun 2013 13:38:21 -0000 Please treat these comments as normal last-call comments. I've been asigned as a security directorate reviewer for this draft. This draft specifies a mechanism to indicate which packets were discarded in a RTP stream. for the most part, this doesn't seem to have any security implications, and the text is clear. I do have one concern. Has the WG analyzed implications of providing feedback to an attacker on what specific SRTP packets are discarded? In the past we've run into trouble with security systems that were too verbose in error reporting. As an example, in certain public-key crypto constructions knowing whether a packet produced a decoding error vs a signature error after decryption can provide an attacker generating forged packets valuable information to attack the system. It's quite possible that SRTP doesn't have problems in this regard. I just want to confirm that the analysis has been done. From new-work-bounces@ietf.org Mon Jun 24 08:08:51 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E2121F9C3F; Mon, 24 Jun 2013 08:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1372086531; bh=/MFIDox+velmszvUr/MU2lKEp+I0+qZS86XzfxpT+oo=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=iEht7RBySaoE2kJ9Ov7RWYX5xxTQzA+2IuRAeGizsK6QLfZmuEx5BR7HV3DLxOoxI w1exPFcb4dM3a5Q56aa0vPfqHA75Q2Pn4Xh3rS2v6m6Ek5CMRuk8Cb76tgmbpoU2/q 6bflrHTBB6OM2rRQDubJvfdx812isYX3c+Nl8nnk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7A321E8092 for ; Sun, 23 Jun 2013 23:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.997 X-Spam-Level: X-Spam-Status: No, score=-7.997 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8aFVPvE3Dcd for ; Sun, 23 Jun 2013 23:33:24 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3C26421E809E for ; Sun, 23 Jun 2013 23:33:24 -0700 (PDT) Received: from host86-180-158-215.range86-180.btcentralplus.com ([86.180.158.215] helo=cascade6.home) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ur0Ky-0000ZB-88; Mon, 24 Jun 2013 02:33:16 -0400 Mime-Version: 1.0 (Apple Message framework v1283) From: Tim Berners-Lee X-Priority: 1 In-Reply-To: <20130624150333.9763.544A59DA@itscj.ipsj.or.jp> Date: Mon, 24 Jun 2013 08:33:09 +0200 Message-Id: <9B774119-3B56-4E1B-92B5-CB64B3006BDF@w3.org> References: <20130624150333.9763.544A59DA@itscj.ipsj.or.jp> To: WATANABE Shinji , W3C Liaisons team X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Mon, 24 Jun 2013 08:08:50 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============0152674878703231813==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 24 Jun 2013 08:10:40 -0700 Cc: Chris Lilley , jc@dufourd.org, leonardo@chiariglione.org, yklwhite@gmail.com, new-work@ietf.org, sc29-sec@itscj.ipsj.or.jp Subject: [secdir] [new-work] MPEG-21 Contract Expression Language and Media Contract Ontology Re: Liaison Statement to W3C (SC 29 N 13458) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:08:52 -0000 --===============0152674878703231813== Content-Type: multipart/alternative; boundary="Apple-Mail=_398A8611-AD83-4090-942E-70E4AB1A0458" --Apple-Mail=_398A8611-AD83-4090-942E-70E4AB1A0458 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Mr Watanabe, Than you for your message alerting us to new work on Contract Expression Language and a Media Contract Ontology being developed by SC29. Please copy W3C Liaisons (as above) on future = similar correspondence. Best Wishes Tim Berners-Lee Director W3C On 2013-06 -24, at 08:03, WATANABE Shinji wrote: > Dear Mr. Tim Berners-Lee, >=20 > In accordance with Resolutions taken at the 104th > SC 29/WG 11 Meeting, 2013-04-22/26, Incheon, Korea, > I am pleased to send attached Liaison statement > to W3C Web and TV Interest Group and Privacy Interest Group. >=20 > If you have any questions, please do not hesitate to contact me. > Thank you for your cooperation. >=20 >=20 > Best Regards, > Shinji Watanabe > Assistant Secretary, ISO/IEC JTC 1/SC 29 >=20 > ----- > WATANABE Shinji > Assistant Secretary, ISO/IEC JTC 1/SC 29 > IPSJ/ITSCJ > 308-3 Kikai-Shinko-Kaikan Bldg. > 3-5-8 Shiba-koen, Minato-ku, Tokyo 105-0011 Japan > Tel: +81-3-3431-2808 Fax: +81-3-3431-6493 > Mail: watanabe@itscj.ipsj.or.jp > <29n13458.zip> ISO/IEC JTC 1/SC 29 N 13458=20 DATE: 2013-06-24=20 =20 ISO/IEC JTC 1/SC 29=20 Coding of Audio, Picture, Multimedia and Hypermedia Information=20 Secretariat: Japan (JISC) DOC. TYPE Outgoing Liaison Statement TITLE Liaison Statement from SC 29/WG 11 on MPEG-21 Contract = Expression Language and Media Contract Ontology [SC 29/WG 11 N 13544] SOURCE ISO/IEC JTC 1/SC 29/WG 11 PROJECT =20 STATUS In accordance with Resolutions taken at the 104th SC 29/WG 11 = Meeting, 2013-04-22/26, Incheon, Korea, the SC 29 Secretariat forwarded = this liaison statement to WIPO, EBU, ABU, NABA, AIR-IAB, AUB-UAR, ASBU, = ACT and W3C. [Requested action: For SC 29's information] ACTION ID FYI DUE DATE =20 DISTRIBUTION P, O and L Members of ISO/IEC JTC 1/SC 29 ; ISO/IEC JTC = 1 Secretariat; ISO/IEC ITTF ACCESS LEVEL Def ISSUE NO. 1447 FILE=09 NAME SIZE (KB) PAGES 29n13458c.htm 29n134581.doc 78.3 2 Secretariat ISO/IEC JTC 1/SC 29 - IPSJ/ITSCJ (Information Processing = Society of Japan/Information Technology Standards Commission of Japan)* = Room 308-3, Kikai-Shinko-Kaikan Bldg., 3-5-8, Shiba-Koen, Minato-ku, = Tokyo 105-0011 Japan *Standard Organization Accredited by JISC=20 Telephone: +81-3-3431-2808; Facsimile: +81-3-3431-6493; E-mail: sc29-sec = @ itscj.ipsj.or.jp Liaison Statement from WG 11 on CEL & MCO INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND AUDIO =20 ISO/IEC JTC1/SC29/WG11 N13544 April 2013, Incheon, Korea =20 Source: Convenor Title: Liaison statement on MPEG-21 Contract Expression = Language and Media Contract Ontology =20 =20 =20 ISO/IEC JTC1/SC29/WG11 (MPEG) is pleased to inform you that the MPEG-21 = suite of standards is about to be enriched with two new standards = related to representing information of contracts on media content. In particular, the standards support the following aspects: =C2=9F Identification of the contract and of possible relations with = pre-existing contracts. =C2=9F Identification of the parties and signatories (with = signatures). =C2=9F Identification of the object of the contract. =C2=9F Unambiguous representation of the agreed terms and conditions. =C2=9F Possibility to encrypt the whole contract or parts of it. =20 ISO/IEC 21000-20 Contract Expression Language provides the XML structure = representation of the contract. ISO/IEC 21000-21 Media Contract Ontology provides the OWL semantic = representation of the contract. Prompt adoption of those standards would foster clarity and improve = efficiency in the audio-visual rights market, while speed and certainty = in rights management would make more content accessible to end users and = would allow a better evaluation of rights. MPEG is aware that exceptions to representation capability for some = aspects of real contracts might appear to be an obstacle to adoption. = However, the technology is flexible by nature to accommodate = improvements and extensions in the short and medium term. These specifications are of potential interest to broadcasters, together = with companies or individuals active in television and cinema = production, and audiovisual products in general, including casual = producers, such as for the so-called =E2=80=9Cuser generated content=E2=80= =9D. Furthermore, audio and video archives, content distributors, providers = of media services and platforms should be clearly also interested, = together with all the companies and organisations which are owners of = the rights related to events which are at the origin of content, such as = sports or festivals. We believe that also providers of IT products and/or services for the = mentioned professionals should be interested. In order to allow you to get the needed technical guidance for early = adoption and use of these standards, and share this within your = communities of practice, and to get the possibility to influence their = improvements by means of future amendments, MPEG is glad to offer this = opportunity of collaboration. =20 --Apple-Mail=_398A8611-AD83-4090-942E-70E4AB1A0458 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = Mr Watanabe,

Than you for your message alerting us to = new work  on
Contract Expression Language and a Media = Contract Ontology
being developed by = SC29.

Please copy W3C Liaisons <team-liaisons@w3.org> (as = above) on future = similar
correspondence.

Best = Wishes

Tim Berners-Lee
Director = W3C


On 2013-06 -24, at = 08:03, WATANABE Shinji wrote:

Dear = Mr. Tim Berners-Lee,

In accordance with Resolutions taken at the = 104th
SC 29/WG 11 Meeting, 2013-04-22/26, Incheon, Korea,
I am = pleased to send attached Liaison statement
to W3C Web and TV Interest = Group and Privacy Interest Group.

If you have any questions, = please do not hesitate to contact me.
Thank you for your = cooperation.


Best Regards,
Shinji Watanabe
Assistant = Secretary, ISO/IEC JTC 1/SC 29

-----
WATANABE = Shinji
Assistant Secretary, ISO/IEC JTC 1/SC = 29
IPSJ/ITSCJ
308-3 Kikai-Shinko-Kaikan Bldg.
3-5-8 Shiba-koen, = Minato-ku, Tokyo 105-0011 Japan
Tel: +81-3-3431-2808 Fax: = +81-3-3431-6493
Mail: watanabe@itscj.ipsj.or.jp<29n13458.zip>


ISO/IEC JTC 1/SC 29 = N 13458 
DATE: = 2013-06-24 
 

ISO/IEC JTC 1/SC 29 
Coding of Audio, = Picture, Multimedia and Hypermedia = Information 
Secretariat: Japan (JISC)

DOC. = TYPEOutgoing Liaison = Statement
TITLELiaison Statement from SC 29/WG 11 on = MPEG-21 Contract Expression Language and Media Contract = Ontology  [SC 29/WG 11 N 13544]
SOURCEISO/IEC JTC 1/SC 29/WG = 11
PROJECT 
STATUSIn accordance with Resolutions = taken at the 104th SC 29/WG 11 Meeting, 2013-04-22/26, Incheon, Korea, = the SC 29 Secretariat forwarded this liaison statement to WIPO, EBU, = ABU, NABA, AIR-IAB, AUB-UAR, ASBU, ACT and W3C. [Requested action: For = SC 29's information]
ACTION IDFYI
DUE DATE 
DISTRIBUTIONP, O and L = Members of ISO/IEC JTC 1/SC 29 ; ISO/IEC JTC 1 Secretariat; ISO/IEC = ITTF
ACCESS = LEVELDef
ISSUE = NO.1447
FILE
NAME
SIZE = (KB)
PAGES
<= table>
29n13458c.htm29n134581.doc
 78.3
 2

<= p style=3D"color: rgb(0, 0, 0); font-family: Times; font-size: medium; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = -webkit-auto; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; ">Secretariat ISO/IEC JTC 1/SC 29 - IPSJ/ITSCJ = (Information Processing Society of Japan/Information Technology = Standards Commission of Japan)* Room 308-3, Kikai-Shinko-Kaikan Bldg., = 3-5-8, Shiba-Koen, Minato-ku, Tokyo 105-0011 Japan *Standard = Organization Accredited by JISC 
Telephone: +81-3-3431-2808; = Facsimile: +81-3-3431-6493; E-mail: sc29-sec @ = itscj.ipsj.or.jp


Liaison Statement from WG 11 on CEL & MCO


INTERNATIONAL ORGANISATION FOR STANDARDISATION

ORGANISATION INTERNATIONALE DE = NORMALISATION

ISO/IEC= JTC1/SC29/WG11

CODING = OF MOVING PICTURES AND AUDIO

 

ISO/IEC JTC1/SC29/WG11 N13544

April 2013, Incheon, Korea

 

Source:         = Convenor

Title:             = ; Liaison statement on MPEG-21 Contract Expression Language and Media Contract = Ontology<= /span>

 

 

 

ISO/IEC = JTC1/SC29/WG11 (MPEG) is pleased to inform you that the MPEG-21 suite of standards is = about to be enriched with two new standards related to representing information = of contracts on media content.

In particular, = the standards support the following aspects:

=C2=9F   Identification of the contract and of possible relations with pre-existing contracts.

=C2=9F   Identification of the parties and signatories = (with signatures).

=C2=9F   Identification of the object of the = contract.

=C2=9F   Unambiguous representation of the agreed terms = and conditions.

=C2=9F   Possibility to encrypt the whole contract or = parts of it.

 

ISO/IEC = 21000-20 Contract Expression Language provides the XML structure representation = of the contract.

ISO/IEC = 21000-21 Media Contract Ontology provides the OWL semantic representation of the = contract.

Prompt adoption = of those standards would foster clarity and improve efficiency in the = audio-visual rights market, while speed and certainty in rights management would make more content accessible to = end users and would allow a better evaluation of rights.

MPEG is aware = that exceptions to representation capability for some aspects of real contracts might appear to be an = obstacle to adoption. However, the technology is flexible by nature to accommodate improvements and extensions in the short and medium = term.

These specifications are of potential interest to broadcasters, together with companies or individuals active in television and cinema production, and = audiovisual products in general, including casual producers, such as for the = so-called =E2=80=9Cuser generated content=E2=80=9D.

Furthermore, audio and video archives, content distributors, providers of media = services and platforms should be clearly also interested, together with all the = companies and organisations which are owners of the rights related to events which = are at the origin of content, such as sports or = festivals.

We believe that = also providers of IT products and/or services for the mentioned professionals = should be interested.

In order to = allow you to get the needed technical guidance for early adoption and use of these standards, and share this within your communities of practice, and to = get the possibility to influence their improvements by means of future = amendments, MPEG is glad to offer this opportunity of = collaboration.

 

=



= --Apple-Mail=_398A8611-AD83-4090-942E-70E4AB1A0458-- --===============0152674878703231813== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============0152674878703231813==-- From new-work-bounces@ietf.org Mon Jun 24 08:08:52 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7FE21F9D9A; Mon, 24 Jun 2013 08:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1372086532; bh=BW5TXfoD1g+Cqe1woMd1uCog9s4U1QE6G/5vScML7VE=; h=Date:From:To:In-Reply-To:References:Message-Id:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=yLh7NwO10J9X5E/rl3SqEOe+nQHZ6vfb0AtqY/xi+pz2EkUxk0rLmUtidqm088Wx+ 0UJsrtUp0jvASrAaFzE54PJ/KyBlWYNOvXIwc0pVSs3zK07m5dZyMTqUDFHfWyvc21 ui1FZZSjA4cI7EBpG7feWw+jZ4TTTIE1TApIyanU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671DE21E80BE for ; Sun, 23 Jun 2013 23:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv8YjMNs4bUt for ; Sun, 23 Jun 2013 23:38:40 -0700 (PDT) Received: from kikaku.itscj.ipsj.or.jp (kikaku.itscj.ipsj.or.jp [210.150.117.162]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD0021E8092 for ; Sun, 23 Jun 2013 23:38:38 -0700 (PDT) Received: from [192.168.1.165] (unknown [218.45.229.2]) by kikaku.itscj.ipsj.or.jp (Postfix) with ESMTP id F1D8E13DC599; Mon, 24 Jun 2013 15:38:34 +0900 (JST) Date: Mon, 24 Jun 2013 15:38:37 +0900 From: WATANABE Shinji To: Tim Berners-Lee In-Reply-To: <9B774119-3B56-4E1B-92B5-CB64B3006BDF@w3.org> References: <20130624150333.9763.544A59DA@itscj.ipsj.or.jp> <9B774119-3B56-4E1B-92B5-CB64B3006BDF@w3.org> Message-Id: <20130624153833.9767.544A59DA@itscj.ipsj.or.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.65.02 [ja] X-Mailman-Approved-At: Mon, 24 Jun 2013 08:08:50 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 24 Jun 2013 08:10:40 -0700 Cc: W3C Liaisons team , Chris Lilley , jc@dufourd.org, leonardo@chiariglione.org, yklwhite@gmail.com, new-work@ietf.org, sc29-sec@itscj.ipsj.or.jp Subject: Re: [secdir] [new-work] MPEG-21 Contract Expression Language and Media Contract Ontology Re: Liaison Statement to W3C (SC 29 N 13458) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:08:52 -0000 Dear Mr. Tim, Thank you for your response. I'll send a copy to W3C Liaisons address ( team-liaisons@w3.org ) on sending Liaison Statement in future. Best Regards, Shinji Watanabe Assistant Secretary, ISO/IEC JTC 1/SC 29 ----- WATANABE Shinji Assistant Secretary, ISO/IEC JTC 1/SC 29 IPSJ/ITSCJ 308-3 Kikai-Shinko-Kaikan Bldg. 3-5-8 Shiba-koen, Minato-ku, Tokyo 105-0011 Japan Tel: +81-3-3431-2808 Fax: +81-3-3431-6493 Mail: watanabe@itscj.ipsj.or.jp On Mon, 24 Jun 2013 08:33:09 +0200 Tim Berners-Lee wrote: > Dear Mr Watanabe, > > Than you for your message alerting us to new work on > Contract Expression Language and a Media Contract Ontology > being developed by SC29. > > Please copy W3C Liaisons (as above) on future similar > correspondence. > > Best Wishes > > Tim Berners-Lee > Director W3C > > > On 2013-06 -24, at 08:03, WATANABE Shinji wrote: > > > Dear Mr. Tim Berners-Lee, > > > > In accordance with Resolutions taken at the 104th > > SC 29/WG 11 Meeting, 2013-04-22/26, Incheon, Korea, > > I am pleased to send attached Liaison statement > > to W3C Web and TV Interest Group and Privacy Interest Group. > > > > If you have any questions, please do not hesitate to contact me. > > Thank you for your cooperation. > > > > > > Best Regards, > > Shinji Watanabe > > Assistant Secretary, ISO/IEC JTC 1/SC 29 > > > > ----- > > WATANABE Shinji > > Assistant Secretary, ISO/IEC JTC 1/SC 29 > > IPSJ/ITSCJ > > 308-3 Kikai-Shinko-Kaikan Bldg. > > 3-5-8 Shiba-koen, Minato-ku, Tokyo 105-0011 Japan > > Tel: +81-3-3431-2808 Fax: +81-3-3431-6493 > > Mail: watanabe@itscj.ipsj.or.jp > > <29n13458.zip> > > > ISO/IEC JTC 1/SC 29 N 13458 > DATE: 2013-06-24 > > > ISO/IEC JTC 1/SC 29 > Coding of Audio, Picture, Multimedia and Hypermedia Information > Secretariat: Japan (JISC) > DOC. TYPE Outgoing Liaison Statement > TITLE Liaison Statement from SC 29/WG 11 on MPEG-21 Contract Expression Language and Media Contract Ontology [SC 29/WG 11 N 13544] > SOURCE ISO/IEC JTC 1/SC 29/WG 11 > PROJECT > STATUS In accordance with Resolutions taken at the 104th SC 29/WG 11 Meeting, 2013-04-22/26, Incheon, Korea, the SC 29 Secretariat forwarded this liaison statement to WIPO, EBU, ABU, NABA, AIR-IAB, AUB-UAR, ASBU, ACT and W3C. [Requested action: For SC 29's information] > ACTION ID FYI > DUE DATE > DISTRIBUTION P, O and L Members of ISO/IEC JTC 1/SC 29 ; ISO/IEC JTC 1 Secretariat; ISO/IEC ITTF > ACCESS LEVEL Def > ISSUE NO. 1447 > FILE > NAME > SIZE (KB) > PAGES > 29n13458c.htm 29n134581.doc > 78.3 > 2 > > Secretariat ISO/IEC JTC 1/SC 29 - IPSJ/ITSCJ (Information Processing Society of Japan/Information Technology Standards Commission of Japan)* Room 308-3, Kikai-Shinko-Kaikan Bldg., 3-5-8, Shiba-Koen, Minato-ku, Tokyo 105-0011 Japan *Standard Organization Accredited by JISC > Telephone: +81-3-3431-2808; Facsimile: +81-3-3431-6493; E-mail: sc29-sec @ itscj.ipsj.or.jp > > > Liaison Statement from WG 11 on CEL & MCO > > > > > INTERNATIONAL ORGANISATION FOR STANDARDISATION > > ORGANISATION INTERNATIONALE DE NORMALISATION > > ISO/IEC JTC1/SC29/WG11 > > CODING OF MOVING PICTURES AND AUDIO > > > > ISO/IEC JTC1/SC29/WG11 N13544 > > April 2013, Incheon, Korea > > > > Source: Convenor > Title: Liaison statement on MPEG-21 Contract Expression Language and Media Contract Ontology > > > > > > > > ISO/IEC JTC1/SC29/WG11 (MPEG) is pleased to inform you that the MPEG-21 suite of standards is about to be enriched with two new standards related to representing information of contracts on media content. > > In particular, the standards support the following aspects: > > ? Identification of the contract and of possible relations with pre-existing contracts. > ? Identification of the parties and signatories (with signatures). > ? Identification of the object of the contract. > ? Unambiguous representation of the agreed terms and conditions. > ? Possibility to encrypt the whole contract or parts of it. > > > ISO/IEC 21000-20 Contract Expression Language provides the XML structure representation of the contract. > > ISO/IEC 21000-21 Media Contract Ontology provides the OWL semantic representation of the contract. > > Prompt adoption of those standards would foster clarity and improve efficiency in the audio-visual rights market, while speed and certainty in rights management would make more content accessible to end users and would allow a better evaluation of rights. > > MPEG is aware that exceptions to representation capability for some aspects of real contracts might appear to be an obstacle to adoption. However, the technology is flexible by nature to accommodate improvements and extensions in the short and medium term. > > These specifications are of potential interest to broadcasters, together with companies or individuals active in television and cinema production, and audiovisual products in general, including casual producers, such as for the so-called $B!H(Buser generated content$B!I(B. > > Furthermore, audio and video archives, content distributors, providers of media services and platforms should be clearly also interested, together with all the companies and organisations which are owners of the rights related to events which are at the origin of content, such as sports or festivals. > > We believe that also providers of IT products and/or services for the mentioned professionals should be interested. > > In order to allow you to get the needed technical guidance for early adoption and use of these standards, and share this within your communities of practice, and to get the possibility to influence their improvements by means of future amendments, MPEG is glad to offer this opportunity of collaboration. > > > > > > _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From mthornbu@adobe.com Mon Jun 24 11:32:56 2013 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 628DB21F9FDF; Mon, 24 Jun 2013 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URGNWuYBQW3f; Mon, 24 Jun 2013 11:32:50 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7361C11E8151; Mon, 24 Jun 2013 11:32:43 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUciQuOeCgAFXBZrMWqO69BVs3xr7Qoih@postini.com; Mon, 24 Jun 2013 11:32:49 PDT Received: from inner-relay-2.corp.adobe.com (mail-321.eur.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r5OIWNAI012991; Mon, 24 Jun 2013 11:32:23 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r5OIWMw7003658; Mon, 24 Jun 2013 11:32:22 -0700 (PDT) Received: from nambx08.corp.adobe.com ([10.8.189.94]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 24 Jun 2013 11:32:21 -0700 From: Michael Thornburgh To: Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" Date: Mon, 24 Jun 2013 11:32:17 -0700 Thread-Topic: Security review of draft-thornburgh-adobe-rtmfp-07 Thread-Index: Ac5uoc9EkpeNgwZsQ1iEivSzWkn/zwAJgxpg Message-ID: References: <201306211705.r5LH5Qf2025408@sylvester.rhmr.com> In-Reply-To: <201306211705.r5LH5Qf2025408@sylvester.rhmr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 24 Jun 2013 14:09:16 -0700 Cc: "draft-thornburgh-adobe-rtmfp@tools.ietf.org" Subject: Re: [secdir] Security review of draft-thornburgh-adobe-rtmfp-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: Mon, 24 Jun 2013 18:32:56 -0000 hi Hilarie. thanks for your review. comments/replies inline. > From: Hilarie Orman [mailto:hilarie@purplestreak.com] > Sent: Friday, June 21, 2013 10:05 AM >=20 > Security review of > Adobe's Secure Real-Time Media Flow Protocol > draft-thornburgh-adobe-rtmfp-07 >=20 > 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. >=20 > This is an informational RFC describing an existing Adobe protocol. > It has the feature of allowing sessions to change their IP addresses > and to use forwarders to help in NAT traversal. >=20 > The draft does not specify the cryptographics requirements and > processing in enough detail to facilitate interoperable > implementations, and I don't recommend advancing it. this draft describes a generic framework of cryptographic operational seman= tics with requirements and recommendations. the generic framework is a com= mon part of RTMFP and belongs in this specification. specific cryptography= choices are left to applications/profiles of RTMFP. the intention is that= application-level interoperation would be achieved using this specificatio= n and a specification of the application-specific Cryptography Profile; for= example, a specification describing the Cryptography Profile to be used fo= r Flash platform communication. > The draft generically specifies the cryptographic features that would > provide privacy and authentication. All specifics are left to the > implementor. The cryptographic profiles could be trivial (rot13 and > casting out nines, for example). correct. for testing/development of the RTMFP implementation used in Adobe'= s products, i created a "Null Crypto Adapter" implementing (NOT RECOMMENDED= ) straight-copy for the "Packet Encryption" function, and a trivial session= -specific key to salt a simple checksum for "data integrity". this profile= /adapter met the semantic requirements of a Cryptography Profile but was no= t suitable for any circumstance where actual aspects of security were desir= ed. however, it made debugging using a packet sniffer a lot easier! > How is the cryptographic profile specified? Is there only one, to be > used by all implementations RTMFP? If not, how do two implementations > agree on which profile they will use? a Cryptography Profile would be specified in another document. the intenti= on is that there could be different Cryptography Profiles for different app= lications or uses of RTMFP. there is one defined for Flash platform commun= ication, which has features uniquely tailored to the Flash ecosystem; howev= er, specifics of this are unfortunately not currently publicly disclosed. = i agree that it would be valuable to have this profile available as a concr= ete example; however, i don't have permission to publish it at this time. = i considered designing a new cryptography profile to use as an example, but= it would have no real-world implementation or deployment experience behind= it and would not have the benefit of the years of refinement and experienc= e we have with the Flash profile. publishing such an example would probabl= y encourage people to implement it, even though it could have serious flaws= . i concluded that creating a new example profile was a bad idea. > How is the "default session key" selected? The text mentions the > possibility of multiple default keys. In "Security Considerations": > ... to allow for different applications of RTMFP using different > Default Session Keys to (intentionally or not) share network > transport addresses without interference. > I don't see how this could work. the Default Session Key is chosen by the designer of the Cryptography Profi= le. for example, in the Flash Crypto Profile, the Default Session Key is t= he 16 bytes of the UTF-8 coded string "Adobe Systems 02" (note: this has be= en widely known for years and is not a secret). these 16 bytes form the ra= w key for AES-128-CBC, which is the default (and currently only) cipher use= d in the Flash Crypto Profile. as far as two RTMFPs using the same network transport address, think of the= different Default Session Keys as different spread-spectrum spreading code= s. if used with something like AES-128-CBC, then even a "data integrity" c= heck comprising an interior checksum would be enough to reject as corrupt a= packet using the wrong Default Session Key. > What is the algorithm for encrypting with the default session key? > Note that the crypto profile is supposed to determine the keys, but > there is not necessarily an interface that accepts a default key > and produces usable encryption and integrity/authentication keys. the Cryptography Profile also determines the method of encryption (Section = 2.2.3 first sentence). in the case of Flash communication, this method is = AES-128-CBC, and would be fully specified in the "RTMFP for Flash" document= , were it published. > Is there any response for "endpoint discriminator unacceptable"? section 3.5.1.1.2 gives the normative behavior for when an Endpoint Discrim= inator selects the identity of the responder. see sections 3.5.1.4 and 3.5= .1.5 for possible behavior for when an Endpoint Discriminator does not sele= ct the identity of the responder. there are no chunks or other messages to encode "i received an EPD i didn't= like for one reason or another". what to do in this circumstance is inten= tionally not specified and is left to the implementer's discretion. in the= Adobe implementation, an IHello or FIHello with an EPD that doesn't select= the receiver (including because it's malformed) is silently dropped (excep= t in forwarders/redirectors). > I did not see any "MUST" requirements for rejecting data that fails to > pass cryptographic checks. i will add a statement to that effect in Section 2.2.3 3rd paragraph. > How are message integrity and authentication achieved? Is it required? > Section 2.2.3 says: > "The packet encryption layer is responsible for data integrity and > authenticity, for example by means of a checksum or cryptographic > message authentication code." > That does not seem to require that the message integrity be tied to > the Endpoint Discriminator. by "message integrity" i assume you mean "data integrity" in the context of= packets. data integrity is not tied to the EPD. the EPD is a field inter= ior to the packet, which must be tested for integrity before being parsed. = in the sentence you quoted above, i will add "of packets" after "integrity= and authenticity" and before the comma. in general, (packet) data integrity and authenticity is left to the designe= r of the cryptography profile. in the case of Flash communication, this is = achieved using either an (interior) checksum or an (exterior) HMAC, the cho= ice being determined during the IIKeying/RIKeying phase of the startup hand= shake in the respective Keying Components, and in the case of HMAC, the HMA= C key being derived in a manner similar to how the packet encryption key is= derived.=20 > Is there anti-replay prevention? I cannot tell. There are sequence > numbers, but they could be spoofed under some definitions of the > cryptographic profile. anti-replay prevention is part of "data integrity and authenticity". in th= e case of Flash communication, a "Session Sequence Number" can be enabled (= during the IIKeying/RIKeying phases, similar to how HMAC/simple checksum is= selected) to prevent packet replay. i will add a RECOMMENDED about anti-r= eplay in SS2.2.3PP3. flow sequence numbers prevent anti-replay (and enable retransmission) withi= n a current flow; however, an observer could capture a packet that starts a= new flow (using traffic analysis to figure out what packet that was), and = later, after using traffic analysis to infer that flow is concluded, could = replay that packet to potentially start a new flow with the same flow ID (o= r interfere with a new flow with the same ID). i will add something to the= Security Considerations about that, to further make the case for implement= ing packet-level anti-replay. > Section 2.2.2: > "The 32-bit Scrambled Session ID is the 32-bit Session ID modified by > performing a bitwise exclusive-or with the bitwise exclusive-or of > the first two 32-bit words of the encrypted packet." > This is security-by-obscurity and is not worth the trouble. disagree with the characterization of "security-by-obscurity" and that it's= not worth the trouble. the intention is to make every byte of UDP payload= appear to a casual observer (and especially to a meddling middlebox) to be= random noise. RTMFP is intended to be used with a strong cipher (like AES= ), where every ciphertext byte appears pseudorandom. during startup, the S= ession ID is 0, and during the rest of the session it is a fixed non-zero v= alue. without the scrambling operation, there would be a tasty and consist= ent 4-bytes that a middlebox might want to interpret as an IP address or so= mething, or otherwise meddle with. if we XORed with only the first 4 bytes= , then during startup (with SID 0) the first 4 bytes would be the same as t= he second 4 bytes. XORing with two 32-bit words (where those 64 bits are s= trongly pseudorandom in the case of AES) ensures that the first 4 bytes at = least don't match the next 8. note that it's not security-by-obscurity because it's documented. :) note= also that even if it's not worth the trouble, it *is* how this deployed pr= otocol actually works. > The Security Considerations admit that the Default Session Key is such > a weak measure that all messages that use it should be considered to > be sent in the clear. It isn't worth the trouble of using it. disagree. the Security Considerations section states that the Default Sessi= on Key is intended to scramble startup packets to avoid meddling by middleb= oxes, to obscure the content from casual observation, and to act as a sprea= d-spectrum or subchannel code for different RTMFP applications that might b= e sharing a transport channel. this is particularly important because star= tup packets can contain IP addresses and port numbers. i disagree with the= characterization as "admit [...] such a weak measure" -- the Security Cons= iderations states the intent and disclaims (with a "MUST NOT") any security= aspect to it. > There are robust IETF security protocols that could be layered over RTMFP= . true. RTMFP could also be adapted to be encapsulated in DTLS. > I recommend removing all references to cryptography from this > document. disagree. the generic (and intentionally open-ended) cryptographic framewor= k is an essential semantic aspect of the protocol. the normative semantics= described in this document are common to any application of RTMFP. > Hilarie thank you very much. -michael thornburgh From uri@mit.edu Tue Jun 25 05:11:21 2013 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 4AB8011E80AE; Tue, 25 Jun 2013 05:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXmjbZOpI8Cf; Tue, 25 Jun 2013 05:11:15 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7065C21F9F6B; Tue, 25 Jun 2013 05:11:15 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-b1-51c988e2a7c7 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 3E.10.02411.2E889C15; Tue, 25 Jun 2013 08:11:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r5PCBCLt012018; Tue, 25 Jun 2013 08:11:13 -0400 Received: from [192.168.1.108] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r5PCB9FB016433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Jun 2013 08:11:11 -0400 References: <201306211705.r5LH5Qf2025408@sylvester.rhmr.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B329) From: Uri Blumenthal Date: Tue, 25 Jun 2013 08:11:13 -0400 To: Michael Thornburgh X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixCmqrPuo42SgwZEjSha3F/9istj6dxKj xYw/E5ktNt1/yGLxYeFDFgdWj2k/e5g9liz5yeTx8pW4x5fLn9kCWKK4bFJSczLLUov07RK4 Mg5/+8pScD6p4mpvI3MD49qALkZODgkBE4nmxknsELaYxIV769m6GLk4hAT2MUqcuPmLCcLZ yCjx9Mw+dqgMk8TSybvYQFqEBOokTrYfZOli5ODgFRCXuHrQByTMKeAn8XDmXGaQMLOAjsTk hYwgYWYBbYllC18zg9i8AlYSG3/OZAUZySzwkFHi3uU9bBBXyEhs3v4Y7CI2ASWJ5uYtrCC2 sICHxLnvi5hAbBYBVYnjzzeBxUWAhu5b8oh5AqPgLIQrZiFsnoVk8wJG5lWMsim5Vbq5iZk5 xanJusXJiXl5qUW65nq5mSV6qSmlmxhBwc7uorKDsfmQ0iFGAQ5GJR7eGTEnAoVYE8uKK3MP MUpyMCmJ8s5rPxkoxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3UBZQjjclsbIqtSgfJiXNwaIk zit2a2egkEB6YklqdmpqQWoRTFaGg0NJgjcCGNVCgkWp6akVaZk5JQhpJg5OkOE8QMPfgizm LS5IzC3OTIfIn2LU5VixZ+t7RiGWvPy8VClx3jSQQQIgRRmleXBzYEnqFaM40FvCvPkgVTzA BAc36RXQEiagJZNTj4MsKUlESEk1MPqfnPms7tSTKbdOW9fw/I1xLo9s4F40U6bUtvryd62f Kzx8rwcfnfEyQ6jK9kzJ0vgHjrNyfrFn7OvM6GFKsLpwwLrvNkP5WY7lTIItXSv3/ree82Q6 uxrn5Xn3++TqnqXrx704fPD21jMPJU6FTljzdOVb68L9lfc8vdUs4q9GXpV9vsJfu1aJpTgj 0VCLuag4EQBEioV2LQMAAA== Cc: "secdir@ietf.org" , "draft-thornburgh-adobe-rtmfp@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Security review of draft-thornburgh-adobe-rtmfp-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: Tue, 25 Jun 2013 12:11:21 -0000 Leaving alone everything else - there was no better encryption mode for stre= aming data (I assume Flash would be streaming?) than CBC? And what's the pur= pose of encrypting something with a key shared with the entire Universe?=20 I think you're expecting too much from "error discovery" of CBC mode. Also, f= or the last two decades cryptographers insist that the correct way of MACing= is applying outer MAC. Also, especially considering the capabilities of the= later Intel chips, using HMAC after (or before:) encryption is a waste of t= ime - there are fast Authenticated Encryption modes (GCM and OCB, to name a c= ouple). So far I tend to agree with Hillary, and suggest using DTLS. Yours in confusion... Sent from my iPad On Jun 24, 2013, at 14:32, Michael Thornburgh wrote: > hi Hilarie. thanks for your review. comments/replies inline. >=20 >> From: Hilarie Orman [mailto:hilarie@purplestreak.com] >> Sent: Friday, June 21, 2013 10:05 AM >>=20 >> Security review of >> Adobe's Secure Real-Time Media Flow Protocol >> draft-thornburgh-adobe-rtmfp-07 >>=20 >> 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. >>=20 >> This is an informational RFC describing an existing Adobe protocol. >> It has the feature of allowing sessions to change their IP addresses >> and to use forwarders to help in NAT traversal. >>=20 >> The draft does not specify the cryptographics requirements and >> processing in enough detail to facilitate interoperable >> implementations, and I don't recommend advancing it. >=20 > this draft describes a generic framework of cryptographic operational sema= ntics with requirements and recommendations. the generic framework is a com= mon part of RTMFP and belongs in this specification. specific cryptography c= hoices are left to applications/profiles of RTMFP. the intention is that ap= plication-level interoperation would be achieved using this specification an= d a specification of the application-specific Cryptography Profile; for exam= ple, a specification describing the Cryptography Profile to be used for Flas= h platform communication. >=20 >> The draft generically specifies the cryptographic features that would >> provide privacy and authentication. All specifics are left to the >> implementor. The cryptographic profiles could be trivial (rot13 and >> casting out nines, for example). >=20 > correct. for testing/development of the RTMFP implementation used in Adobe= 's products, i created a "Null Crypto Adapter" implementing (NOT RECOMMENDED= ) straight-copy for the "Packet Encryption" function, and a trivial session-= specific key to salt a simple checksum for "data integrity". this profile/a= dapter met the semantic requirements of a Cryptography Profile but was not s= uitable for any circumstance where actual aspects of security were desired. = however, it made debugging using a packet sniffer a lot easier! >=20 >> How is the cryptographic profile specified? Is there only one, to be >> used by all implementations RTMFP? If not, how do two implementations >> agree on which profile they will use? >=20 > a Cryptography Profile would be specified in another document. the intent= ion is that there could be different Cryptography Profiles for different app= lications or uses of RTMFP. there is one defined for Flash platform communi= cation, which has features uniquely tailored to the Flash ecosystem; however= , specifics of this are unfortunately not currently publicly disclosed. i a= gree that it would be valuable to have this profile available as a concrete e= xample; however, i don't have permission to publish it at this time. i cons= idered designing a new cryptography profile to use as an example, but it wou= ld have no real-world implementation or deployment experience behind it and w= ould not have the benefit of the years of refinement and experience we have w= ith the Flash profile. publishing such an example would probably encourage p= eople to implement it, even though it could have serious flaws. i concluded= that creating a new example profile was a bad idea. >=20 >> How is the "default session key" selected? The text mentions the >> possibility of multiple default keys. In "Security Considerations": >> ... to allow for different applications of RTMFP using different >> Default Session Keys to (intentionally or not) share network >> transport addresses without interference. >> I don't see how this could work. >=20 > the Default Session Key is chosen by the designer of the Cryptography Prof= ile. for example, in the Flash Crypto Profile, the Default Session Key is t= he 16 bytes of the UTF-8 coded string "Adobe Systems 02" (note: this has bee= n widely known for years and is not a secret). these 16 bytes form the raw k= ey for AES-128-CBC, which is the default (and currently only) cipher used in= the Flash Crypto Profile. >=20 > as far as two RTMFPs using the same network transport address, think of th= e different Default Session Keys as different spread-spectrum spreading code= s. if used with something like AES-128-CBC, then even a "data integrity" ch= eck comprising an interior checksum would be enough to reject as corrupt a p= acket using the wrong Default Session Key. >=20 >> What is the algorithm for encrypting with the default session key? >> Note that the crypto profile is supposed to determine the keys, but >> there is not necessarily an interface that accepts a default key >> and produces usable encryption and integrity/authentication keys. >=20 > the Cryptography Profile also determines the method of encryption (Section= 2.2.3 first sentence). in the case of Flash communication, this method is A= ES-128-CBC, and would be fully specified in the "RTMFP for Flash" document, w= ere it published. >=20 >> Is there any response for "endpoint discriminator unacceptable"? >=20 > section 3.5.1.1.2 gives the normative behavior for when an Endpoint Discri= minator selects the identity of the responder. see sections 3.5.1.4 and 3.5= .1.5 for possible behavior for when an Endpoint Discriminator does not selec= t the identity of the responder. >=20 > there are no chunks or other messages to encode "i received an EPD i didn'= t like for one reason or another". what to do in this circumstance is inten= tionally not specified and is left to the implementer's discretion. in the A= dobe implementation, an IHello or FIHello with an EPD that doesn't select th= e receiver (including because it's malformed) is silently dropped (except in= forwarders/redirectors). >=20 >> I did not see any "MUST" requirements for rejecting data that fails to >> pass cryptographic checks. >=20 > i will add a statement to that effect in Section 2.2.3 3rd paragraph. >=20 >> How are message integrity and authentication achieved? Is it required? >> Section 2.2.3 says: >> "The packet encryption layer is responsible for data integrity and >> authenticity, for example by means of a checksum or cryptographic >> message authentication code." >> That does not seem to require that the message integrity be tied to >> the Endpoint Discriminator. >=20 > by "message integrity" i assume you mean "data integrity" in the context o= f packets. data integrity is not tied to the EPD. the EPD is a field inter= ior to the packet, which must be tested for integrity before being parsed. i= n the sentence you quoted above, i will add "of packets" after "integrity an= d authenticity" and before the comma. >=20 > in general, (packet) data integrity and authenticity is left to the design= er of the cryptography profile. in the case of Flash communication, this is a= chieved using either an (interior) checksum or an (exterior) HMAC, the choic= e being determined during the IIKeying/RIKeying phase of the startup handsha= ke in the respective Keying Components, and in the case of HMAC, the HMAC ke= y being derived in a manner similar to how the packet encryption key is deri= ved.=20 >=20 >> Is there anti-replay prevention? I cannot tell. There are sequence >> numbers, but they could be spoofed under some definitions of the >> cryptographic profile. >=20 > anti-replay prevention is part of "data integrity and authenticity". in t= he case of Flash communication, a "Session Sequence Number" can be enabled (= during the IIKeying/RIKeying phases, similar to how HMAC/simple checksum is s= elected) to prevent packet replay. i will add a RECOMMENDED about anti-repl= ay in SS2.2.3PP3. >=20 > flow sequence numbers prevent anti-replay (and enable retransmission) with= in a current flow; however, an observer could capture a packet that starts a= new flow (using traffic analysis to figure out what packet that was), and l= ater, after using traffic analysis to infer that flow is concluded, could re= play that packet to potentially start a new flow with the same flow ID (or i= nterfere with a new flow with the same ID). i will add something to the Sec= urity Considerations about that, to further make the case for implementing p= acket-level anti-replay. >=20 >> Section 2.2.2: >> "The 32-bit Scrambled Session ID is the 32-bit Session ID modified by >> performing a bitwise exclusive-or with the bitwise exclusive-or of >> the first two 32-bit words of the encrypted packet." >> This is security-by-obscurity and is not worth the trouble. >=20 > disagree with the characterization of "security-by-obscurity" and that it'= s not worth the trouble. the intention is to make every byte of UDP payload= appear to a casual observer (and especially to a meddling middlebox) to be r= andom noise. RTMFP is intended to be used with a strong cipher (like AES), w= here every ciphertext byte appears pseudorandom. during startup, the Sessio= n ID is 0, and during the rest of the session it is a fixed non-zero value. = without the scrambling operation, there would be a tasty and consistent 4-b= ytes that a middlebox might want to interpret as an IP address or something,= or otherwise meddle with. if we XORed with only the first 4 bytes, then du= ring startup (with SID 0) the first 4 bytes would be the same as the second 4= bytes. XORing with two 32-bit words (where those 64 bits are strongly pseu= dorandom in the case of AES) ensures that the first 4 bytes at least don't m= atch the next 8. >=20 > note that it's not security-by-obscurity because it's documented. :) not= e also that even if it's not worth the trouble, it *is* how this deployed pr= otocol actually works. >=20 >> The Security Considerations admit that the Default Session Key is such >> a weak measure that all messages that use it should be considered to >> be sent in the clear. It isn't worth the trouble of using it. >=20 > disagree. the Security Considerations section states that the Default Sess= ion Key is intended to scramble startup packets to avoid meddling by middleb= oxes, to obscure the content from casual observation, and to act as a spread= -spectrum or subchannel code for different RTMFP applications that might be s= haring a transport channel. this is particularly important because startup p= ackets can contain IP addresses and port numbers. i disagree with the chara= cterization as "admit [...] such a weak measure" -- the Security Considerati= ons states the intent and disclaims (with a "MUST NOT") any security aspect t= o it. >=20 >> There are robust IETF security protocols that could be layered over RTMFP= . >=20 > true. RTMFP could also be adapted to be encapsulated in DTLS. >=20 >> I recommend removing all references to cryptography from this >> document. >=20 > disagree. the generic (and intentionally open-ended) cryptographic framewo= rk is an essential semantic aspect of the protocol. the normative semantics= described in this document are common to any application of RTMFP. >=20 >> Hilarie >=20 > thank you very much. >=20 > -michael thornburgh > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From hallam@gmail.com Tue Jun 25 06:35:30 2013 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 9206121E80AA; Tue, 25 Jun 2013 06:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqF66jqTrkag; Tue, 25 Jun 2013 06:35:29 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5E21E80A8; Tue, 25 Jun 2013 06:35:28 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so756553wiv.11 for ; Tue, 25 Jun 2013 06:35:28 -0700 (PDT) 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=MhTbweCKCpr4O45QgrqGFp79BRI//1MD7U8fzAAYpeQ=; b=fEGs0+WyRiEQCKvbW2NEw60NN5oUnZ1gvCy1BrUuScmmoSu033Bq4o3DovNgUVhMh0 /r48Yhorqu5VR+W44RE9sp57yxCu3EqA3UuwuxnFLjN8c5DKWNU2p4I0+Mdym5iBjbj/ vzd9rX1mG72+QUWHmIb2iD3TbKW0DPD07EL7HKWmRbTE3jKSSIQB7ygs+s1jf3vxOiDS V7zBpkKpxlwwUOrSH259O54oRq2rVZiFMGtyJSquzC+63j5Gt2nfY/Y1bAPk7KEjvkXB AWwsDTyLMbYFH7T4yOKmWnlFzbxuoNG5UHTF8bpFiFs5OLftT8jqt5xsj9fD6OFqB2dQ /NHg== MIME-Version: 1.0 X-Received: by 10.194.240.201 with SMTP id wc9mr12417371wjc.1.1372167327918; Tue, 25 Jun 2013 06:35:27 -0700 (PDT) Received: by 10.194.54.10 with HTTP; Tue, 25 Jun 2013 06:35:27 -0700 (PDT) Date: Tue, 25 Jun 2013 09:35:27 -0400 Message-ID: From: Phillip Hallam-Baker To: "iesg@ietf.org" , IETF Discussion Mailing List , "secdir@ietf.org" , draft-ietf-l2vpn-pbb-vpls-pe-model@ietf.org Content-Type: multipart/alternative; boundary=089e013d1bea27333f04dffa9a9c Subject: [secdir] SECDIR review of draft-ietf-l2vpn-pbb-vpls-pe-model 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, 25 Jun 2013 13:35:30 -0000 --089e013d1bea27333f04dffa9a9c 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. The draft is an informational document describing an architecture for moving packets about based on MAC addresses. While the existence of such architectures and devices is likely relevant to Internet Protocol networking, the draft does not explain how the architecture described is relevant. The draft does not contain a substantive Security Considerations, there is instead a reference: No new security issues are introduced beyond those that are described in [RFC4761 ] and [RFC4762 ]. The references in turn contain references A more comprehensive description of the security issues involved in L2VPNs is covered in [RFC4111 ]. This is a pity if the principle purpose of the document is to explain the differences between IP layer inter-networking and Layer 2 (aka Ethernet layer) networking and the main differences are in the area of security and scalability. One of the main reasons to prefer L2 networking over IP is the dependence certain LAN protocols still have on the use of broadcast techniques. But broadcast techniques are by their very nature unscalable. Given n nodes the cost of broadcast traffic rises as n^2 as every machine on the network has to process the spam from all the rest. >From a security point of view the L2 approach results in a true peered network which has unfortunate effects on security. Absent mechanisms to authenticate network control messages, every additional machine added to the network is an additional potential point of pollution. -- Website: http://hallambaker.com/ --089e013d1bea27333f04dffa9a9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dir= ectorate's ongoing effort to review all IETF documents being processed = by the IESG. These comments were written primarily for the benefit of the s= ecurity area directors. =A0Document editors and WG chairs should treat thes= e comments just like any other last call comments.


The draft is an informational docu= ment describing an architecture for moving packets about based on MAC addre= sses.


While the e= xistence of such architectures and devices is likely relevant to Internet P= rotocol networking, the draft does not explain how the architecture describ= ed is relevant.=A0

The draft does not contain a substantive Se= curity Considerations, there is instead a reference:

=A0 No new = security issues are introduced beyond those that are described
   in [=
RFC4761] and [RFC4762].

The references in turn contain references

   A more comprehensive descri=
ption of the security issues involved in
   L2VPNs is covered in [RFC4111].


This is a pity if the princ= iple purpose of the document is to explain the differences between IP layer= inter-networking and Layer 2 (aka Ethernet layer) networking and the main = differences are in the area of security and scalability.

One of the main reasons to prefer L2 networ= king over IP is the dependence certain LAN protocols still have on the use = of broadcast techniques. But broadcast techniques are by their very nature = unscalable. Given n nodes the cost of broadcast traffic rises as n^2 as eve= ry machine on the network has to process the spam from all the rest.

From a security point of view the L2 approa= ch results in a true peered network which has unfortunate effects on securi= ty. Absent mechanisms to authenticate network control messages, every addit= ional machine added to the network is an additional potential point of poll= ution.



<= br>

--
Website: http://hallambaker.com/
--089e013d1bea27333f04dffa9a9c-- From mthornbu@adobe.com Tue Jun 25 10:29:08 2013 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 4F5C121E8098; Tue, 25 Jun 2013 10:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.144 X-Spam-Level: X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWJjEpzr2-ih; Tue, 25 Jun 2013 10:29:03 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1421E80A8; Tue, 25 Jun 2013 10:28:55 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUcnTRAYKuKT8aPLQ1wz14gjVEeRchp1r@postini.com; Tue, 25 Jun 2013 10:29:02 PDT Received: from inner-relay-2.corp.adobe.com (mail-321.eur.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r5PHSZAI018157; Tue, 25 Jun 2013 10:28:35 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r5PHSYw7021706; Tue, 25 Jun 2013 10:28:34 -0700 (PDT) Received: from nambx08.corp.adobe.com ([10.8.189.94]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Tue, 25 Jun 2013 10:28:34 -0700 From: Michael Thornburgh To: Uri Blumenthal Date: Tue, 25 Jun 2013 10:28:29 -0700 Thread-Topic: [secdir] Security review of draft-thornburgh-adobe-rtmfp-07 Thread-Index: Ac5xnRmcqqtYRGNpQsGqJZc4guAKVQAKNrIw Message-ID: References: <201306211705.r5LH5Qf2025408@sylvester.rhmr.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "secdir@ietf.org" , "draft-thornburgh-adobe-rtmfp@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Security review of draft-thornburgh-adobe-rtmfp-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: Tue, 25 Jun 2013 17:29:08 -0000 > From: Uri Blumenthal [mailto:uri@mit.edu] > Sent: Tuesday, June 25, 2013 5:11 AM >=20 > Leaving alone everything else - there was no better encryption mode for s= treaming data (I assume Flash > would be streaming?) than CBC? And what's the purpose of encrypting somet= hing with a key shared with > the entire Universe? as mentioned in this thread, Section 2.2.3, descriptions of the startup chu= nks, and the Security Considerations of the memo, the Default Session Key i= s used at session startup, during which per-session encryption keys are neg= otiated. also as mentioned in this thread and the Security Considerations,= the startup handshake is encrypted with the Default Session key to scrambl= e startup packets to avoid meddling by middleboxes, to obscure the content = from casual observation, and to act as a spread-spectrum or subchannel code= for different RTMFP applications that might be sharing a transport channel= . > I think you're expecting too much from "error discovery" of CBC mode. Als= o, for the last two decades > cryptographers insist that the correct way of MACing is applying outer MA= C. Also, especially > considering the capabilities of the later Intel chips, using HMAC after (= or before:) encryption is a > waste of time - there are fast Authenticated Encryption modes (GCM and OC= B, to name a couple). in the Flash profile, the MAC is an outer MAC. when HMAC mode is not selec= ted, there is a simple inner checksum. the inner checksum is at least as g= ood as a checksum over a normal unencrypted packet. as far as detecting wh= ether a packet was encrypted with an incorrect key in checksum mode: even i= f the checksum succeeded, the likelihood that the incorrectly decrypted pac= ket could parse correctly even to a first complete and valid chunk is very = low. =20 > So far I tend to agree with Hillary, and suggest using DTLS. >=20 > Yours in confusion... HTH. i invite you to read the entire memo. note that this memo documents = an existing and widely deployed vendor-supplied protocol. note also that t= his memo doesn't describe the cryptography profile used by Flash (including= AES-CBC, HMAC, and anti-replay measures). -michael thornburgh > Sent from my iPad >=20 > On Jun 24, 2013, at 14:32, Michael Thornburgh wrote: >=20 > > hi Hilarie. thanks for your review. comments/replies inline. > > > >> From: Hilarie Orman [mailto:hilarie@purplestreak.com] > >> Sent: Friday, June 21, 2013 10:05 AM > >> > >> Security review of > >> Adobe's Secure Real-Time Media Flow Protocol > >> draft-thornburgh-adobe-rtmfp-07 > >> > >> 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. > >> > >> This is an informational RFC describing an existing Adobe protocol. > >> It has the feature of allowing sessions to change their IP addresses > >> and to use forwarders to help in NAT traversal. > >> > >> The draft does not specify the cryptographics requirements and > >> processing in enough detail to facilitate interoperable > >> implementations, and I don't recommend advancing it. > > > > this draft describes a generic framework of cryptographic operational s= emantics with requirements > and recommendations. the generic framework is a common part of RTMFP and= belongs in this > specification. specific cryptography choices are left to applications/pr= ofiles of RTMFP. the > intention is that application-level interoperation would be achieved usin= g this specification and a > specification of the application-specific Cryptography Profile; for examp= le, a specification > describing the Cryptography Profile to be used for Flash platform communi= cation. > > > >> The draft generically specifies the cryptographic features that would > >> provide privacy and authentication. All specifics are left to the > >> implementor. The cryptographic profiles could be trivial (rot13 and > >> casting out nines, for example). > > > > correct. for testing/development of the RTMFP implementation used in Ad= obe's products, i created a > "Null Crypto Adapter" implementing (NOT RECOMMENDED) straight-copy for th= e "Packet Encryption" > function, and a trivial session-specific key to salt a simple checksum fo= r "data integrity". this > profile/adapter met the semantic requirements of a Cryptography Profile b= ut was not suitable for any > circumstance where actual aspects of security were desired. however, it = made debugging using a packet > sniffer a lot easier! > > > >> How is the cryptographic profile specified? Is there only one, to be > >> used by all implementations RTMFP? If not, how do two implementations > >> agree on which profile they will use? > > > > a Cryptography Profile would be specified in another document. the int= ention is that there could be > different Cryptography Profiles for different applications or uses of RTM= FP. there is one defined for > Flash platform communication, which has features uniquely tailored to the= Flash ecosystem; however, > specifics of this are unfortunately not currently publicly disclosed. i = agree that it would be > valuable to have this profile available as a concrete example; however, i= don't have permission to > publish it at this time. i considered designing a new cryptography profi= le to use as an example, but > it would have no real-world implementation or deployment experience behin= d it and would not have the > benefit of the years of refinement and experience we have with the Flash = profile. publishing such an > example would probably encourage people to implement it, even though it c= ould have serious flaws. i > concluded that creating a new example profile was a bad idea. > > > >> How is the "default session key" selected? The text mentions the > >> possibility of multiple default keys. In "Security Considerations": > >> ... to allow for different applications of RTMFP using different > >> Default Session Keys to (intentionally or not) share network > >> transport addresses without interference. > >> I don't see how this could work. > > > > the Default Session Key is chosen by the designer of the Cryptography P= rofile. for example, in the > Flash Crypto Profile, the Default Session Key is the 16 bytes of the UTF-= 8 coded string "Adobe Systems > 02" (note: this has been widely known for years and is not a secret). th= ese 16 bytes form the raw key > for AES-128-CBC, which is the default (and currently only) cipher used in= the Flash Crypto Profile. > > > > as far as two RTMFPs using the same network transport address, think of= the different Default > Session Keys as different spread-spectrum spreading codes. if used with = something like AES-128-CBC, > then even a "data integrity" check comprising an interior checksum would = be enough to reject as > corrupt a packet using the wrong Default Session Key. > > > >> What is the algorithm for encrypting with the default session key? > >> Note that the crypto profile is supposed to determine the keys, but > >> there is not necessarily an interface that accepts a default key > >> and produces usable encryption and integrity/authentication keys. > > > > the Cryptography Profile also determines the method of encryption (Sect= ion 2.2.3 first sentence). > in the case of Flash communication, this method is AES-128-CBC, and would= be fully specified in the > "RTMFP for Flash" document, were it published. > > > >> Is there any response for "endpoint discriminator unacceptable"? > > > > section 3.5.1.1.2 gives the normative behavior for when an Endpoint Dis= criminator selects the > identity of the responder. see sections 3.5.1.4 and 3.5.1.5 for possible= behavior for when an > Endpoint Discriminator does not select the identity of the responder. > > > > there are no chunks or other messages to encode "i received an EPD i di= dn't like for one reason or > another". what to do in this circumstance is intentionally not specified= and is left to the > implementer's discretion. in the Adobe implementation, an IHello or FIHe= llo with an EPD that doesn't > select the receiver (including because it's malformed) is silently droppe= d (except in > forwarders/redirectors). > > > >> I did not see any "MUST" requirements for rejecting data that fails to > >> pass cryptographic checks. > > > > i will add a statement to that effect in Section 2.2.3 3rd paragraph. > > > >> How are message integrity and authentication achieved? Is it required= ? > >> Section 2.2.3 says: > >> "The packet encryption layer is responsible for data integrity and > >> authenticity, for example by means of a checksum or cryptographic > >> message authentication code." > >> That does not seem to require that the message integrity be tied to > >> the Endpoint Discriminator. > > > > by "message integrity" i assume you mean "data integrity" in the contex= t of packets. data integrity > is not tied to the EPD. the EPD is a field interior to the packet, which= must be tested for integrity > before being parsed. in the sentence you quoted above, i will add "of pa= ckets" after "integrity and > authenticity" and before the comma. > > > > in general, (packet) data integrity and authenticity is left to the des= igner of the cryptography > profile. in the case of Flash communication, this is achieved using eithe= r an (interior) checksum or > an (exterior) HMAC, the choice being determined during the IIKeying/RIKey= ing phase of the startup > handshake in the respective Keying Components, and in the case of HMAC, t= he HMAC key being derived in > a manner similar to how the packet encryption key is derived. > > > >> Is there anti-replay prevention? I cannot tell. There are sequence > >> numbers, but they could be spoofed under some definitions of the > >> cryptographic profile. > > > > anti-replay prevention is part of "data integrity and authenticity". i= n the case of Flash > communication, a "Session Sequence Number" can be enabled (during the IIK= eying/RIKeying phases, > similar to how HMAC/simple checksum is selected) to prevent packet replay= . i will add a RECOMMENDED > about anti-replay in SS2.2.3PP3. > > > > flow sequence numbers prevent anti-replay (and enable retransmission) w= ithin a current flow; > however, an observer could capture a packet that starts a new flow (using= traffic analysis to figure > out what packet that was), and later, after using traffic analysis to inf= er that flow is concluded, > could replay that packet to potentially start a new flow with the same fl= ow ID (or interfere with a > new flow with the same ID). i will add something to the Security Conside= rations about that, to > further make the case for implementing packet-level anti-replay. > > > >> Section 2.2.2: > >> "The 32-bit Scrambled Session ID is the 32-bit Session ID modified b= y > >> performing a bitwise exclusive-or with the bitwise exclusive-or of > >> the first two 32-bit words of the encrypted packet." > >> This is security-by-obscurity and is not worth the trouble. > > > > disagree with the characterization of "security-by-obscurity" and that = it's not worth the trouble. > the intention is to make every byte of UDP payload appear to a casual obs= erver (and especially to a > meddling middlebox) to be random noise. RTMFP is intended to be used wit= h a strong cipher (like AES), > where every ciphertext byte appears pseudorandom. during startup, the Se= ssion ID is 0, and during the > rest of the session it is a fixed non-zero value. without the scrambling= operation, there would be a > tasty and consistent 4-bytes that a middlebox might want to interpret as = an IP address or something, > or otherwise meddle with. if we XORed with only the first 4 bytes, then = during startup (with SID 0) > the first 4 bytes would be the same as the second 4 bytes. XORing with t= wo 32-bit words (where those > 64 bits are strongly pseudorandom in the case of AES) ensures that the fi= rst 4 bytes at least don't > match the next 8. > > > > note that it's not security-by-obscurity because it's documented. :) = note also that even if it's > not worth the trouble, it *is* how this deployed protocol actually works. > > > >> The Security Considerations admit that the Default Session Key is such > >> a weak measure that all messages that use it should be considered to > >> be sent in the clear. It isn't worth the trouble of using it. > > > > disagree. the Security Considerations section states that the Default S= ession Key is intended to > scramble startup packets to avoid meddling by middleboxes, to obscure the= content from casual > observation, and to act as a spread-spectrum or subchannel code for diffe= rent RTMFP applications that > might be sharing a transport channel. this is particularly important bec= ause startup packets can > contain IP addresses and port numbers. i disagree with the characterizat= ion as "admit [...] such a > weak measure" -- the Security Considerations states the intent and discla= ims (with a "MUST NOT") any > security aspect to it. > > > >> There are robust IETF security protocols that could be layered over RT= MFP. > > > > true. RTMFP could also be adapted to be encapsulated in DTLS. > > > >> I recommend removing all references to cryptography from this > >> document. > > > > disagree. the generic (and intentionally open-ended) cryptographic fram= ework is an essential > semantic aspect of the protocol. the normative semantics described in th= is document are common to any > application of RTMFP. > > > >> Hilarie > > > > thank you very much. > > > > -michael thornburgh > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From mthornbu@adobe.com Tue Jun 25 11:50:10 2013 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 3FD4011E813B for ; Tue, 25 Jun 2013 11:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEkk52sKJqa8 for ; Tue, 25 Jun 2013 11:50:03 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 79FE911E8134 for ; Tue, 25 Jun 2013 11:49:48 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUcnmPENsjwtwOriIyr3iAMolOFxeb//Q@postini.com; Tue, 25 Jun 2013 11:49:59 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r5PIkAD8009047; Tue, 25 Jun 2013 11:46:10 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r5PInTw7026706; Tue, 25 Jun 2013 11:49:29 -0700 (PDT) Received: from nambx08.corp.adobe.com ([10.8.189.94]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Tue, 25 Jun 2013 11:49:29 -0700 From: Michael Thornburgh To: Hilarie Orman , "secdir@ietf.org" Date: Tue, 25 Jun 2013 11:49:27 -0700 Thread-Topic: Security review of draft-thornburgh-adobe-rtmfp-07 Thread-Index: Ac5uoc9EkpeNgwZsQ1iEivSzWkn/zwAJgxpgAMMHnjA= Message-ID: References: <201306211705.r5LH5Qf2025408@sylvester.rhmr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rs@netapp.com" , "draft-thornburgh-adobe-rtmfp@tools.ietf.org" , Martin Stiemerling Subject: Re: [secdir] Security review of draft-thornburgh-adobe-rtmfp-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: Tue, 25 Jun 2013 18:50:10 -0000 hi Hilarie, Security Directorate folks. (note i dropped IESG from the CC l= ist because i already sent a note there) i have uploaded a new revision -08 of this draft that addresses comments ra= ised during the IETF Last Call, including some of those raised in this thre= ad. thank you for helping to improve the quality of this document. -michael thornburgh > From: Michael Thornburgh > Sent: Monday, June 24, 2013 11:32 AM > =09 > hi Hilarie. thanks for your review. comments/replies inline. >=20 > > From: Hilarie Orman [mailto:hilarie@purplestreak.com] > > Sent: Friday, June 21, 2013 10:05 AM > > > > Security review of > > Adobe's Secure Real-Time Media Flow Protocol > > draft-thornburgh-adobe-rtmfp-07 > > > > 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. > > > > This is an informational RFC describing an existing Adobe protocol. > > It has the feature of allowing sessions to change their IP addresses > > and to use forwarders to help in NAT traversal. > > > > The draft does not specify the cryptographics requirements and > > processing in enough detail to facilitate interoperable > > implementations, and I don't recommend advancing it. >=20 > this draft describes a generic framework of cryptographic operational sem= antics with requirements and > recommendations. the generic framework is a common part of RTMFP and bel= ongs in this specification. > specific cryptography choices are left to applications/profiles of RTMFP.= the intention is that > application-level interoperation would be achieved using this specificati= on and a specification of the > application-specific Cryptography Profile; for example, a specification d= escribing the Cryptography > Profile to be used for Flash platform communication. >=20 > > The draft generically specifies the cryptographic features that would > > provide privacy and authentication. All specifics are left to the > > implementor. The cryptographic profiles could be trivial (rot13 and > > casting out nines, for example). >=20 > correct. for testing/development of the RTMFP implementation used in Adob= e's products, i created a > "Null Crypto Adapter" implementing (NOT RECOMMENDED) straight-copy for th= e "Packet Encryption" > function, and a trivial session-specific key to salt a simple checksum fo= r "data integrity". this > profile/adapter met the semantic requirements of a Cryptography Profile b= ut was not suitable for any > circumstance where actual aspects of security were desired. however, it = made debugging using a packet > sniffer a lot easier! >=20 > > How is the cryptographic profile specified? Is there only one, to be > > used by all implementations RTMFP? If not, how do two implementations > > agree on which profile they will use? >=20 > a Cryptography Profile would be specified in another document. the inten= tion is that there could be > different Cryptography Profiles for different applications or uses of RTM= FP. there is one defined for > Flash platform communication, which has features uniquely tailored to the= Flash ecosystem; however, > specifics of this are unfortunately not currently publicly disclosed. i = agree that it would be > valuable to have this profile available as a concrete example; however, i= don't have permission to > publish it at this time. i considered designing a new cryptography profi= le to use as an example, but > it would have no real-world implementation or deployment experience behin= d it and would not have the > benefit of the years of refinement and experience we have with the Flash = profile. publishing such an > example would probably encourage people to implement it, even though it c= ould have serious flaws. i > concluded that creating a new example profile was a bad idea. >=20 > > How is the "default session key" selected? The text mentions the > > possibility of multiple default keys. In "Security Considerations": > > ... to allow for different applications of RTMFP using different > > Default Session Keys to (intentionally or not) share network > > transport addresses without interference. > > I don't see how this could work. >=20 > the Default Session Key is chosen by the designer of the Cryptography Pro= file. for example, in the > Flash Crypto Profile, the Default Session Key is the 16 bytes of the UTF-= 8 coded string "Adobe Systems > 02" (note: this has been widely known for years and is not a secret). th= ese 16 bytes form the raw key > for AES-128-CBC, which is the default (and currently only) cipher used in= the Flash Crypto Profile. >=20 > as far as two RTMFPs using the same network transport address, think of t= he different Default Session > Keys as different spread-spectrum spreading codes. if used with somethin= g like AES-128-CBC, then even > a "data integrity" check comprising an interior checksum would be enough = to reject as corrupt a packet > using the wrong Default Session Key. >=20 > > What is the algorithm for encrypting with the default session key? > > Note that the crypto profile is supposed to determine the keys, but > > there is not necessarily an interface that accepts a default key > > and produces usable encryption and integrity/authentication keys. >=20 > the Cryptography Profile also determines the method of encryption (Sectio= n 2.2.3 first sentence). in > the case of Flash communication, this method is AES-128-CBC, and would be= fully specified in the > "RTMFP for Flash" document, were it published. >=20 > > Is there any response for "endpoint discriminator unacceptable"? >=20 > section 3.5.1.1.2 gives the normative behavior for when an Endpoint Discr= iminator selects the identity > of the responder. see sections 3.5.1.4 and 3.5.1.5 for possible behavior= for when an Endpoint > Discriminator does not select the identity of the responder. >=20 > there are no chunks or other messages to encode "i received an EPD i didn= 't like for one reason or > another". what to do in this circumstance is intentionally not specified= and is left to the > implementer's discretion. in the Adobe implementation, an IHello or FIHe= llo with an EPD that doesn't > select the receiver (including because it's malformed) is silently droppe= d (except in > forwarders/redirectors). >=20 > > I did not see any "MUST" requirements for rejecting data that fails to > > pass cryptographic checks. >=20 > i will add a statement to that effect in Section 2.2.3 3rd paragraph. >=20 > > How are message integrity and authentication achieved? Is it required? > > Section 2.2.3 says: > > "The packet encryption layer is responsible for data integrity and > > authenticity, for example by means of a checksum or cryptographic > > message authentication code." > > That does not seem to require that the message integrity be tied to > > the Endpoint Discriminator. >=20 > by "message integrity" i assume you mean "data integrity" in the context = of packets. data integrity > is not tied to the EPD. the EPD is a field interior to the packet, which= must be tested for integrity > before being parsed. in the sentence you quoted above, i will add "of pa= ckets" after "integrity and > authenticity" and before the comma. >=20 > in general, (packet) data integrity and authenticity is left to the desig= ner of the cryptography > profile. in the case of Flash communication, this is achieved using eithe= r an (interior) checksum or > an (exterior) HMAC, the choice being determined during the IIKeying/RIKey= ing phase of the startup > handshake in the respective Keying Components, and in the case of HMAC, t= he HMAC key being derived in > a manner similar to how the packet encryption key is derived. >=20 > > Is there anti-replay prevention? I cannot tell. There are sequence > > numbers, but they could be spoofed under some definitions of the > > cryptographic profile. >=20 > anti-replay prevention is part of "data integrity and authenticity". in = the case of Flash > communication, a "Session Sequence Number" can be enabled (during the IIK= eying/RIKeying phases, > similar to how HMAC/simple checksum is selected) to prevent packet replay= . i will add a RECOMMENDED > about anti-replay in SS2.2.3PP3. >=20 > flow sequence numbers prevent anti-replay (and enable retransmission) wit= hin a current flow; however, > an observer could capture a packet that starts a new flow (using traffic = analysis to figure out what > packet that was), and later, after using traffic analysis to infer that f= low is concluded, could > replay that packet to potentially start a new flow with the same flow ID = (or interfere with a new flow > with the same ID). i will add something to the Security Considerations a= bout that, to further make > the case for implementing packet-level anti-replay. >=20 > > Section 2.2.2: > > "The 32-bit Scrambled Session ID is the 32-bit Session ID modified b= y > > performing a bitwise exclusive-or with the bitwise exclusive-or of > > the first two 32-bit words of the encrypted packet." > > This is security-by-obscurity and is not worth the trouble. >=20 > disagree with the characterization of "security-by-obscurity" and that it= 's not worth the trouble. > the intention is to make every byte of UDP payload appear to a casual obs= erver (and especially to a > meddling middlebox) to be random noise. RTMFP is intended to be used wit= h a strong cipher (like AES), > where every ciphertext byte appears pseudorandom. during startup, the Se= ssion ID is 0, and during the > rest of the session it is a fixed non-zero value. without the scrambling= operation, there would be a > tasty and consistent 4-bytes that a middlebox might want to interpret as = an IP address or something, > or otherwise meddle with. if we XORed with only the first 4 bytes, then = during startup (with SID 0) > the first 4 bytes would be the same as the second 4 bytes. XORing with t= wo 32-bit words (where those > 64 bits are strongly pseudorandom in the case of AES) ensures that the fi= rst 4 bytes at least don't > match the next 8. >=20 > note that it's not security-by-obscurity because it's documented. :) no= te also that even if it's not > worth the trouble, it *is* how this deployed protocol actually works. >=20 > > The Security Considerations admit that the Default Session Key is such > > a weak measure that all messages that use it should be considered to > > be sent in the clear. It isn't worth the trouble of using it. >=20 > disagree. the Security Considerations section states that the Default Ses= sion Key is intended to > scramble startup packets to avoid meddling by middleboxes, to obscure the= content from casual > observation, and to act as a spread-spectrum or subchannel code for diffe= rent RTMFP applications that > might be sharing a transport channel. this is particularly important bec= ause startup packets can > contain IP addresses and port numbers. i disagree with the characterizat= ion as "admit [...] such a > weak measure" -- the Security Considerations states the intent and discla= ims (with a "MUST NOT") any > security aspect to it. >=20 > > There are robust IETF security protocols that could be layered over RTM= FP. >=20 > true. RTMFP could also be adapted to be encapsulated in DTLS. >=20 > > I recommend removing all references to cryptography from this > > document. >=20 > disagree. the generic (and intentionally open-ended) cryptographic framew= ork is an essential semantic > aspect of the protocol. the normative semantics described in this docume= nt are common to any > application of RTMFP. >=20 > > Hilarie >=20 > thank you very much. >=20 > -michael thornburgh From shawn.emery@oracle.com Wed Jun 26 01:11:37 2013 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 9A8F121E80CD; Wed, 26 Jun 2013 01:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7e1X-G2zo6h; Wed, 26 Jun 2013 01:11:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1106E21E8064; Wed, 26 Jun 2013 01:11:20 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5Q8BIu2020084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jun 2013 08:11:19 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5Q8BGPx017691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 08:11:17 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5Q8BGtg001187; Wed, 26 Jun 2013 08:11:16 GMT Received: from [10.159.121.201] (/10.159.121.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Jun 2013 01:11:16 -0700 Message-ID: <51CAA254.6040303@oracle.com> Date: Wed, 26 Jun 2013 02:12:04 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: secdir@ietf.org References: <519097A8.40409@oracle.com> In-Reply-To: <519097A8.40409@oracle.com> X-Forwarded-Message-Id: <519097A8.40409@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-xrblock-rtcp-xr-jb-12 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, 26 Jun 2013 08:11:37 -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 internet-draft specifies a RTP Control Protocol (RTCP) Extended Report (XR) Block for data on jitter buffer configuration and performance. The security considerations section does exist and states that the new block data does not introduce any additional security concerns than those stated in the base XR spec, RFC 3611. I believe this to be an accurate assertion. General comments: I found the draft slightly hard to read, as the terminology and abbreviations used are not expanded. For example, the abstract has "RTP", but never expands the abbreviation. Editorial comments: s/[RFC6390]and/[RFC6390] and/ Shawn. -- From bill.wu@huawei.com Wed Jun 26 02:46:32 2013 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 8F88F21F9A64; Wed, 26 Jun 2013 02:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6qaFDUAeWbL; Wed, 26 Jun 2013 02:46:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 03A0321E8106; Wed, 26 Jun 2013 02:46:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASW23557; Wed, 26 Jun 2013 09:46:24 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 26 Jun 2013 10:45:28 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 26 Jun 2013 10:46:10 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Wed, 26 Jun 2013 17:46:06 +0800 From: Qin Wu To: Shawn M Emery , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-xrblock-rtcp-xr-jb-12 Thread-Index: AQHOckTd96glCg6T/0ypV8ToJGuOoplHvkQg Date: Wed, 26 Jun 2013 09:46:05 +0000 Message-ID: References: <519097A8.40409@oracle.com> <51CAA254.6040303@oracle.com> In-Reply-To: <51CAA254.6040303@oracle.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-xrblock-rtcp-xr-jb-12 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, 26 Jun 2013 09:46:32 -0000 Hi,Shawn: Thank for your comments, my reply is inline below. Regards! -Qin -----Original Message----- From: Shawn M Emery [mailto:shawn.emery@oracle.com]=20 Sent: Wednesday, June 26, 2013 4:12 PM To: secdir@ietf.org Cc: draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org; iesg@ietf.org Subject: Review of draft-ietf-xrblock-rtcp-xr-jb-12 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 internet-draft specifies a RTP Control Protocol (RTCP) Extended Report (XR) Block for data on jitter buffer configuration and performance. The security considerations section does exist and states that the new bloc= k data does not introduce any additional security concerns than those stated in the base XR spec, RFC 3611. I believe this to be an accurate assertion. General comments: I found the draft slightly hard to read, as the terminology and abbreviatio= ns used are not expanded. For example, the abstract has "RTP", but never expa= nds the abbreviation. [Qin]; RTP is abbreviation of "A Transport Protocol for Real-Time Applicat= ions" and defined In the basic RTP protocol specification [RFC3550], it is the basic atom we = are used=20 in the context of this draft and can not be decomposed.For other term and a= bbreviation, I will check and fix that, thanks. Editorial comments: s/[RFC6390]and/[RFC6390] and/ [Qin]:okay.Thanks! Shawn. -- From stephen.farrell@cs.tcd.ie Wed Jun 26 03:15:00 2013 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 6EA3D21E812A for ; Wed, 26 Jun 2013 03:15:00 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orfMopfxG5A5 for ; Wed, 26 Jun 2013 03:14:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C583121E8123 for ; Wed, 26 Jun 2013 03:14:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A84C2BECF for ; Wed, 26 Jun 2013 11:14:33 +0100 (IST) 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 b1+t6H-YHy9Q for ; Wed, 26 Jun 2013 11:14:33 +0100 (IST) Received: from [IPv6:2001:770:10:203:f41a:f073:48c6:77b5] (unknown [IPv6:2001:770:10:203:f41a:f073:48c6:77b5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B666BE70 for ; Wed, 26 Jun 2013 11:14:33 +0100 (IST) Message-ID: <51CABF09.5050107@cs.tcd.ie> Date: Wed, 26 Jun 2013 11:14:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "secdir@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA1AEEC7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1AEEC7@AZ-FFEXMB04.global.avaya.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <9904FB1B0159DA42B0B887B7FA8119CA1AEEC7@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Fwd: RE: Stephen Farrell's No Objection on draft-ietf-xrblock-rtcp-xr-discard-14: (with COMMENT) 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, 26 Jun 2013 10:15:00 -0000 Anyone interested in thinking about whether there might be side-channels caused by xrblock? [1] Or even in just giving them a general presentation on side-channels to help 'em figure out if they think there's an issue or not? Once the meeting schedule is firmed up I'll maybe ask on saag but if someone here is interested in helping 'em just let me know. Ta, S. [1] http://tools.ietf.org/wg/xrblock/charters -------- Original Message -------- Subject: RE: Stephen Farrell's No Objection on draft-ietf-xrblock-rtcp-xr-discard-14: (with COMMENT) Date: Wed, 26 Jun 2013 10:06:00 +0000 From: Romascanu, Dan (Dan) To: Stephen Farrell , The IESG CC: xrblock-chairs@tools.ietf.org , draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org Hi, If this is a generic problem that can possibly impact several xrblock documents, maybe we can have a security expert (a.k.a. co-ponderer) attend the XRBLOCK meeting and discuss the issue with us. We seem to have a pretty light wg agenda in Berlin, so it won't be a problem to find time on it. Thanks and Regards, Dan > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, June 25, 2013 8:01 PM > To: The IESG > Cc: xrblock-chairs@tools.ietf.org; draft-ietf-xrblock-rtcp-xr- > discard@tools.ietf.org > Subject: Stephen Farrell's No Objection on draft-ietf-xrblock-rtcp-xr- > discard-14: (with COMMENT) > > Stephen Farrell has entered the following ballot position for > draft-ietf-xrblock-rtcp-xr-discard-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Sam Hartman's secdir review [1] of xr-discard-rle-metrics raised a good > question that's probably better asked here, or here as well. I'm not > asking for any change in this or any specific xrblock document, but I > would ask that the WG do consider this. Sam said: > > "Has the WG analyzed implications of providing feedback to an attacker > on what specific SRTP packets are discarded? In the past we've run into > trouble with security systems that were too verbose in error reporting. > As an example, in certain public-key crypto constructions knowing > whether a packet produced a decoding error vs a signature error after > decryption can provide an attacker generating forged packets valuable > information to attack the system. > > It's quite possible that SRTP doesn't have problems in this regard. I > just want to confirm that the analysis has been done." > > I think that's a good question because knowing at what stage in a > security protocol a message was barfed or getting timing statistics can > expose information about how some crypto operation went wrong, and that > can be exploited via statistical techniques with a sufficiently large > number of messages. See for example the lucky-13 attacks against > certain cryptographic modes in TLS [2] or perhaps the "original" of the > species, the Bleichenbacher attack. [3] > > I suspect the best thing to do might be for the wg to try grab a > security person and ponder this for a bit, if that's not already been > done. I'm happy to try help find a co-ponderer if you want:-) Maybe we > can ambush one in a hallway in Berlin. > > [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04048.html > [2] http://www.isg.rhul.ac.uk/tls/Lucky13.html > [3] https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack > From uri@mit.edu Wed Jun 26 05:14:46 2013 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 7E0FE21F9C79 for ; Wed, 26 Jun 2013 05:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j-aFv2QyOmJ for ; Wed, 26 Jun 2013 05:14:41 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0F921F9C3D for ; Wed, 26 Jun 2013 05:14:40 -0700 (PDT) X-AuditID: 12074425-b7f0c8e000000953-b3-51cadb2e5018 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 76.50.02387.E2BDAC15; Wed, 26 Jun 2013 08:14:38 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r5QCEaJs009752; Wed, 26 Jun 2013 08:14:37 -0400 Received: from [192.168.1.105] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r5QCEXl1024543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 26 Jun 2013 08:14:35 -0400 References: <9904FB1B0159DA42B0B887B7FA8119CA1AEEC7@AZ-FFEXMB04.global.avaya.com> <51CABF09.5050107@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <51CABF09.5050107@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10B329) From: Uri Blumenthal Date: Wed, 26 Jun 2013 08:14:35 -0400 To: Stephen Farrell X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixG6nrqt3+1SgwY5v+hYfFj5ksZi+9xq7 A5PH2u6rbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4cqa84KZyxeszM1kaGFfKdjFyckgImEj8 OLaMGcIWk7hwbz1bFyMXh5DAPkaJyV/fs4MkhAQ2Mko8XOUGlWCSaNo7mwkikSdxbcUx1i5G Dg5eAXGJqwd9QMKcApoSk961sYCEmQV0JCYvZAQJMwvIS2x/OwdsF6+AlcSELpBdIHF1iTf3 V7NB3CAjsXn7Y7C1bAJKEs3NW1hBbGGBMon9j5+DjWQRUJXY2WsAEhYR0JfYu/kc+wRGwVkI N8xC2DsLyd4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcxgoPWRXUH44RD SocYBTgYlXh4FbaeDBRiTSwrrsw9xCjJwaQkyrvi+qlAIb6k/JTKjMTijPii0pzU4kOMEhzM SiK8b+YD5XhTEiurUovyYVLSHCxK4rxit3YGCgmkJ5akZqemFqQWwWRlODiUJHj7bwE1Chal pqdWpGXmlCCkmTg4QYbzAA2fBlLDW1yQmFucmQ6RP8Woy7Fiz9b3jEIsefl5qVLivPNBigRA ijJK8+DmwJLNK0ZxoLeEeVtAqniAiQpu0iugJUxAS2YuAVtSkoiQkmpgNLj3Mch6UoPkyR6F iG371h9Q6f683d93rlXR+z2OaatXlivWns04dbZVJsnYp/uIa1BvIb/upafKi4rCXntsm6lo un6n4aF9zv33IuvKvzU7ruie/ndCQJ3E7Km+VXmVnHplR/+u9NwbNjXTxMjt5uJFD9jqPpqw /X7imVzYtmqlxIUGTakUJZbijERDLeai4kQAmbwWAhEDAAA= Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: RE: Stephen Farrell's No Objection on draft-ietf-xrblock-rtcp-xr-discard-14: (with COMMENT) 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, 26 Jun 2013 12:14:46 -0000 No promise, I'll try. Tnx! Sent from my iPad On Jun 26, 2013, at 6:14, Stephen Farrell wrote: > > Anyone interested in thinking about whether there might be > side-channels caused by xrblock? [1] Or even in just giving > them a general presentation on side-channels to help 'em > figure out if they think there's an issue or not? > > Once the meeting schedule is firmed up I'll maybe ask on > saag but if someone here is interested in helping 'em > just let me know. > > Ta, > S. > > [1] http://tools.ietf.org/wg/xrblock/charters > > > -------- Original Message -------- > Subject: RE: Stephen Farrell's No Objection on > draft-ietf-xrblock-rtcp-xr-discard-14: (with COMMENT) > Date: Wed, 26 Jun 2013 10:06:00 +0000 > From: Romascanu, Dan (Dan) > To: Stephen Farrell , The IESG > CC: xrblock-chairs@tools.ietf.org , > draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org > > > Hi, > > If this is a generic problem that can possibly impact several xrblock > documents, maybe we can have a security expert (a.k.a. co-ponderer) > attend the XRBLOCK meeting and discuss the issue with us. We seem to > have a pretty light wg agenda in Berlin, so it won't be a problem to > find time on it. > > Thanks and Regards, > > Dan > > > > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Tuesday, June 25, 2013 8:01 PM >> To: The IESG >> Cc: xrblock-chairs@tools.ietf.org; draft-ietf-xrblock-rtcp-xr- >> discard@tools.ietf.org >> Subject: Stephen Farrell's No Objection on draft-ietf-xrblock-rtcp-xr- >> discard-14: (with COMMENT) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-xrblock-rtcp-xr-discard-14: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Sam Hartman's secdir review [1] of xr-discard-rle-metrics raised a good >> question that's probably better asked here, or here as well. I'm not >> asking for any change in this or any specific xrblock document, but I >> would ask that the WG do consider this. Sam said: >> >> "Has the WG analyzed implications of providing feedback to an attacker >> on what specific SRTP packets are discarded? In the past we've run into >> trouble with security systems that were too verbose in error reporting. >> As an example, in certain public-key crypto constructions knowing >> whether a packet produced a decoding error vs a signature error after >> decryption can provide an attacker generating forged packets valuable >> information to attack the system. >> >> It's quite possible that SRTP doesn't have problems in this regard. I >> just want to confirm that the analysis has been done." >> >> I think that's a good question because knowing at what stage in a >> security protocol a message was barfed or getting timing statistics can >> expose information about how some crypto operation went wrong, and that >> can be exploited via statistical techniques with a sufficiently large >> number of messages. See for example the lucky-13 attacks against >> certain cryptographic modes in TLS [2] or perhaps the "original" of the >> species, the Bleichenbacher attack. [3] >> >> I suspect the best thing to do might be for the wg to try grab a >> security person and ponder this for a bit, if that's not already been >> done. I'm happy to try help find a co-ponderer if you want:-) Maybe we >> can ambush one in a hallway in Berlin. >> >> [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04048.html >> [2] http://www.isg.rhul.ac.uk/tls/Lucky13.html >> [3] https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From jsalowey@cisco.com Wed Jun 26 08:52:06 2013 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 539DA21E8087; Wed, 26 Jun 2013 08:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC-szk5kXfIA; Wed, 26 Jun 2013 08:52:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B2EA121F991F; Wed, 26 Jun 2013 08:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=890; q=dns/txt; s=iport; t=1372261920; x=1373471520; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Ms2KfbjWvSadEI9w2cx2tPpbjGzpkPTHToTKcttRAWk=; b=Xyx2v8qFJDU6GPB8I3O2UdHuAkU+LHfxmQ0Qr8nGR1Hmqox9b8TG4I6x 7I4nBsL0gd14KbgnYZ/9rdPo3C2G0XGboBnE0UDCfKMRLAgGiDUN/pVgv 8XkTrmEkVCykxZp9DxIsw55xaJxEuasp5oq7D7Qdb1Is8rTEHIUdD0oZt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAoNy1GtJV2d/2dsb2JhbABagwl6vn2BARZ0giUBBDpRASoUQicEARqIBro+jxqDOmEDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227796941" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jun 2013 15:52:00 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5QFq0oY029947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 15:52:00 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 10:51:59 -0500 From: "Joseph Salowey (jsalowey)" To: "secdir@ietf.org" , "draft-ietf-l3vpn-virtual-hub.all@tools.ietf.com" , " IESG" Thread-Topic: Secdir review of draft-ietf-l3vpn-virtual-hub-06 Thread-Index: AQHOcoUXnQzzTkLyh0ixcnNbf10m9A== Date: Wed, 26 Jun 2013 15:51:59 +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.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <1657B00FDCF8DA488E9EBB7795BC8DA5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-l3vpn-virtual-hub-06 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, 26 Jun 2013 15:52:06 -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. The document describes a hub and spoke topology for BGP/MPLS VPNs. The sec= urity considerations refer to RFC4364. While I share the concern in Steph= en's Comment, I have thought about it a bit and have not come up with signi= ficant recommendations that are not covered in RFC4364. The document doe= s discuss multicast routing a bit so I'm wondering if it should also refere= nce the security considerations in RFC 6513 and/or RFC 6514.=20 Aside from this comment I think the document is ready to go. =20 Cheers, Joe= From n@arifumi.net Wed Jun 26 22:00:01 2013 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 7724C21F9AC1 for ; Wed, 26 Jun 2013 22:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueGrUBzHwqN5 for ; Wed, 26 Jun 2013 21:59:56 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1E24E21F9AED for ; Wed, 26 Jun 2013 21:59:47 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so162643pdj.28 for ; Wed, 26 Jun 2013 21:59:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=FLAiaNHHjX8MQfhzUIftQqymR2yLa5PZwINSuNKtH+U=; b=Zgs0Y8SM+k9L2SNcJ6RPV2ax0NhMsPn5V8fNCVxzFCklxU342xOTjjSRoMgGBtI10+ tGv9nFTMy49b1CCvQN56DvBetXPXkq9UkXQY1cWvXYN9hsNTqQXhFTWAR0PDmEbPBxQL sWbZiyZvmmbx1FMhc2KhGGKfLuNLGUoEcWvBVnr9/agUOGmm9Q2ZOnCUhpjZZxMneySo eWC3Inq6lCbtcRUyMFAuL9Z8mzv4DJWQcFNvf09H+XV+drpzwkMKeMoNd8tSYKhJdWkN HgdKNwIAPEwvWg3Z3dNhNZl/ZWSxekZ3lWUv+imfNGKyArzTtwgDzk51rf7TKLk/RwLy 2F7g== MIME-Version: 1.0 X-Received: by 10.68.211.228 with SMTP id nf4mr4152012pbc.26.1372309186735; Wed, 26 Jun 2013 21:59:46 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.237.162 with HTTP; Wed, 26 Jun 2013 21:59:46 -0700 (PDT) X-Originating-IP: [192.68.248.65] In-Reply-To: References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> <5F8FAF51-833A-4C75-9FFC-BE17ADF27994@employees.org> <5ffd0e5973e67c773b8ce3d345010c8f.squirrel@www.trepanning.net> <2B1856F1-537D-4268-A104-BDC180A4EC54@employees.org> Date: Thu, 27 Jun 2013 13:59:46 +0900 X-Google-Sender-Auth: xo8o5RwZ7a_hY0FNndFgwQlal68 Message-ID: From: Arifumi Matsumoto To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=e89a8ffba99999023d04e01ba13c X-Gm-Message-State: ALoCoQlC4L2l6t7/0Li6fAbqpHut6pqmCkihry0zlQ+V+vHogsTwzMVgvsShGeKRHw+nzrr8FB8V Cc: secdir@ietf.org, "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , draft-ietf-6man-rfc3484bis@tools.ietf.org, Ole Troan , iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 27 Jun 2013 05:00:01 -0000 --e89a8ffba99999023d04e01ba13c Content-Type: text/plain; charset=ISO-8859-1 Hi, then, let me submit this version today. Dan, please comment on it, if you have any. Thanks. 2013/6/20 Arifumi Matsumoto > Dan, > > this is diff from the previous version, as requested by Ole. > https://bitbucket.org/arifumi/draft-addr-select-opt/diff/draft-ietf-6man- > addr-select-opt.txt?diff2=2e7efc634b5a&at=master > > Thanks. > > > > 2013/6/17 Arifumi Matsumoto > >> I attached a rev candidate. >> Hope this solves the issues pointed by Dan. >> >> Thank you very much. >> >> >> 2013/6/13 Ole Troan >> >>> Dan, >>> >>> > Yes, I am fine with Arifumi's clarification. Thanks. >>> >>> splendid, thanks for the help! >>> >>> Best regards, >>> Ole >>> >>> >> Dan, >>> >> >>> >> apologies for the delay, I discussed this directly with Arifumi, and I >>> >> hope his latest message clarifies the issue. >>> >> >>> >> to rephrase in my words; >>> >> OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to >>> disable >>> >> automatic row addition) >>> >> and to carry policy table options. >>> >> the A-flag is a hint to the host to disable automatic row addition. >>> >> if OPTION_ADDRSEL contains policy table options the A-flag is >>> redundant. >>> >> (as policy table options and the A-flag are incompatible). >>> >> >>> >> if you are fine with this, I will ask the authors to update the draft >>> to >>> >> make this behaviour explicit. >>> >> >>> >> Best regards, >>> >> Ole >>> >> >>> >>>> let me chime in as the document shepherd. >>> >>>> (thank you very much for the thorough comments by the way). >>> >>>> >>> >>>>> For instance, while I think I understand the policy override of RFC >>> >>>>> 6724, having the Automatic Row Additions Flag be part of the >>> address >>> >>>>> selection options seems problematic. If it is set to zero, then >>> what >>> >>>>> are >>> >>>>> the semantics of such a message? "Here's an address selection >>> option >>> >>>>> but don't you dare use it!"? What is the point? Me, as a node, can >>> >>>>> have >>> >>>>> this as part of my policy state which would allow me to ignore such >>> >>>>> an update but to have the bit be part of the option to update does >>> >>>>> not seem to make much sense. The semantics of the message needs >>> >>>>> to be explained much more clearly, or the bit needs to be removed >>> >>>>> from the message. >>> >>>> >>> >>>> my reading of the meaning of the A flag is a little different. (I >>> have >>> >>>> cc'ed the authors of rfc6724 for confirmation.) >>> >>>> >>> >>>> an implementation of RFC6724 may automatically add entries in the >>> >>>> policy >>> >>>> table based on addresses configured on the node. >>> >>>> e.g. the node has an interface with a ULA address. >>> >>>> >>> >>>> RFC6724 also says: >>> >>>> An implementation SHOULD provide a means (the Automatic Row >>> Additions >>> >>>> flag) for an administrator to disable >>> >>>> automatic row additions. >>> >>> >>> >>> That makes perfect sense. A client implementation SHOULD provide a >>> >>> means to disable automatic row additions. So it has some knob that >>> can >>> >>> be turned on or off locally that would allow for update of its policy >>> >>> table >>> >>> by receiving policy options (enable) or forbid received policy >>> options >>> >>> from >>> >>> updating the policy table (disable). >>> >>> >>> >>>> the A-flag in draft-ietf-6man-addr-select-opt provides the means. >>> >>> >>> >>> So this is where I'm confused. The sender of the policy option should >>> >>> not have the ability to control the knob that an implementation added >>> >>> locally to satisfy RFC 6724. If a client implementation sets its >>> knob to >>> >>> "disable" then it forbids policy option updates to its policy table. >>> It >>> >>> shouldn't inspect the received option update to decide whether it >>> >>> should override the setting of its local knob. >>> >>> >>> >>> This seems like a security issue to me. There's a reason why an >>> >>> implementation would choose to disable updates of its policy table >>> >>> and allowing the sender of policy updates to override that seems >>> >>> wrong. >>> >>> >>> >>>> it does not affect the policy entries that is contained in the DHCP >>> >>>> option. >>> >>>> the A-flag only affects the RFC6724 behaviour of adding entries >>> based >>> >>>> on >>> >>>> address configuration on the node. >>> >>> >>> >>> Again, according to the draft a message can be received by a client >>> >>> implementation that provides policy update options to its policy >>> table >>> >>> with semantics of "you SHOULD NOT use these!" So what is the point >>> >>> of sending that message? Why not just refrain from sending the >>> message >>> >>> if that's what the message is? >>> >>> >>> >>> Would you ever tell someone, "disregard what I am about to tell >>> you"? I >>> >>> can't see why. And that's what the semantics of this message seem to >>> be. >>> >> >>> >> >>> >> >>> >> >>> > >>> >>> >> > --e89a8ffba99999023d04e01ba13c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

then, let me submit this vers= ion today.
Dan, please comment on it, if you have any.

Thanks.


2013/6/20 Arifumi Matsumoto <arifumi@nt= tv6.net>


2013/6/17 Arifumi Matsumoto <arifumi@nttv6.net><= br>
I attached a rev candi= date.
Hope this solves the issues pointed by Dan.

<= /div>
Thank you very much.
<= br>
2013/6/13 Ole Troan <= ;otroan@employees= .org>
Dan,

> =A0Yes, I am fine with Arifumi's clarification. Thanks.

splendid, thanks for the help!

Best regards,
Ole

>> Dan,
>>
>> apologies for the delay, I discussed this directly with Arifumi, a= nd I
>> hope his latest message clarifies the issue.
>>
>> to rephrase in my words;
>> OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to = disable
>> automatic row addition)
>> and to carry policy table options.
>> the A-flag is a hint to the host to disable automatic row addition= .
>> if OPTION_ADDRSEL contains policy table options the A-flag is redu= ndant.
>> (as policy table options and the A-flag are incompatible).
>>
>> if you are fine with this, I will ask the authors to update the dr= aft to
>> make this behaviour explicit.
>>
>> Best regards,
>> Ole
>>
>>>> let me chime in as the document shepherd.
>>>> (thank you very much for the thorough comments by the way)= .
>>>>
>>>>> For instance, while I think I understand the policy ov= erride of RFC
>>>>> 6724, having the Automatic Row Additions Flag be part = of the address
>>>>> selection options seems problematic. If it is set to z= ero, then what
>>>>> are
>>>>> the semantics of such a message? "Here's an a= ddress selection option
>>>>> but don't you dare use it!"? What is the poin= t? Me, as a node, can
>>>>> have
>>>>> this as part of my policy state which would allow me t= o ignore such
>>>>> an update but to have the bit be part of the option to= update does
>>>>> not seem to make much sense. The semantics of the mess= age needs
>>>>> to be explained much more clearly, or the bit needs to= be removed
>>>>> from the message.
>>>>
>>>> my reading of the meaning of the A flag is a little differ= ent. (I have
>>>> cc'ed the authors of rfc6724 for confirmation.)
>>>>
>>>> an implementation of RFC6724 may automatically add entries= in the
>>>> policy
>>>> table based on addresses configured on the node.
>>>> e.g. the node has an interface with a ULA address.
>>>>
>>>> RFC6724 also says:
>>>> =A0An implementation SHOULD provide a means (the Automatic= Row Additions
>>>> flag) for an administrator to disable
>>>> =A0automatic row additions.
>>>
>>> That makes perfect sense. A client implementation SHOULD provi= de a
>>> means to disable automatic row additions. So it has some knob = that can
>>> be turned on or off locally that would allow for update of its= policy
>>> table
>>> by receiving policy options (enable) or forbid received policy= options
>>> from
>>> updating the policy table (disable).
>>>
>>>> the A-flag in draft-ietf-6man-addr-select-opt provides the= means.
>>>
>>> So this is where I'm confused. The sender of the policy op= tion should
>>> not have the ability to control the knob that an implementatio= n added
>>> locally to satisfy RFC 6724. If a client implementation sets i= ts knob to
>>> "disable" then it forbids policy option updates to i= ts policy table. It
>>> shouldn't inspect the received option update to decide whe= ther it
>>> should override the setting of its local knob.
>>>
>>> This seems like a security issue to me. There's a reason w= hy an
>>> implementation would choose to disable updates of its policy t= able
>>> and allowing the sender of policy updates to override that see= ms
>>> wrong.
>>>
>>>> it does not affect the policy entries that is contained in= the DHCP
>>>> option.
>>>> the A-flag only affects the RFC6724 behaviour of adding en= tries based
>>>> on
>>>> address configuration on the node.
>>>
>>> Again, according to the draft a message can be received by a c= lient
>>> implementation that provides policy update options to its poli= cy table
>>> with semantics of "you SHOULD NOT use these!" So wha= t is the point
>>> of sending that message? Why not just refrain from sending the= message
>>> if that's what the message is?
>>>
>>> Would you ever tell someone, "disregard what I am about t= o tell you"? I
>>> can't see why. And that's what the semantics of this m= essage seem to be.
>>
>>
>>
>>
>




--e89a8ffba99999023d04e01ba13c-- From kivinen@iki.fi Thu Jun 27 05:51:48 2013 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 31E8C21F9C6D for ; Thu, 27 Jun 2013 05:51:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9p6LxN-SwwE for ; Thu, 27 Jun 2013 05:51:47 -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 371D721F9C6A for ; Thu, 27 Jun 2013 05:51:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r5RCphMw011774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 27 Jun 2013 15:51:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r5RCpgq1029096; Thu, 27 Jun 2013 15:51:42 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20940.13662.248109.159892@fireball.kivinen.iki.fi> Date: Thu, 27 Jun 2013 15:51:42 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 1 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, 27 Jun 2013 12:51:48 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Charlie Kaufman is next in the rotation. For telechat 2013-06-27 Reviewer LC end Draft David Waltermire T 2013-06-19 draft-ietf-nvo3-overlay-problem-statement-03 For telechat 2013-07-11 Tobias Gondrom T 2013-06-27 draft-ietf-appsawg-rfc5451bis-07 Sam Weiler T 2013-06-19 draft-ietf-ospf-manet-single-hop-mdr-03 For telechat 2013-07-18 Simon Josefsson T 2013-07-23 draft-merkle-tls-brainpool-02 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland - draft-ietf-httpbis-p5-range-22 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Donald Eastlake 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Steve Hanna 2013-06-27 draft-ietf-manet-rfc6622-bis-02 Dan Harkins 2013-07-03 draft-ietf-multimob-pmipv6-ropt-06 David Harrington 2013-07-01 draft-ietf-straw-b2bua-taxonomy-02 Paul Hoffman 2013-07-16 draft-ivov-xmpp-cusax-06 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Leif Johansson 2013-07-22 draft-ivov-grouptextchat-purpose-03 Julien Laganier - draft-ietf-avtcore-rtp-security-options-03 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Sandy Murphy 2013-07-17 draft-jabley-dnsext-eui48-eui64-rrtypes-05 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-11 Ondrej Sury 2013-06-17 draft-ietf-abfab-eapapplicability-03 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-10 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 -- kivinen@iki.fi From gonzalo.camarillo@ericsson.com Thu Jun 27 08:05:42 2013 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 1227621F9E14; Thu, 27 Jun 2013 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.425 X-Spam-Level: X-Spam-Status: No, score=-104.425 tagged_above=-999 required=5 tests=[AWL=1.824, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArforAAVDDYJ; Thu, 27 Jun 2013 08:05:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBE321F9E07; Thu, 27 Jun 2013 08:05:35 -0700 (PDT) X-AuditID: c1b4fb25-b7f1e6d00000274b-39-51cc54be4874 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F6.A8.10059.EB45CC15; Thu, 27 Jun 2013 17:05:34 +0200 (CEST) Received: from [131.160.126.127] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 27 Jun 2013 17:05:31 +0200 Message-ID: <51CC54B0.3050702@ericsson.com> Date: Thu, 27 Jun 2013 18:05:20 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Qin Wu References: <519097A8.40409@oracle.com> <51CAA254.6040303@oracle.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvre6+kDOBBrMWGlg8nruA1WLeom3s FjP+TGS2+LDwIYtF3+tD7A6sHi1H3rJ6LFnyk8nj49NbLB5fLn9mC2CJ4rJJSc3JLEst0rdL 4Mo4cKaVteAof8WTRzvYGhh38XQxcnBICJhItN7l7WLkBDLFJC7cW8/WxcjFISRwilGi9fVs VpCEkMBaRon//zVAbF4BbYljDcuYQGwWAVWJa+8mgNWwCVhIbLl1nwXEFhWIkmjtncoMUS8o cXLmE7C4iIC8RMPmu4wgC5gF7jFKHN+xEKxZWMBcYsfed6wQm/sZJeb/7gfbwCkQJjHrUC8b xHmSEltetLOD2MwCehJTrrYwQtjyEtvfzmGGuFRbYvmzFpYJjEKzkCyfhaRlFpKWBYzMqxjZ cxMzc9LLjTYxAsP74JbfqjsY75wTOcQozcGiJM67We9MoJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGLpvHXVpXmncvL1ry1uZ2T6ld5dbvvouuOfTlcujNnjS1xCtyafa5pGju28Z9d4RW XdJR51kQ8vvi+z8T2t7cz1QWeKr8Ld3635R1wacE132//l/pWrOhX/Oa/pLPbMusvR5Zfvm7 /J38O//3/D3Po79ILH+v73r9N6PB42ZPx77mLxraC4r0lViKMxINtZiLihMB8zZusD0CAAA= Cc: "draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-xrblock-rtcp-xr-jb-12 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, 27 Jun 2013 15:05:42 -0000 Hi, note that RTP is one of the well-known abbreviations that do not need expansion: http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt Cheers, Gonzalo On 26/06/2013 12:46 PM, Qin Wu wrote: > Hi,Shawn: > Thank for your comments, my reply is inline below. > > Regards! > -Qin > > -----Original Message----- > From: Shawn M Emery [mailto:shawn.emery@oracle.com] > Sent: Wednesday, June 26, 2013 4:12 PM > To: secdir@ietf.org > Cc: draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org; iesg@ietf.org > Subject: Review of draft-ietf-xrblock-rtcp-xr-jb-12 > > > 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 internet-draft specifies a RTP Control Protocol (RTCP) Extended Report > (XR) Block for data on jitter buffer configuration and performance. > > The security considerations section does exist and states that the new block > data does not introduce any additional security concerns than those stated > in the base XR spec, RFC 3611. I believe this to be an accurate assertion. > > General comments: > > I found the draft slightly hard to read, as the terminology and abbreviations > used are not expanded. For example, the abstract has "RTP", but never expands > the abbreviation. > > [Qin]; RTP is abbreviation of "A Transport Protocol for Real-Time Applications" and defined > In the basic RTP protocol specification [RFC3550], it is the basic atom we are used > in the context of this draft and can not be decomposed.For other term and abbreviation, > I will check and fix that, thanks. > > > Editorial comments: > > s/[RFC6390]and/[RFC6390] and/ > > [Qin]:okay.Thanks! > > Shawn. > -- > > From dharkins@lounge.org Thu Jun 27 09:10:38 2013 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 6E35D21F9E71; Thu, 27 Jun 2013 09:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBqrHkOe9MD6; Thu, 27 Jun 2013 09:10:30 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id BEAE921F9E6E; Thu, 27 Jun 2013 09:10:27 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 550BAA888008; Thu, 27 Jun 2013 09:10:26 -0700 (PDT) Received: from 67.155.206.12 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 27 Jun 2013 09:10:26 -0700 (PDT) Message-ID: <51db411de70c7cb7b4e41776cc366a40.squirrel@www.trepanning.net> In-Reply-To: References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> <5F8FAF51-833A-4C75-9FFC-BE17ADF27994@employees.org> <5ffd0e5973e67c773b8ce3d345010c8f.squirrel@www.trepanning.net> <2B1856F1-537D-4268-A104-BDC180A4EC54@employees.org> Date: Thu, 27 Jun 2013 09:10:26 -0700 (PDT) From: "Dan Harkins" To: "Arifumi Matsumoto" 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 Cc: draft-ietf-6man-rfc3484bis@tools.ietf.org, secdir@ietf.org, "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , Ole Troan , iesg@ietf.org, Arifumi Matsumoto Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt 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, 27 Jun 2013 16:10:38 -0000 Hi Arifumi, It looks fine. Thanks. regards, Dan. On Wed, June 26, 2013 9:59 pm, Arifumi Matsumoto wrote: > Hi, > > then, let me submit this version today. > Dan, please comment on it, if you have any. > > Thanks. > > > 2013/6/20 Arifumi Matsumoto > >> Dan, >> >> this is diff from the previous version, as requested by Ole. >> https://bitbucket.org/arifumi/draft-addr-select-opt/diff/draft-ietf-6man- >> addr-select-opt.txt?diff2=2e7efc634b5a&at=master >> >> Thanks. >> >> >> >> 2013/6/17 Arifumi Matsumoto >> >>> I attached a rev candidate. >>> Hope this solves the issues pointed by Dan. >>> >>> Thank you very much. >>> >>> >>> 2013/6/13 Ole Troan >>> >>>> Dan, >>>> >>>> > Yes, I am fine with Arifumi's clarification. Thanks. >>>> >>>> splendid, thanks for the help! >>>> >>>> Best regards, >>>> Ole >>>> >>>> >> Dan, >>>> >> >>>> >> apologies for the delay, I discussed this directly with Arifumi, >>>> and I >>>> >> hope his latest message clarifies the issue. >>>> >> >>>> >> to rephrase in my words; >>>> >> OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to >>>> disable >>>> >> automatic row addition) >>>> >> and to carry policy table options. >>>> >> the A-flag is a hint to the host to disable automatic row addition. >>>> >> if OPTION_ADDRSEL contains policy table options the A-flag is >>>> redundant. >>>> >> (as policy table options and the A-flag are incompatible). >>>> >> >>>> >> if you are fine with this, I will ask the authors to update the >>>> draft >>>> to >>>> >> make this behaviour explicit. >>>> >> >>>> >> Best regards, >>>> >> Ole >>>> >> >>>> >>>> let me chime in as the document shepherd. >>>> >>>> (thank you very much for the thorough comments by the way). >>>> >>>> >>>> >>>>> For instance, while I think I understand the policy override of >>>> RFC >>>> >>>>> 6724, having the Automatic Row Additions Flag be part of the >>>> address >>>> >>>>> selection options seems problematic. If it is set to zero, then >>>> what >>>> >>>>> are >>>> >>>>> the semantics of such a message? "Here's an address selection >>>> option >>>> >>>>> but don't you dare use it!"? What is the point? Me, as a node, >>>> can >>>> >>>>> have >>>> >>>>> this as part of my policy state which would allow me to ignore >>>> such >>>> >>>>> an update but to have the bit be part of the option to update >>>> does >>>> >>>>> not seem to make much sense. The semantics of the message needs >>>> >>>>> to be explained much more clearly, or the bit needs to be >>>> removed >>>> >>>>> from the message. >>>> >>>> >>>> >>>> my reading of the meaning of the A flag is a little different. (I >>>> have >>>> >>>> cc'ed the authors of rfc6724 for confirmation.) >>>> >>>> >>>> >>>> an implementation of RFC6724 may automatically add entries in the >>>> >>>> policy >>>> >>>> table based on addresses configured on the node. >>>> >>>> e.g. the node has an interface with a ULA address. >>>> >>>> >>>> >>>> RFC6724 also says: >>>> >>>> An implementation SHOULD provide a means (the Automatic Row >>>> Additions >>>> >>>> flag) for an administrator to disable >>>> >>>> automatic row additions. >>>> >>> >>>> >>> That makes perfect sense. A client implementation SHOULD provide a >>>> >>> means to disable automatic row additions. So it has some knob that >>>> can >>>> >>> be turned on or off locally that would allow for update of its >>>> policy >>>> >>> table >>>> >>> by receiving policy options (enable) or forbid received policy >>>> options >>>> >>> from >>>> >>> updating the policy table (disable). >>>> >>> >>>> >>>> the A-flag in draft-ietf-6man-addr-select-opt provides the means. >>>> >>> >>>> >>> So this is where I'm confused. The sender of the policy option >>>> should >>>> >>> not have the ability to control the knob that an implementation >>>> added >>>> >>> locally to satisfy RFC 6724. If a client implementation sets its >>>> knob to >>>> >>> "disable" then it forbids policy option updates to its policy >>>> table. >>>> It >>>> >>> shouldn't inspect the received option update to decide whether it >>>> >>> should override the setting of its local knob. >>>> >>> >>>> >>> This seems like a security issue to me. There's a reason why an >>>> >>> implementation would choose to disable updates of its policy table >>>> >>> and allowing the sender of policy updates to override that seems >>>> >>> wrong. >>>> >>> >>>> >>>> it does not affect the policy entries that is contained in the >>>> DHCP >>>> >>>> option. >>>> >>>> the A-flag only affects the RFC6724 behaviour of adding entries >>>> based >>>> >>>> on >>>> >>>> address configuration on the node. >>>> >>> >>>> >>> Again, according to the draft a message can be received by a >>>> client >>>> >>> implementation that provides policy update options to its policy >>>> table >>>> >>> with semantics of "you SHOULD NOT use these!" So what is the point >>>> >>> of sending that message? Why not just refrain from sending the >>>> message >>>> >>> if that's what the message is? >>>> >>> >>>> >>> Would you ever tell someone, "disregard what I am about to tell >>>> you"? I >>>> >>> can't see why. And that's what the semantics of this message seem >>>> to >>>> be. >>>> >> >>>> >> >>>> >> >>>> >> >>>> > >>>> >>>> >>> >> > From d3e3e3@gmail.com Thu Jun 27 15:18:33 2013 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 80A0821F9EAC; Thu, 27 Jun 2013 15:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8qweLhA8-pn; Thu, 27 Jun 2013 15:18:32 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9630A21F9EA9; Thu, 27 Jun 2013 15:18:32 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o6so1553159oag.27 for ; Thu, 27 Jun 2013 15:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eK2/Wek/+eTjUzw53amx8FHZXMfVB0K1Mjm8cEancL4=; b=PlYQFXihJIvlgmIaQXgXXIARO2qgKQ20MOo5HypvIXWMRKNaRGIXCvs1i4l9tNQgDK KQuKkk0GvXFdXn0dcVONBe7f0SfGjZ0T7498Tnilp8zhy1dDnKXLIJpvqcMqPha+0SGB AJkUVAXhopurp3GzsueyMILBYj2WX+ck5QifTiHnXMDBNizjnWx3+u2uh9nI71T7u5xi JHb8wwMDlhy1HNG450XehBkNnMoStP82Mv3PIL/vUtOrvH/glVEt6sHyx/6/jxXPRxCI /i0MN2+h8dRKHo4PMG+cqcGOTdmaOXyB3Yh3R3RZ31MrDBIF9FslpbZUUAAbYwIh0UbA UDyA== X-Received: by 10.60.35.65 with SMTP id f1mr3907992oej.17.1372371512075; Thu, 27 Jun 2013 15:18:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.12.65 with HTTP; Thu, 27 Jun 2013 15:18:11 -0700 (PDT) In-Reply-To: <51CC54B0.3050702@ericsson.com> References: <519097A8.40409@oracle.com> <51CAA254.6040303@oracle.com> <51CC54B0.3050702@ericsson.com> From: Donald Eastlake Date: Thu, 27 Jun 2013 18:18:11 -0400 Message-ID: To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org" , "secdir@ietf.org" , Qin Wu , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-xrblock-rtcp-xr-jb-12 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, 27 Jun 2013 22:18:33 -0000 I believe it is always better to bend over backwards, if need be, to make a document clear. If someone had requested it, I would spell out any acronym in a draft of mine, not matter how "well known" -- IETF, IP, TCP, whatever. I believe the correct response to a request to spell out an acronym on first use is always to simply agree with that request, as in "RTP (Real-time Transport Protocol)". Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Jun 27, 2013 at 11:05 AM, Gonzalo Camarillo wrote: > Hi, > > note that RTP is one of the well-known abbreviations that do not need > expansion: > > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > Cheers, > > Gonzalo > > On 26/06/2013 12:46 PM, Qin Wu wrote: >> Hi,Shawn: >> Thank for your comments, my reply is inline below. >> >> Regards! >> -Qin >> >> -----Original Message----- >> From: Shawn M Emery [mailto:shawn.emery@oracle.com] >> Sent: Wednesday, June 26, 2013 4:12 PM >> To: secdir@ietf.org >> Cc: draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org; iesg@ietf.org >> Subject: Review of draft-ietf-xrblock-rtcp-xr-jb-12 >> >> >> 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 internet-draft specifies a RTP Control Protocol (RTCP) Extended Report >> (XR) Block for data on jitter buffer configuration and performance. >> >> The security considerations section does exist and states that the new block >> data does not introduce any additional security concerns than those stated >> in the base XR spec, RFC 3611. I believe this to be an accurate assertion. >> >> General comments: >> >> I found the draft slightly hard to read, as the terminology and abbreviations >> used are not expanded. For example, the abstract has "RTP", but never expands >> the abbreviation. >> >> [Qin]; RTP is abbreviation of "A Transport Protocol for Real-Time Applications" and defined >> In the basic RTP protocol specification [RFC3550], it is the basic atom we are used >> in the context of this draft and can not be decomposed.For other term and abbreviation, >> I will check and fix that, thanks. >> >> >> Editorial comments: >> >> s/[RFC6390]and/[RFC6390] and/ >> >> [Qin]:okay.Thanks! >> >> Shawn. >> -- >> >> > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From tlyu@mit.edu Thu Jun 27 15:59:44 2013 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 7125A21F9DCA; Thu, 27 Jun 2013 15:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J0hIOo6Qww0; Thu, 27 Jun 2013 15:59:37 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8498021F9DC7; Thu, 27 Jun 2013 15:59:37 -0700 (PDT) X-AuditID: 12074425-b7f0c8e000000953-aa-51ccc3d8825a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 39.A5.02387.8D3CCC15; Thu, 27 Jun 2013 18:59:36 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r5RMxYhR002084; Thu, 27 Jun 2013 18:59:34 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r5RMxVqQ024213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jun 2013 18:59:33 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r5RMxVmi021077; Thu, 27 Jun 2013 18:59:31 -0400 (EDT) To: curtis@ipv6.occnc.com References: <201306201717.r5KHHaaW004832@gateway1.orleans.occnc.com> From: Tom Yu Date: Thu, 27 Jun 2013 18:59:31 -0400 In-Reply-To: <201306201717.r5KHHaaW004832@gateway1.orleans.occnc.com> (Curtis Villamizar's message of "Thu, 20 Jun 2013 13:17:36 -0400") Message-ID: Lines: 125 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrXvj8JlAg2vzmS0mzzrDZrGjS9ti xp+JzBYfFj5kcWDxWLLkJ5PHsvsX2Ty+XP7MFsAcxWWTkpqTWZZapG+XwJXxuaGdveCMccXW kxcZGxgfaXYxcnJICJhInD3dwwphi0lcuLeerYuRi0NIYB+jxMtvR9ghnI2MEkeb97NCOOeY JFpf9zJBOF2MEov+X2AE6RcRkJT4dvAk2CxmgXiJ7e83MIPYwgIOEsvmv2cDsYUEXCQ+7P4G 1MzBwSYgLXF0cRlImEVAVWLhxuVgqzkFOhglnr46DjaTV8BCoqX9INhMHgEuia0fHjJBxAUl Ts58wgKxS0vixr+XTBMYBWchSc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NE LzWldBMjKJDZXVR3ME44pHSIUYCDUYmH90bymUAh1sSy4srcQ4ySHExKorwbDgKF+JLyUyoz Eosz4otKc1KLDzFKcDArifDeWQCU401JrKxKLcqHSUlzsCiJ84rd2hkoJJCeWJKanZpakFoE k5Xh4FCS4N16CKhRsCg1PbUiLTOnBCHNxMEJMpwHaPg+kBre4oLE3OLMdIj8KUZFKXGIhABI IqM0D64XlmheMYoDvSLMGwFyNw8wScF1vwIazAQ0eOaSUyCDSxIRUlINjHv1bzXe7pNTT06Y e6/UWr7tW8/uPVtn/DZpsgg1TTkWmiU2KfOFb0ba9cSU6z8cwrcy6TwrnZ6qULZiD59c6Cxn WZVObt3U/4lTu5otjAPX31h4slRc6mFC0guRaMe+YLlThsLvPzQwttaEH79a7SHS2xuaLXhU ReP/Oom6vw8up7S1nNutxFKckWioxVxUnAgA4i2H7Q8DAAA= Cc: draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-rtgwg-cl-requirement-10 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, 27 Jun 2013 22:59:44 -0000 Curtis Villamizar writes: > The entire one paragraph section is: > > This document specifies a set of requirements. The requirements > themselves do not pose a security threat. If these requirements are > met using MPLS signaling as commonly practiced today with > authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, > then the requirement to provide additional information in this > communication presents additional information that could conceivably > be gathered in a man-in-the-middle confidentiality breach. Such an > attack would require a capability to monitor this signaling either > through a provider breach or access to provider physical transmission > infrastructure. A provider breach already poses a threat of numerous > tpes of attacks which are of far more serious consequence. Encrption > of the signaling can prevent or render more difficult any > confidentiality breach that otherwise might occur by means of access > to provider physical transmission infrastructure. > > What is meant by "man-in-the-middle confidentiality breach" is a > man-in-the-middle situation in which the extent of damage is loss of > confidentiality due to routing protocols generally being authenticated > but in the clear, in this case the OSPF-TE and ISIS-TE. This is no > different, except now additional information is present, such as > delay. Providers already feel that topology is sensitive information > that they would prefer competitors didn't have and delay would be at > least as sensitive. Readers with security backgrounds would assume that "man-in-the-middle" refers to an active attack (see RFC 4949). I suggest removing that phrase, because it seems that in your "authenticated but unencrypted" case, a passive attack is sufficient to compromise confidentiality, and implying an active attack is confusing to the reader. > The sentence in question is the first third "If these requirements are > met using MPLS signaling as commonly practiced today with > authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, > then the requirement to provide additional information in this > communication presents additional information that could conceivably > be gathered in a man-in-the-middle confidentiality breach." Is the additional information of equal, greater, or lesser value than the information exchanged with the existing routing and signaling protocols? Does it add nontrivial value (to an attacker) to the existing information that the routing and signaling protocols already exchange? If an attacker can manipulate the additional information, e.g., delay measurements, can there be results such as routing instabilities? If such harmful results can occur from manipulation of the additional information that this document specifies, it seems that would require a minimum of an authenticated integrity-protected channel (or acceptance of the risks involved with relying on the physical and logical security of the service provider's equipment and transmission links). >> What scope of compromise does "provider breach" designate? > > What is meant by "provider breach" is any breach in which equipment > used in the provider infrastructure or management of that > infrastructure is fully compromised. It is well known that really bad > things can happen if a router is compromised and can inject bad > information. It is also well known that bad things can happen if > there is a compromise of management systems and in some cases > workstations involved in network management. There are equipment compromises less serious than a full compromise that could have an impact on confidentiality. > The access to physical transmission infrastructure means being able to > listen in on microwave or being able to put a bend in fiber and get > som light to leak out or somehow otherwise monitoring the signal, > demodulating it, and looking at anything in the clear. These physical link attacks, while possibly expensive to execute, are still only passive attacks from a cryptographic perspective, not "man-in-the-middle" active attacks. > The entire section is acknowledging an imperfect status quo and trying > to say that it makes it no worse. Perhaps is does so unclearly. > Maybe we could just replace the section with the standard boilerplate: > > The security considerations for MPLS/GMPLS and for MPLS-TP are > documented in > and > . > This document does not impact the security of MPLS, GMPLS, or > MPLS-TP. > > That would certainly be more clear. This type of boilerplate is in > the framework document but could be moved to the requirements > document. See draft-ietf-rtgwg-cl-framework. I agree that acknowledging the imperfect status quo is useful. Whether the proposed extensions make things worse depends on the relative value of the additional information that protocol participants will exchange, but it seems that you believe it to be of minimal additional value to an attacker. I'm not clear on whether your proposed replacement text encompasses the entire set of routing and signaling protocols that could be affected by this requirements document, but maybe I'm not sufficiently familiar with this space. > Would you prefer a wholesale replacement, or fixing up the existing > wording to make it more clear? If the latter, can you please suggest > text that you feel is clear. I prefer the two sentence replacement > above since it is clear and simple and accurate. I think the two sentences you propose above would be sufficient as replacement text if combined with text like the following, assuming it is accurate for the situation: The additional information that this document requires does not provide significant additional value to an attacker beyond the information already typically available from attacking a routing or signaling protocol. If the requirements of this document are met by extending an existing routing or signaling protocol, the security considerations of the protocol being extended apply. If the requirements of this document are met by specifying a new protocol, the security considerations of that new protocol should include an evaluation of what level of protection is required by the additional information specified in this document, such as data origin authentication. From varun@comnet.tkk.fi Wed Jun 26 10:43:34 2013 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 9406C11E80F5; Wed, 26 Jun 2013 10:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwpketrAEoBo; Wed, 26 Jun 2013 10:43:28 -0700 (PDT) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78D21F9DBB; Wed, 26 Jun 2013 10:43:27 -0700 (PDT) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6D6BA271515_1CB283EB; Wed, 26 Jun 2013 17:43:26 +0000 (GMT) Received: from smtp.netlab.hut.fi (sx2.tct.hut.fi [130.233.154.177]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id 4DC7D27106F_1CB283EF; Wed, 26 Jun 2013 17:43:26 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 453FE1E142; Wed, 26 Jun 2013 20:43:26 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LeTBDjw9eSWZ; Wed, 26 Jun 2013 20:43:21 +0300 (EEST) Received: from [192.168.0.10] (cs181253247.pp.htv.fi [82.181.253.247]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 8A3E41E13D; Wed, 26 Jun 2013 20:43:21 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Varun Singh In-Reply-To: Date: Wed, 26 Jun 2013 20:43:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <90938DE2-4AE6-4C45-B918-6C94CEB12D69@comnet.tkk.fi> References: To: Sam Hartman X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Fri, 28 Jun 2013 08:04:22 -0700 Cc: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-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, 26 Jun 2013 17:43:34 -0000 Hi, Thanks for the comments, comments inline. On Jun 24, 2013, at 4:37 PM, Sam Hartman wrote: >=20 >=20 > Please treat these comments as normal last-call comments. >=20 > I've been asigned as a security directorate reviewer for this draft. >=20 > This draft specifies a mechanism to indicate which packets were > discarded in a RTP stream. for the most part, this doesn't seem to = have > any security implications, and the text is clear. I do have one > concern. >=20 > Has the WG analyzed implications of providing feedback to an attacker = on > what specific SRTP packets are discarded? In the past we've run into > trouble with security systems that were too verbose in error = reporting. > As an example, in certain public-key crypto constructions knowing > whether a packet produced a decoding error vs a signature error after > decryption can provide an attacker generating forged packets valuable > information to attack the system. >=20 In the draft, discarded packets are defined as: packets that were = received but dropped from the jitter buffer because they were either too early (for = buffering)=20 or too late (for playout).=20 Since the timestamp field in the RTP header is not encrypted,=20 the endpoint can discard the packet before decrypting or authenticating = it. Forged packets that are discarded are not reported by this metric block. > It's quite possible that SRTP doesn't have problems in this regard. I > just want to confirm that the analysis has been done.=20 Cheers, Varun= From new-work-bounces@ietf.org Fri Jun 28 09:31:35 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC18221F9B11; Fri, 28 Jun 2013 09:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1372437095; bh=cMtckGuJ9evYpkmZRynLOC1I2/wJ5KmYrzNB3P4BCQE=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=VbSJrjmwRGNE6NDwv1/Hg6rGO72YyVvnb/X/nrgD8J59MafLx9F4qWqtyQBzGJjY4 JzY0Y5MU9X+efUZnG/8OpsAtQSywf1EIcB4KPRM6U0jWqqNrlX9Fm7NZfNYz8SzE+O jk2Da3CsqFgJNgxsbHXc2B8gNkumZKocjyNHBpbI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A8E21F9B12; Fri, 28 Jun 2013 09:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiHg2xtNrYB8; Fri, 28 Jun 2013 09:31:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A07C721F9B07; Fri, 28 Jun 2013 09:31:33 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628163133.18759.33764.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 09:31:33 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 28 Jun 2013 09:33:33 -0700 Subject: [secdir] [new-work] WG Review: Security Automation and Continuous Monitoring (sacm) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:31:36 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-07-08. Security Automation and Continuous Monitoring (sacm) ------------------------------------------------ Current Status: Proposed WG Chairs: Dan Romascanu Kathleen Moriarty Assigned Area Director: Sean Turner Mailing list Address: sacm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm/ Charter: Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols to collect, verify, and update system security configurations would allow this process to be automated, which would free security practitioners to focus on high priority tasks and should improve their ability to prioritize risk based on timely information about threats and vulnerabilities. Because this is a broad area of work, this working group will first address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are existing industry standards, preferably IETF standards, that could support automation of asset, change, configuration, and vulnerability management. The working group will define: 1. A set of standards to enable assessment of endpoint posture. This area of focus provides for necessary language and data format specifications. An example of such an endpoint posture assessment could include, but is not limited to, the following general steps: 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This approach to endpoint posture collection enables multiple policies to be evaluated based on a single data collection activity. Policies will be evaluated by comparing available endpoint posture data according to rules expressed in the policy. Typically, these rules will compare the actual value against an expected value or range for specific posture elements. In some cases, the posture element may pertain to software installation state, in which case the actual and expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using Boolean logic. 2. A set of standards for interacting with repositories of content related to assessment of endpoint posture. Repository protocols are needed to store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above). A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. asset inventory, configuration settings, or vulnerabilities). In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. This working group will produce the following deliverables: - A document or documents describing the SACM Architecture. This will include protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system. This may be a single standards-track document, or may be split up as the WG sees fit. - A standards-track document specifying the informational model for endpoints data posture. - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis - A standards-track document specifying a protocol and data format for collecting actual endpoint posture The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. The working group will work in close coordination with other WGs in the IETF (including, but not limited to MILE and NEA) in order to create solutions that do not overlap and can be used or re-used to meet the goals of more than one working group. The working group will communicate with non-IETF organizations working on related specifications and will encourage industry participation in the development of the WG's documents. Other organizations involved in the sacm space include ISO/IEC and TCG, as well as government agencies such as NIST. SACM-related efforts are largely aligned, and may overlap, with other IETF (and non-IETF) standardization efforts. There are common "problems" found in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest to SACM is understanding and respecting the distinctions between itself and NEA and MILE. One way the NEA protocols can be used is as the transport for data collected on the endpoint to an external service or data repository for further analysis and action. NEA may also serve the purpose of carrying data-collection instructions. The MILE data formats provide a format to describe incident, threat-related incident, and indicator information. SACM data formats provide ways to understand what endpoints are in your environment, whether they meet policy requirements, and their current configuration state. The data exchanged in MILE, supplementing the SACM data, creates enhanced situational awareness, thus enabling increased understanding of current threats and mitigations. The combined SACM and MILE data sets become a powerful tool to automate security with descriptions of endpoints, known vulnerabilities to those endpoints, and their configurations along with an understanding of layered defenses. Transports from MILE may be used by SACM. This charter will expire in Month Year (36 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Oct 2013 - Initial submission of SACM Architecture Internet-Draft Nov 2013 - Initial submission of SACM Information Model Internet-Draft Jan 2014 - Initial submission of protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft Jan 2014 - Initial submission of protocol and data format for collecting endpoint posture Internet-Draft May 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as Informational RFC Sep 2014 - Submit protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard Sep 2014 - Submit protocol and data format for collecting endpoint posture Internet-Draft to the IESG for consideration as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Jun 28 09:40:28 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9C321F9B95; Fri, 28 Jun 2013 09:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1372437628; bh=3KHhEIF4ZFM6Svkrfuiv5vSRt/1ICa6lqkljUYap8lE=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=txc7XDA1MVxHcVKvoj9LKeJrK9S4DbypcEOWXfMNte1Qwx3yEdsKt9iE/XPz4Lud9 HIv5vR5ZP1cundTFZbw5PuByaocaMU6dz9dJ6SC0nf9Z5MZWO8C/4r6U/KFaTrMbQL swzY704IUH8hAl6gAwszOpQ5NUtn+geOCJwQ1mh8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE0721F9B94; Fri, 28 Jun 2013 09:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xowuwlRfUM1; Fri, 28 Jun 2013 09:40:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4F21F9B14; Fri, 28 Jun 2013 09:40:27 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628164027.30627.72088.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 09:40:27 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Sat, 29 Jun 2013 09:31:11 -0700 Subject: [secdir] [new-work] WG Review: Managed Incident Lightweight Exchange (mile) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:40:28 -0000 The Managed Incident Lightweight Exchange (mile) working group in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-07-08. Managed Incident Lightweight Exchange (mile) ------------------------------------------------ Current Status: Active WG Chairs: Kathleen Moriarty Brian Trammell Assigned Area Director: Sean Turner Mailing list Address: mile@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile/ Charter: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. The MILE WG is focused on two areas, IODEF, the data format and extensions to represent incident and indicator data, and RID, the policy and transport for structured data. With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience. Use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs) and the recent cyber security Executive Order in the US. International groups, such as the Multinational Alliance for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified or are working to develop data representations relevant to their use cases that may compliment/extend IODEF or be useful to exchange using RID and related transport protocols. - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. - Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. - RID may require modifications to address data provenance, additional policy options, or other changes now that there are multiple interoperable implementations of RFC6545 and RFC6546. With the RID implementations in the open source community, increased use and experimentation may demonstrate the need for a revision. Milestones: Aug 2013 - Submit a draft on the representation of Structured Cybersecurity Information in IODEF to the IESG for publication as a Standards Track RFC Aug 2013 - Submit a draft on enumeration reference formats for IODEF to the IESG for publication as a Standards Track RFC Dec 2013 - Submit a draft on RESTful indicator exchange using IODEF/RID to the IESG for publication as an Informational RFC Jan 2014 - Submit an update of RFC5070 to the IESG for publication as a Standards Track RFC Apr 2014 - Submit a draft on guidance for IODEF applications to the IESG for publication as an Informational RFC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Jun 28 10:18:35 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEE821F9B93; Fri, 28 Jun 2013 10:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1372439915; bh=v87Y1SMFZXCfb5U/ChFWhcG/A3YJgFcucv0GJ1U+Bwk=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=MUXmGle5I/KNgIenqWU5VHp8OXT0mPfjZ5wR+hTDB7XeDR5tMuRJPtTXjTYkpWvjx BdiAPa9XotCNOhF4+9pqX3AqVpCbCs4sJOZL5jl1uSZhLbj7bJAI6LaXxFujxwcOdC IMuoc7W3w+wcrVlx1hw7T7jsw8sC94/z09M0Uk3Y= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9610B21F9B83; Fri, 28 Jun 2013 10:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnXhaGV8nH9e; Fri, 28 Jun 2013 10:18:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5521F9B88; Fri, 28 Jun 2013 10:18:32 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628171832.18257.35472.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 10:18:32 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Sat, 29 Jun 2013 09:31:11 -0700 Subject: [secdir] [new-work] UPDATED WG Review: Security Automation and Continuous Monitoring (sacm) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 17:18:35 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-07-08. Security Automation and Continuous Monitoring (sacm) ------------------------------------------------ Current Status: Proposed WG Chairs: Dan Romascanu Adam Montville Assigned Area Director: Sean Turner Mailing list Address: sacm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm/ Charter: Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols to collect, verify, and update system security configurations would allow this process to be automated, which would free security practitioners to focus on high priority tasks and should improve their ability to prioritize risk based on timely information about threats and vulnerabilities. Because this is a broad area of work, this working group will first address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are existing industry standards, preferably IETF standards, that could support automation of asset, change, configuration, and vulnerability management. The working group will define: 1. A set of standards to enable assessment of endpoint posture. This area of focus provides for necessary language and data format specifications. An example of such an endpoint posture assessment could include, but is not limited to, the following general steps: 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This approach to endpoint posture collection enables multiple policies to be evaluated based on a single data collection activity. Policies will be evaluated by comparing available endpoint posture data according to rules expressed in the policy. Typically, these rules will compare the actual value against an expected value or range for specific posture elements. In some cases, the posture element may pertain to software installation state, in which case the actual and expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using Boolean logic. 2. A set of standards for interacting with repositories of content related to assessment of endpoint posture. Repository protocols are needed to store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above). A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. asset inventory, configuration settings, or vulnerabilities). In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. This working group will produce the following deliverables: - A document or documents describing the SACM Architecture. This will include protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system. This may be a single standards-track document, or may be split up as the WG sees fit. - A standards-track document specifying the informational model for endpoints data posture. - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis - A standards-track document specifying a protocol and data format for collecting actual endpoint posture The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. The working group will work in close coordination with other WGs in the IETF (including, but not limited to MILE and NEA) in order to create solutions that do not overlap and can be used or re-used to meet the goals of more than one working group. The working group will communicate with non-IETF organizations working on related specifications and will encourage industry participation in the development of the WG's documents. Other organizations involved in the sacm space include ISO/IEC and TCG, as well as government agencies such as NIST. SACM-related efforts are largely aligned, and may overlap, with other IETF (and non-IETF) standardization efforts. There are common "problems" found in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest to SACM is understanding and respecting the distinctions between itself and NEA and MILE. One way the NEA protocols can be used is as the transport for data collected on the endpoint to an external service or data repository for further analysis and action. NEA may also serve the purpose of carrying data-collection instructions. The MILE data formats provide a format to describe incident, threat-related incident, and indicator information. SACM data formats provide ways to understand what endpoints are in your environment, whether they meet policy requirements, and their current configuration state. The data exchanged in MILE, supplementing the SACM data, creates enhanced situational awareness, thus enabling increased understanding of current threats and mitigations. The combined SACM and MILE data sets become a powerful tool to automate security with descriptions of endpoints, known vulnerabilities to those endpoints, and their configurations along with an understanding of layered defenses. Transports from MILE may be used by SACM. This charter will expire in Month Year (36 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Oct 2013 - Initial submission of SACM Architecture Internet-Draft Nov 2013 - Initial submission of SACM Information Model Internet-Draft Jan 2014 - Initial submission of protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft Jan 2014 - Initial submission of protocol and data format for collecting endpoint posture Internet-Draft May 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as Informational RFC Sep 2014 - Submit protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard Sep 2014 - Submit protocol and data format for collecting endpoint posture Internet-Draft to the IESG for consideration as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From curtis@ipv6.occnc.com Sat Jun 29 17:26:59 2013 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 6E07421F9D88; Sat, 29 Jun 2013 17:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dLIgv5s8zFl; Sat, 29 Jun 2013 17:26:54 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0D17221F9D6C; Sat, 29 Jun 2013 17:26:53 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r5U0PSdm023633; Sat, 29 Jun 2013 20:25:30 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201306300025.r5U0PSdm023633@gateway1.orleans.occnc.com> To: Tom Yu From: Curtis Villamizar In-reply-to: Your message of "Thu, 27 Jun 2013 18:59:31 EDT." Date: Sat, 29 Jun 2013 20:25:28 -0400 Cc: draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, curtis@ipv6.occnc.com Subject: Re: [secdir] secdir review of draft-ietf-rtgwg-cl-requirement-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 00:26:59 -0000 Tom, See inline, at the bottom. In message Tom Yu writes: > > Curtis Villamizar writes: > > > The entire one paragraph section is: > > > > This document specifies a set of requirements. The requirements > > themselves do not pose a security threat. If these requirements are > > met using MPLS signaling as commonly practiced today with > > authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, > > then the requirement to provide additional information in this > > communication presents additional information that could conceivably > > be gathered in a man-in-the-middle confidentiality breach. Such an > > attack would require a capability to monitor this signaling either > > through a provider breach or access to provider physical transmission > > infrastructure. A provider breach already poses a threat of numerous > > tpes of attacks which are of far more serious consequence. Encrption > > of the signaling can prevent or render more difficult any > > confidentiality breach that otherwise might occur by means of access > > to provider physical transmission infrastructure. > > > > What is meant by "man-in-the-middle confidentiality breach" is a > > man-in-the-middle situation in which the extent of damage is loss of > > confidentiality due to routing protocols generally being authenticated > > but in the clear, in this case the OSPF-TE and ISIS-TE. This is no > > different, except now additional information is present, such as > > delay. Providers already feel that topology is sensitive information > > that they would prefer competitors didn't have and delay would be at > > least as sensitive. > > Readers with security backgrounds would assume that > "man-in-the-middle" refers to an active attack (see RFC 4949). I > suggest removing that phrase, because it seems that in your > "authenticated but unencrypted" case, a passive attack is sufficient > to compromise confidentiality, and implying an active attack is > confusing to the reader. > > > The sentence in question is the first third "If these requirements are > > met using MPLS signaling as commonly practiced today with > > authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, > > then the requirement to provide additional information in this > > communication presents additional information that could conceivably > > be gathered in a man-in-the-middle confidentiality breach." > > Is the additional information of equal, greater, or lesser value than > the information exchanged with the existing routing and signaling > protocols? Does it add nontrivial value (to an attacker) to the > existing information that the routing and signaling protocols already > exchange? If an attacker can manipulate the additional information, > e.g., delay measurements, can there be results such as routing > instabilities? > > If such harmful results can occur from manipulation of the additional > information that this document specifies, it seems that would require > a minimum of an authenticated integrity-protected channel (or > acceptance of the risks involved with relying on the physical and > logical security of the service provider's equipment and transmission > links). > > >> What scope of compromise does "provider breach" designate? > > > > What is meant by "provider breach" is any breach in which equipment > > used in the provider infrastructure or management of that > > infrastructure is fully compromised. It is well known that really bad > > things can happen if a router is compromised and can inject bad > > information. It is also well known that bad things can happen if > > there is a compromise of management systems and in some cases > > workstations involved in network management. > > There are equipment compromises less serious than a full compromise > that could have an impact on confidentiality. > > > The access to physical transmission infrastructure means being able to > > listen in on microwave or being able to put a bend in fiber and get > > som light to leak out or somehow otherwise monitoring the signal, > > demodulating it, and looking at anything in the clear. > > These physical link attacks, while possibly expensive to execute, are > still only passive attacks from a cryptographic perspective, not > "man-in-the-middle" active attacks. > > > The entire section is acknowledging an imperfect status quo and trying > > to say that it makes it no worse. Perhaps is does so unclearly. > > Maybe we could just replace the section with the standard boilerplate: > > > > The security considerations for MPLS/GMPLS and for MPLS-TP are > > documented in > > and > > . > > This document does not impact the security of MPLS, GMPLS, or > > MPLS-TP. > > > > That would certainly be more clear. This type of boilerplate is in > > the framework document but could be moved to the requirements > > document. See draft-ietf-rtgwg-cl-framework. > > I agree that acknowledging the imperfect status quo is useful. > Whether the proposed extensions make things worse depends on the > relative value of the additional information that protocol > participants will exchange, but it seems that you believe it to be of > minimal additional value to an attacker. > > I'm not clear on whether your proposed replacement text encompasses > the entire set of routing and signaling protocols that could be > affected by this requirements document, but maybe I'm not sufficiently > familiar with this space. > > > Would you prefer a wholesale replacement, or fixing up the existing > > wording to make it more clear? If the latter, can you please suggest > > text that you feel is clear. I prefer the two sentence replacement > > above since it is clear and simple and accurate. > > I think the two sentences you propose above would be sufficient as > replacement text if combined with text like the following, assuming it > is accurate for the situation: > > The additional information that this document requires does not > provide significant additional value to an attacker beyond the > information already typically available from attacking a routing > or signaling protocol. If the requirements of this document are > met by extending an existing routing or signaling protocol, the > security considerations of the protocol being extended apply. If > the requirements of this document are met by specifying a new > protocol, the security considerations of that new protocol should > include an evaluation of what level of protection is required by > the additional information specified in this document, such as > data origin authentication. This paragraph is accurate. The two sentences above, plus this paragraph will replace the existing security section. As you alreay know, this document will be going back to WGLC due to the nature of the changes called for in the RtgDir review, which IMHO greatly improve the document. Thanks again for the review, Curtis From gonzalo.camarillo@ericsson.com Sun Jun 30 12:22:15 2013 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 CC57921F9C01; Sun, 30 Jun 2013 12:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wOZG34UCWQA; Sun, 30 Jun 2013 12:22:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 38A3A21F9C03; Sun, 30 Jun 2013 12:22:10 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-c0-51d08560bf12 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4C.7F.05990.06580D15; Sun, 30 Jun 2013 21:22:09 +0200 (CEST) Received: from [131.160.126.29] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.2.328.9; Sun, 30 Jun 2013 21:22:07 +0200 Message-ID: <51D0855F.60500@ericsson.com> Date: Sun, 30 Jun 2013 22:22:07 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Donald Eastlake References: <519097A8.40409@oracle.com> <51CAA254.6040303@oracle.com> <51CC54B0.3050702@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+JvrW5i64VAg2f/mSwez13AanFwu6bF vEXb2C1m/JnIbPFh4UMWB1aPnbPusnu0HHnL6rFkyU8mjy+XP7MFsERx2aSk5mSWpRbp2yVw ZTz5dZux4JRExeneS4wNjE0iXYycHBICJhLHj51nh7DFJC7cW8/WxcjFISRwmFFi6oFWFghn DaPE/StbmUCqeAU0Jea2fgeyOThYBFQlOrrlQcJsAhYSW27dZwGxRQWiJFp7pzJDlAtKnJz5 BCwuIqAm8Xr5ArCZzAKXGCWat39gBEkICzhIdD26yAqx7AujxKIVe8GWcQoESuxccZMJ4jxJ iS0v2sFOZRbQk5hytYURwpaX2P52Dtg2IQFtieXPWlgmMArNQrJ8FpKWWUhaFjAyr2Jkz03M zEkvN9rECAzvg1t+q+5gvHNO5BCjNAeLkjjvZr0zgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4 pRoY50+P33r5ziUpt8PH1fLOJv72jCoVdX0pfGDF9/Wbi7pX/VT76/Eh4nNrjP3JvNrWMJeW uZ5Tl/pKfGlp2KLmNP8tj7d57ONZntMXqGgWsUvVN7/WeTPv9e1H/K9fb01eP9fqbuBXfbHo srO8Mz/+mnJxiuTmqcveOsjtXcBb9rraboHCo7Psc5RYijMSDbWYi4oTAR5ze5Y9AgAA Cc: "draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org" , "secdir@ietf.org" , Qin Wu , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-xrblock-rtcp-xr-jb-12 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, 30 Jun 2013 19:22:15 -0000 Hi Donald, sure, that is what I also do in my own documents. Cheers, Gonzalo On 28/06/2013 1:18 AM, Donald Eastlake wrote: > I believe it is always better to bend over backwards, if need be, to > make a document clear. If someone had requested it, I would spell out > any acronym in a draft of mine, not matter how "well known" -- IETF, > IP, TCP, whatever. I believe the correct response to a request to > spell out an acronym on first use is always to simply agree with that > request, as in "RTP (Real-time Transport Protocol)". > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Thu, Jun 27, 2013 at 11:05 AM, Gonzalo Camarillo > wrote: >> Hi, >> >> note that RTP is one of the well-known abbreviations that do not need >> expansion: >> >> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt >> >> Cheers, >> >> Gonzalo >> >> On 26/06/2013 12:46 PM, Qin Wu wrote: >>> Hi,Shawn: >>> Thank for your comments, my reply is inline below. >>> >>> Regards! >>> -Qin >>> >>> -----Original Message----- >>> From: Shawn M Emery [mailto:shawn.emery@oracle.com] >>> Sent: Wednesday, June 26, 2013 4:12 PM >>> To: secdir@ietf.org >>> Cc: draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org; iesg@ietf.org >>> Subject: Review of draft-ietf-xrblock-rtcp-xr-jb-12 >>> >>> >>> 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 internet-draft specifies a RTP Control Protocol (RTCP) Extended Report >>> (XR) Block for data on jitter buffer configuration and performance. >>> >>> The security considerations section does exist and states that the new block >>> data does not introduce any additional security concerns than those stated >>> in the base XR spec, RFC 3611. I believe this to be an accurate assertion. >>> >>> General comments: >>> >>> I found the draft slightly hard to read, as the terminology and abbreviations >>> used are not expanded. For example, the abstract has "RTP", but never expands >>> the abbreviation. >>> >>> [Qin]; RTP is abbreviation of "A Transport Protocol for Real-Time Applications" and defined >>> In the basic RTP protocol specification [RFC3550], it is the basic atom we are used >>> in the context of this draft and can not be decomposed.For other term and abbreviation, >>> I will check and fix that, thanks. >>> >>> >>> Editorial comments: >>> >>> s/[RFC6390]and/[RFC6390] and/ >>> >>> [Qin]:okay.Thanks! >>> >>> Shawn. >>> -- >>> >>> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview