Re: [Softwires] early MIB Doctor review for draft-ietf-softwire-map-mib-07

"Yu Fu" <fuyu@cnnic.cn> Wed, 17 May 2017 07:19 UTC

Return-Path: <fuyu@cnnic.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955021293DA; Wed, 17 May 2017 00:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.797
X-Spam-Level:
X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8npT_pZmwc0; Wed, 17 May 2017 00:19:18 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id F0639129BFF; Wed, 17 May 2017 00:15:59 -0700 (PDT)
Received: from LIUXD (unknown [218.241.103.89]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CpsuKi+BtZoOuxKg--.42393S3; Wed, 17 May 2017 15:15:46 +0800 (CST)
From: Yu Fu <fuyu@cnnic.cn>
To: bertietf@bwijnen.net
Cc: draft-ietf-softwire-map-mib.all@ietf.org, 'MIB Doctors' <mib-doctors@ietf.org>, softwires@ietf.org
References: <d7384d87-7a25-408d-86e7-9073a6c38278@bwijnen.net> <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net>
In-Reply-To: <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net>
Date: Wed, 17 May 2017 15:15:57 +0800
Message-ID: <002401d2cedd$6efb6870$4cf23950$@cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdLOHSNfBEgrSrxETg2pp8We1O3+SQAlnKBA
Content-Language: zh-cn
X-CM-TRANSID: AQAAf0CpsuKi+BtZoOuxKg--.42393S3
X-Coremail-Antispam: 1UD129KBjvJXoWxKw4xGF48Cw1UZr1DJF43Wrg_yoWxAw48pF Wftay7KrWDJ34ayrs2qw18try0yrZ2yry3Xr98tryUC390vrn7JF47KrW7ua4DCr18Xa1j v3yUX343ur1UAaUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4xMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07bo-BiUUUUU=
X-CM-SenderInfo: pix13q5fqqxugofq/
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/pn2OBsB4zojE0CSfdIo4lxhkBnM>
Subject: Re: [Softwires] early MIB Doctor review for draft-ietf-softwire-map-mib-07
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 May 2017 07:19:20 -0000

Hi Bert,

Please see my reply inline.

>>
>>>>   mapRuleID OBJECT-TYPE
>>>>           SYNTAX Integer32 (1..2147483647)
>>>>           MAX-ACCESS not-accessible
>>>>           STATUS current
>>>>           DESCRIPTION
>>>>              "An identifier used to distinguish the multiple
>>>>mapping
>>>>               rule which is unique with each CE in the same BR."
>>>>           ::= { mapRuleEntry 1 }
>>>>
>>>>   Since this is an index object, it be better defined as unsigned 32.
>>>>   See RFC4181, section 4.6.1.1. Specifically page 15, which states
>>>>      - Unsigned32 with a range that excludes zero is
>>>>RECOMMENDED for
>>>>        most index objects.  It is acceptable to include zero in the
>>>>        range when it is semantically significant or when it is used as
>>>>        the index value for a unique row with special properties.
>>>> Such
>>>>        usage SHOULD be clearly documented in the DESCRIPTION
>>>>clause.
>>>>>
>>>> [fuyu]:  I will change it into unsigned 32.
>>>>
>>>> Pls also think about the question if the value can ever be zero for a
>>>> good reason.
>>>> Normally INDEX object do not have a value of zero.
>>>>
>> [fuyu] Yes, since it is an index object and the value range is not include
>>zero. I think unsigned 32 is better.
>>
>OK, but then the definition would better be:
>
>     SYNTAX Unsigned32 (1..4294967295)
>That wat it is machinereadably clear that valu 0 is not valid.


[fuyu] :OK, I will updated it. Thanks.


>>>>
>>>>
>>>>    mapRulePSID  OBJECT-TYPE
>>>>           SYNTAX     Integer32
>>>>           MAX-ACCESS read-only
>>>>           STATUS     current
>>>>           DESCRIPTION
>>>>              "The PSID value algorithmically identifies a set of
>>>>               ports assigned to a CE."
>>>>           REFERENCE
>>>>                "PSID: section 3 of RFC 7597."
>>>>           ::= { mapRuleEntry 9 }
>>>>
>>>>     Mmmm... section 3 of RFC7597 only defines the term. The
>>>> algorithm is in section 5.1
>>>>     Maybe that is a better place to point to.
>>>>     Reading that section 5.1 in RFC7597, I wonder if "Integer32" is
>>>> the best representation.
>>>>     In section 5.1, I see a PSID that is 6 bits (figure 2 on page
>>>> 10). But there is also
>>>>     text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits.
>>>>     I am not an expert (basically have no knowledge about) on
>>>> RFC7597.
>>>> But sofar I cannot
>>>>     determine what the value range might be and how Integer32 is a
>>>> good representation for
>>>>     the PSID. Please explain (not just to me, but adding text to the
>>>> internet drafts
>>>>     and the DESCRIPTION clause of this object)
>>>>
>>>> [fuyu]:Different PSID values guarantee non-overlapping port sets.
>>>>      The length of PSID is k bits, and the default value of PSID
>>>> offset is 6 bits.
>>>>      So the bit length of PSID is variable. Thank you for your
>>>>question.
>>>>      I have reconsidered the SYNTAS of the PSID. It can never be a
>>>> negative value.
>>>>      I think Unsigned32 will be better.
>>>>
>>>> So do you just map the 4 octets of the PSID into this object?
>>>> Is it not better to then use OCTET-STRING with a SIZE(4) ??
>>>> Maybe with a DISPLY-HINT added as well
>>>>
>>>> Do you normally display the value as an (unsigned) integer?
>>>> Or do you normally display it as 0Xxxxxxxxx ??
>>>> Or maybe as bits?
>>>>
>>>> [fuyu] We always describe a Basic mapping rule as below:
>>>>
>>>>   A MAP node (CE or BR) can, via the BMR or equivalent FMR,
>>>>    determine the IPv4 address and port set as shown below:
>>>>
>>>>    EA bits offset:       40
>>>>    IPv4 suffix bits (p)  Length of IPv4 address (32) -
>>>>                          IPv4 prefix length (24) = 8
>>>>    IPv4 address:         192.0.2.18 (0xc0000212)
>>>>    PSID start:           40 + p = 40 + 8 = 48
>>>>    PSID length:          o - p = (56 - 40) - 8 = 8
>>>>    PSID:                 0x34 (1232)
>>>>
>>>>
>Not sure I understand: 0x34 (1232) ??? 0x34 in my mind is 52, no?


 [fuyu] : Ops, sorry .....it's my fault.  1232 is the port number, not the integer. 


>
>In fact I am not sure I understand much/any of the above.
>But that is OK, if people who are familiar with (or must use/implement) this
>and if they understand it then fine.
>
>>>>
>>>> So I think display the values as (unsigned) integer or display it as
>>>>0Xxxxxxxxx both will be OK.
>>>> Do you have the surggstions?
>>>>
>My personal feeling/thinking is that it is probably best displayed as
>0Xxxxxxxxx.
>That (I would think) makes it easier to see bit positions as opposed to an
>(unsigned) integer. But in princople I can live with either. The idea/hope is
>that if you add a DISPLAY HINT that everyone displays it in the same way.


[fuyu]:Thank you for your suggestions. I will define it as below:

RulePSID ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "0x:"
    STATUS       current
    DESCRIPTION
        "Represents ..."
    SYNTAX       OCTET STRING (SIZE (4))

mapRulePSID  OBJECT-TYPE
    SYNTAX     RulePSID
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
       "The PSID value algorithmically identifies a set of
               ports assigned to a CE."
          REFERENCE
                "PSID: section 5.1 of RFC 7597."
           ::= { mapRuleEntry 9 }

Do you think it will be Ok?

>>>>
>>>>>  - Section 7. Security considerations:
>>>>>
>>>>     These are the objects and their sensitivity/vulnerability:
>>>>
>>>>       mapRuleIPv6PrefixType
>>>>
>>>>       mapRuleIPv6Prefix
>>>>
>>>>       ... etc (quite a list of objects).
>>>>
>>>>     But nowhere do I see text about "their
>>>> sensitivity/vulnerability". ??
>>>>     Still to be added?
>>>>
>>>> [fuyu]: Some of the readable objects in this MIB module may be
>>>> considered sensitive or
>>>>    vulnerable in some network environments. These objects are
>>>> readable,
>>>>    so maybe they are considered sensitive or vulnerable in some use
>>>> case.
>>>>    We have a description why they are sensitive or vulnerable above
>>>> the list of objects.
>>>>
>>>> Mmmm... can you point me to that text? I do not see that you describe
>>>> the vulnerability at any place. You do describe what the objects are
>>>> for, but that does not clearly explain what the security risks are if
>>>> some unauthorize person would see them.
>>>>
>>>> If you describe that at some other place in the document, then at
>>>> least I would suggest to add a pointer to that text in the Security
>>>> COnsiderations Secion.
>>>>
>>>> [fuyu]: Sorry. I should point it more clearly. It is in the paragraph 2 of the
>>>>section 7.
>>>>      From the first sentence that "Some of the readable objects in this
>>>>MIB module may be
>>>>    considered sensitive or vulnerable..."
>>>>
>>>>
>It states that they " may be considered sensitive of vulnerable".
>But it does not state WHY or IN WHAT CIRCUMSTANCES they might be
>vulnerable.
>What bad things are there that an intruder can do (or find out) when
>he/she gets read access to these objects?
>I.e. does he get to see confidential or private information? Does he learn
>about a competitors internal network structure? Or something else?

[fuyu] : I will update it in more detail in this paragraph.Thanks.
>
>Bert

Thanks again
Yu