Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt
Arifumi Matsumoto <arifumi@nttv6.net> Thu, 20 June 2013 04:31 UTC
Return-Path: <n@arifumi.net>
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 <secdir@ietfa.amsl.com>; 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 <secdir@ietfa.amsl.com>; 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 <secdir@ietf.org>; Wed, 19 Jun 2013 21:31:28 -0700 (PDT)
Received: by mail-pb0-f47.google.com with SMTP id rr13so5754167pbb.6 for <secdir@ietf.org>; 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: <CABTuw1BqJH8uHkm=73oARWMd1wNkC+5FjJ+819zjcr_c+hT=kQ@mail.gmail.com>
References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <14984CD7-6EDD-49E6-A3C2-4775E80041AC@employees.org> <fb61afaa7d78273cb257bab766d03bcc.squirrel@www.trepanning.net> <5F8FAF51-833A-4C75-9FFC-BE17ADF27994@employees.org> <5ffd0e5973e67c773b8ce3d345010c8f.squirrel@www.trepanning.net> <2B1856F1-537D-4268-A104-BDC180A4EC54@employees.org> <CABTuw1BqJH8uHkm=73oARWMd1wNkC+5FjJ+819zjcr_c+hT=kQ@mail.gmail.com>
Date: Thu, 20 Jun 2013 13:31:28 +0900
X-Google-Sender-Auth: oqGFuRIP31PdTGZcpNNSYN8aa5Y
Message-ID: <CABTuw1CWZW+_Cdjbd4tCYOdCRweJNka+t-MNq9ktSM+1XRn5bQ@mail.gmail.com>
From: Arifumi Matsumoto <arifumi@nttv6.net>
To: Arifumi Matsumoto <arifumi@nttv6.net>
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-addr-select-opt.all@tools.ietf.org>, draft-ietf-6man-rfc3484bis@tools.ietf.org, Ole Troan <otroan@employees.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 <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jun 2013 04:31:29 -0000
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 <arifumi@nttv6.net> > I attached a rev candidate. > Hope this solves the issues pointed by Dan. > > Thank you very much. > > > 2013/6/13 Ole Troan <otroan@employees.org> > >> 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. >> >> >> >> >> >> >> >> >> > >> >> >
- [secdir] secdir review of draft-ietf-6man-addr-se… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Ole Troan
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Ole Troan
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Ole Troan
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins