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
- [Softwires] FW: early MIB Doctor review for draft… Yu Fu
- Re: [Softwires] early MIB Doctor review for draft… Yu Fu
- [Softwires] FW: early MIB Doctor review for draft… Yu Fu
- [Softwires] FW: early MIB Doctor review for draft… Yu Fu
- Re: [Softwires] early MIB Doctor review for draft… Bert Wijnen (IETF)
- Re: [Softwires] early MIB Doctor review for draft… Yu Fu
- Re: [Softwires] early MIB Doctor review for draft… Bert Wijnen (IETF)
- Re: [Softwires] early MIB Doctor review for draft… Terry Manderson
- Re: [Softwires] early MIB Doctor review for draft… Yu Fu