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

["Bert Wijnen (IETF)" <[e-mail]>]

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