Re: [Softwires] early MIB Doctor review for draft-ietf-softwire-map-mib-07
Terry Manderson <terry.manderson@icann.org> Wed, 17 May 2017 15:02 UTC
Return-Path: <terry.manderson@icann.org>
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 61F20129C5F; Wed, 17 May 2017 08:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 HE-O3nVop4sD; Wed, 17 May 2017 08:02:37 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B951293F5; Wed, 17 May 2017 07:56:04 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 17 May 2017 07:56:02 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 17 May 2017 07:56:02 -0700
From: Terry Manderson <terry.manderson@icann.org>
To: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>, Yu Fu <fuyu@cnnic.cn>
CC: "draft-ietf-softwire-map-mib.all@ietf.org" <draft-ietf-softwire-map-mib.all@ietf.org>, 'MIB Doctors' <mib-doctors@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>
Thread-Topic: early MIB Doctor review for draft-ietf-softwire-map-mib-07
Thread-Index: AQHSzt4ufXUW3DrbCUefV2/mMb2PhqH5up6A
Date: Wed, 17 May 2017 14:56:01 +0000
Message-ID: <D359882F-7DE4-405E-BEFF-EF31B972992D@icann.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> <002401d2cedd$6efb6870$4cf23950$@cn> <e93c0505-20c8-74d5-1c34-b80cf102a5f2@bwijnen.net>
In-Reply-To: <e93c0505-20c8-74d5-1c34-b80cf102a5f2@bwijnen.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3577913755_241280046"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/IJA0-cwh7NszawCmQl5FIGkDuQ0>
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 15:02:39 -0000
Bert, Yu, Thank you very much for your review and activity on this! Cheers Terry On 17/05/2017, 5:17 PM, "Bert Wijnen (IETF)" <bertietf@bwijnen.net> wrote: thank you. I am happy mow Bert On 17/05/2017 09:15, Yu Fu wrote: > 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