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

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

inline

On 16/05/2017 09:10, Yu Fu wrote:
> Hi Bert,
>
> Please see my reply inline.
>
> I have cc the email to the softwire WG so that the WG could see the MIB Doctor's comments.
>
>>> In the MIB module itself:
>>>
>>>   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.

>>>
>>>
>>>    mapRuleIPv6PrefixType OBJECT-TYPE
>>>           SYNTAX     InetAddressType
>>>           MAX-ACCESS read-only
>>>           STATUS     current
>>>           DESCRIPTION
>>>               "This object MUST be set to the value of ipv6(2) to
>>>                present the IPv6 address.It describes the
>>>                address type of the mapRuleIPv6Prefix and
>>>                mapRuleBRIPv6Address."
>>>
>>>    Such MUST language is not recommended. The way to specify
>>> such
>>> mandatory
>>>    value you best use the MODULE COMPLIANCE statement. Such is
>>> RECOMMENDED
>>>    as per RFC4181, page 26
>>>
>>> [fuyu]: I will delete the MUST in the updated version.
>>>
>> But if you change to InetAddressIPv6 and InetAddressIPv4 (as you state
>> below), then there is no need for an InetAddressType.
>
>
> [fuyu] :Yes, I will delete the object of mapRuleIPv6PrefixType and mapRuleIPv4PrefixType too. Thank you for your remind.
>
OK
>>>
>>>
>>>    mapRuleIPv6Prefix OBJECT-TYPE
>>>           SYNTAX     InetAddress(SIZE (0..16))
>>>           MAX-ACCESS read-only
>>>           STATUS     current
>>>           DESCRIPTION
>>>              "The IPv6 prefix defined in mapping rule which will be
>>>               assigned to CE. The address type is given by
>>>               mapRuleIPv6PrefixType."
>>>           ::= { mapRuleEntry 3 }
>>>
>>>    mmmmm, when the InetAddressType is ipv6(2), then my
>>> understanding
>>> of RFC4001
>>>    is that the SIZE for the InetAddress MUST be 16. Maybe Juergen
>>> can chime in here?
>>>
>>>    And if it is ALWAYS an IPv6 address, then maybe it is even better
>>> to use
>>>    InetAddressIPv6 as the OBJECT-TYPE.
>>>
>>>    I see the same set of 2 objects for IPv4.
>>>
>>>    In my view, the idea of InetAddressType and InetAddress
>>> were/are
>>> to allow yopu to specify
>>>    one or a single pair that can hold each of the 2 (or even more if
>>> needed) AddressTypes.
>>>
>>>    So why are there separate objects for IPv4 and IPv6 ???
>>>
>>> [fuyu]:OK, I will change it into
>>>
>>>      mapRuleIPv6Prefix OBJECT-TYPE
>>>            SYNTAX     InetAddressIPv6
>>>            MAX-ACCESS read-only
>>>            STATUS     current
>>>            DESCRIPTION
>>>               "The IPv6 prefix defined in mapping rule which will be
>>>                assigned to CE. The address type is given by
>>>                mapRuleIPv6PrefixType."
>>>            ::= { mapRuleEntry 3 }
>>>
>>>      mapRuleIPv4Prefix OBJECT-TYPE
>>>           SYNTAX     InetAddressIPv4
>>>           MAX-ACCESS read-only
>>>           STATUS     current
>>>           DESCRIPTION
>>>              " The IPv4 prefix defined in mapping rule which will be
>>>                assigned to CE. The address type is given by
>>>                mapRuleIPv4PrefixType."
>>>           ::= { mapRuleEntry 6 }
>>>
>>> Do you think it OK?
>>>
>> Yes. And you then do not need the InetAddressType object.
>
> [fuyu] : Yes, I will delete the objects of mapRuleIPv6PrefixType and mapRuleIPv4PrefixType too. Thank you for your remind.
>
ok

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

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.


>>>
>>>
>>>     mapRulePSIDLen  OBJECT-TYPE
>>>           SYNTAX     Integer32
>>>
>>>     My understanding sofar is that this object can never take a
>>> negative value,
>>>     so Unsigned32 would be better I think.
>>>
>>> [fuyu]: I will change it into Unsigned32 in the updated version.
>>>
>> Does it also make sense to add a range? (what are the possible values?) ??
>
> [fuyu]  The value range of mapRulePSIDLen is greater than or equal to 0 and no more than 16, so do you think define as below
>
>       mapRulePSIDLen  OBJECT-TYPE
>            SYNTAX     Unsigned32(0..16)
>
>   Will it make sense?
>
>
I think that makes sense. Now you can see (machine readable) what the range
of valid values is.

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

Bert
>> Bert
>
> Thanks a lot
>
> Yu
>
>
>