Subject: [Softwires] WGLC for draft-ietf-softwire-map-mib-10

From: Yong Cui <[email-masked]>
Date: Wed, 11 Oct 2017 10:40:16 +0800

Hi folks,

The authors believe the document, Definitions of Managed Objects for MAP-E (draft-ietf-softwire-map-mib-10), is mature for advancement. We are now issuing a working group last call for it.

Please send your comments, either for or against, to the WG mailing list. The WGLC will end on Oct. 24, 2017.

Thanks,

Yong & Ian

---

From: Ian Farrer <[email-masked]>
Date: Tue, 24 Oct 2017 09:54:29 +0200

Hi,

I’ve done a fairly extensive review of v10 of the draft. There’s quite a lot of comments, but nothing major.

Thanks,
Ian

General Comments

g1.
1, Introduction
[if - RFC7597 only covers MAP-E. Translation is described in RFC7599. 
I think that this text is carried over from when MAP E and T were both in the
same draft.]

Suggested rewording for this section:

"Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597] is a
stateless, automatic tunnelling mechanism for providing an IPv4 connectivity
service to end-users over a service provider's IPv6 network.

This document defines a portion of the Management Information Base
(MIB) for use with monitoring MAP-E devices."
---
g2.
In the description for mapRuleIpv4Prefix, what is the mapRuleIPv4PrefixType? 
This is the only mention of this object in the whole document.
---
g3.
Section 7 - States that there are a list of objects and their sensitivity /
vulnerability, but the list that follows only names the objects. No vulnerability
information is included.
========

Linguistic Comments

l1.
Abstract

"This memo defines a portion of the Management Information Base (MIB)
for using with network management protocols in the Internet
community.  In particular, it defines managed objects for MAP
with encapsulation (MAP-E)."

This doesn't read very clearly. A suggested rewording:
This memo defines a portion of the Management Information Base (MIB)
for Mapping Address and Port with encapsulation (MAP-E) for use with
network management protocols.
---

l2.
4 - Structure of the MIB Module

The term 'MAP specification[RFC7597]' is used several times in the section and
it is redundant. Suggest that just [RFC7597] is used. 
---

l3.
The first sentence repeats what has already been said in the abstract
and introduction. Suggest it is removed.
---

l4.
The text states that it relies on 'several parts of the IF-MIB'. Can you provide
more information about which parts and how they are used
---

l5.
4.1.1 The mapRule Subtree

The mapRule subtree describes managed objects used for managing the
   multiple mapping rules in the MAP encapsulation mode.

s/the MAP encapsulation mode./MAP-E/
---

l6.
4.1.2 The mapSecurityCheck Subtree
The mapSecurityCheck subtree is to statistic the number of invalid
   packets that have been identified.  

s/is to statistic/provides statistics for/
---

l7.
For clarity, I suggest that:
- The Border Relay (BR) will perform a validation of the consistency
  of the source IPv6 address and destination IPv6 address for the
  packet using Basic Mapping Rule (BMR).

is replaced with:
  The Border Relay (BR) will validates the received packet's source 
  IPv6 address against the configured MAP domain rule and the destination
  IPv6 address against the configured BR IPv6 address.
---

l8.
- The Map node...
s/Map/MAP/
---

5. Definitions

l9.
DESCRIPTION
      "The MIB module is defined for management of objects in the
       MAP-E BRs or CEs."

s/in the/for/
---

l10.
DESCRIPTION
    "It represents the PSID represented in the hexadecimal version
     so as to display it more clearly."

    "Indicates that the PSID is represented as hexidecimal for clarity"
---

l11.
DESCRIPTION
   "This enumeration describes the type of the mapping rule. It
    defines tree types of mapping rules here:

s/This enumeration describes/Enumerates/
---

l12.
DESCRIPTION
   "The (conceptual) table containing rule Information of
    specific mapping rule. It can also be used for row
    creation."

s/Information of/information for a/
---

l13.
DESCRIPTION
   "The IPv6 prefix defined in mapping rule which will be
    assigned to CE. The address type is given by
    mapRuleIPv6PrefixType."

s/in mapping rule which will be assigned to CE./in the mapping rule which
will be assigned to the CE./
---

l14.
DESCRIPTION
   "The length of the IPv6 prefix defined in the mapping rule.
    As a parameter for mapping rule, it will be also assigned
    to CE."

