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

[Terry Manderson <[e-mail]>]

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)" <[e-mail]> 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
    >
    >
    >