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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