Replace with:
   "The length of the IPv6 prefix defined in the mapping rule that is assigned
   to the CE."
---

l15.
mapRuleIPv4Prefix
DESCRIPTION
   " The IPv4 prefix defined in mapping rule which will be
     assigned to CE. The address type is given by
     mapRuleIPv4PrefixType."

s/The IPv4 prefix defined in mapping rule which will be
  assigned to CE./The IPv4 prefix defined in the mapping rule which will be
    assigned to the CE./
---

l15.
mapRuleIPv4PrefixLen
DESCRIPTION
   "The length of the IPv4 prefix defined in the mapping
    rule. As a parameter for mapping rule, it will be also
    assigned to CE."

Replace with:
    "The length of the IPv4 prefix defined in the mapping rule that is assigned
to the CE."
---

l16.
mapRuleType
DESCRIPTION
   "It represents the type of the mapping rule. The value of
    1 means it is a bmr, the value 2 means it is a fmr, the
    value 3 means that the bmr is also a fmr for mesh mode."

Replace with:
    "Indicates the type of mapping rule. '1' represents a BMR. '2' represents
    an FMR and '3' is for a BMR which is also an FMR for mesh mode."
---

l17.
mapSecurityCheckTable
DESCRIPTION
   "The (conceptual) table containing information on
    MAP security checks. This table can be used to statistic
    the number of invalid packets that been identified."

s/to statistic the number of invalid packets that been identified./for
statistics on the number of invalid packets that have been identified./
---

l18.
mapSecurityCheckEntry
DESCRIPTION
   "Each entry in this table contains the information on a
    particular MAP SecurityCheck."

s/contains the information/contains information/
---

l19.
mapSecurityCheckInvalidv4
DESCRIPTION
   "The Map node (CE and BR) will check that the received
    packets'source IPv4 address and port is in the range
    derived from matching MAP Rule.So this object indicate
    the number of the invalid IPv4 packets received by the
    MAP domain."

Replace with:
  "Indicates the number of received IPv4 packets which do not have 
   a payload source IPv4 address or port within the range defined in the 
   matching MAP rule."
---

l20.
mapSecurityCheckInvalidv6
DESCRIPTION
   "The BR will perform a validation of the consistency
    of the source IPv6 address and destination IPv6 address
    for the packet using Basic Mapping Rule (BMR). So this
    object indicate the number of the invalid IPv6 packets
    received by the BR."

Replace with:
   "Indicates the number of received IPv6 packets which do not have 
    a source or destination IPv6 address matching a Basic Mapping Rule."
---

l21.
mapMIBRuleGroup
DESCRIPTION
   " The collection of this objects are used to give the
    information of mapping rules in MAP-E."

Replace with:
   "The group of objects used to describe the MAP-E mapping rule."
---

l22.
mapMIBSecurityGroup
DESCRIPTION
" The collection of this objects are used to give the
information on MAP security checks."

Replace with:
"The group of objects used to provide information on the MAP-E security checks."
---

l23.
Section 7 Security Considerations

s/(for example by using IPSec), even then, there is no control/
(for example by using IPSec), there is no control/
---

idnits 2.15.00 

/tmp/draft-ietf-softwire-map-mib-10.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (September 15, 2017) is 39 days in the past.  Is this
     intentional?

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC7598' is defined on line 636, but no explicit
     reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 2629
     (Obsoleted by RFC 7749)

     Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------

> On 11. Oct 2017, at 04:40, Yong Cui <[email-masked]> wrote:
> 
> Hi folks,
>

---

From: "Yu Fu" <[email-masked]>
Date: Wed, 25 Oct 2017 17:28:59 +0800

Hi Ian,

Thanks for your thorough comments. Please see my reply inline.

>(MIB) for use with monitoring MAP-E devices."

[Yu]:Done

>This is the only mention of this object in the whole document.

[Yu]: Sorry, we had delete the definition of mapRuleIPv4PrefixType since 08 version. I will delete 

the description for this.

>information is included.

[Yu]: It has a description as followed :

“Some of the readable objects in this MIB module (i.e., objects with a

   MAX-ACCESS other than not-accessible) may be considered sensitive or

   vulnerable in some network environments. It is thus important to

   control even GET and/or NOTIFY access to these objects and possibly

   to even encrypt the values of these objects when sending them over

   the network via SNMP”

