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

["Yu Fu" <[e-mail]>]

Hi Ian,

 

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

 

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

 

[Yu]:Done

 

>g2.

>In the description for mapRuleIpv4Prefix, what is the mapRuleIPv4PrefixType? 

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

 

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

 

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

 

>Linguistic Comments

>idnits 2.15.00 

 

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

 

Thanks again

 

Cheers

Yu

 

 

 

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

 

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 <[e-mail]> wrote:

 

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