“Objects that reveal rule information of the MAP Domain: Various objects can reveal the

   rule information of the map domain.  A curious outsider could monitor

   these to assess the number of rules and the IPv6 prefix performed in

   this domain.  Further, an intruder could use the information to guess

   the address-sharing ratios of the ISPs.”

[Yu]: The objects in the list reveal the rule information and are readable. So they are vulnerable.

>idnits 2.15.00 

[Yu]: I accept all the comments and an updated version will be submitted soon.

Thanks again

Cheers

Yu

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 24, 2017 3:54 PM
To: Yong Cui
Cc: [email-masked]; [email-masked]
Subject: Re: WGLC for draft-ietf-softwire-map-mib-10

Hi,

Thanks,

Ian

General Comments

g1.

1, Introduction

same draft.]

---

g2.

---

g3.

information is included.

========

Linguistic Comments

l1.

Abstract

---

l2.

---

l3.

---

l4.

---

l5.

---

l6.

---

l7.

is replaced with:

---

l8.

- The Map node...

s/Map/MAP/

---

5. Definitions

l9.

DESCRIPTION

       MAP-E BRs or CEs."

s/in the/for/

---

l10.

DESCRIPTION

---

l11.

DESCRIPTION

---

l12.

DESCRIPTION

    creation."

---

l13.

DESCRIPTION

    mapRuleIPv6PrefixType."

---

l14.

DESCRIPTION

    to CE."

Replace with:

   to the CE."

---

l15.

mapRuleIPv4Prefix

DESCRIPTION

     mapRuleIPv4PrefixType."

    assigned to the CE./

---

l15.

mapRuleIPv4PrefixLen

DESCRIPTION

    assigned to CE."

Replace with:

to the CE."

---

l16.

mapRuleType

DESCRIPTION

Replace with:

---

l17.

mapSecurityCheckTable

DESCRIPTION

---

l18.

mapSecurityCheckEntry

DESCRIPTION

---

l19.

DESCRIPTION

    MAP domain."

Replace with:

   matching MAP rule."

---

l20.

DESCRIPTION

    received by the BR."

Replace with:

---

l21.

mapMIBRuleGroup

DESCRIPTION

Replace with:

---

l22.

mapMIBSecurityGroup

DESCRIPTION

Replace with:

---

l23.

---

idnits 2.15.00 

 
     No issues found here.

     No issues found here.

     No issues found here.
 
  Miscellaneous warnings:

 

 

 

Hi folks,

Thanks,

Yong & Ian

---

From: Ian Farrer <[email-masked]>
Date: Thu, 26 Oct 2017 08:57:06 +0200

Hi Yu,

Please see below. 

Thanks,
Ian

> On 25. Oct 2017, at 11:28, Yu Fu <[email-masked]> wrote:
> 
> >g3.

[if - OK. The current text isn’t very clear. Can I propose the following text as a replacement?

Some of the MIB model's objects are vulnerable as the information
which they hold may be used for targeting an attack against a MAP node (CE or BR).
E.g., an intruder could use the information to help deduce the customer IPv4 and IPv6
topologies and address-sharing ratios in use by the ISP.

The following is a list of the objects that have this vulnerability:
]

---

From: Yong Cui <[email-masked]>
Date: Fri, 27 Oct 2017 10:37:15 +0800

Hi folk,

We don’t have major objections to advance the document during the WGLC.
As a result, before we advance the doc, we would encourage the authors to update a new version to address the minor comments.

Thanks so much for the Ian’s thorough review and the authors’ contribution.

Yong

> 在 2017年10月26日，14:57，Ian Farrer <[email-masked]> 写道：
> 
> Hi Yu,
> 
> Please see below. 
> 
> Thanks,
> Ian
>

---

From: "Yu Fu" <[email-masked]>
Date: Mon, 30 Oct 2017 10:57:02 +0800

Hi Ian,

I will do as you suggested.

An updated version will be submitted soon. 

Thanks again

Yu

From: Ian Farrer [mailto:[email-masked]] 
Sent: Thursday, October 26, 2017 2:57 PM
To: Yu Fu
Cc: [email-masked]; [email-masked]; Yong Cui
Subject: Re: WGLC for draft-ietf-softwire-map-mib-10

Hi Yu,

Please see below. 

Thanks,

Ian

   the network via SNMP”

 

]