Re: [Softwires] Review of draft-ietf-softwire-map-mib-09

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

Hi Ian,
Thanks for your comments.
Please see my reply inline.


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Ian Farrer
>Sent: Tuesday, May 30, 2017 5:37 PM
>To: [e-mail]
>Cc: Softwires-wg
>Subject: [Softwires] Review of draft-ietf-softwire-map-mib-09
>
>Hi,
>
>Here is a review of the current version of the draft.
>
>Cheers,
>Ian
>
>Introduction
>
>a1) This needs to be updated: RFC7597 is for MAP-E and encapsulation is
>the single mode described there. RFC7599 deals with translation and so
>probably doesn’t need to be mentioned at all as it’s not part of the scope.

[Yu]:ok, I will update the description to exclude MAP-T.

>a2) Section 4.1.2
>The description of error cases is not correct. The checks that are
>performed by both CE and BR validate that the v6, v4 and l4 ports are
>consistent, not just the v6 and dest. ports. Please check RFC7597 section
>8.1.

[Yu]: From the section 8.1 of RFC7597 described: 
  "A MAP BR receiving IPv6 packets selects a best matching MAP domain
   rule (Rule IPv6 prefix) based on a longest address match of the
   packet's IPv6 source address, as well as a match of the packet
   destination address against the configured BR IPv6 address(es).  The
   selected MAP Rule allows the BR to determine the EA-bits from the
   source IPv6 address.
   To prevent spoofing of IPv4 addresses, any MAP node (CE and BR) MUST
   perform the following validation upon reception of a packet.  First,
   the embedded IPv4 address or prefix, as well as the PSID (if any),
   are extracted from the source IPv6 address using the matching MAP
   Rule.  These represent the range of what is acceptable as source IPv4
   address and port.  Second, the node extracts the source IPv4 address
   and port from the IPv4 packet encapsulated inside the IPv6 packet.
   If they are found to be outside the acceptable range, the packet MUST
   be silently discarded and a counter incremented to indicate that a
   potential spoofing attack may be underway. "

So I will change the description of error check as below:
  - 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).
  - 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.


>MIB Comments:
>
>b1) It appears that the intention to provide a single model to be used by
>both BR and CE. For ‘mapRuleBRIpv6Address, the description only
>provides information about what the CE does with this value. Is it valid for
>a BR? What should the BR do with it?

[Yu]: As described in section 7.2 of RFC7597, 
    "If the BR IPv6 address is anycast, the relay MUST use this anycast 
     IPv6 address as the source address in packets relayed to CEs"
    So I will add a description for the BR in the definition. 

>Also, for the ‘mapRuleType’ field - Is there a case where a rule
>provisioned to a BR is not an FMR? (I’m not familiar enough with MAP BR
>implementations to know if this is the case)

[Yu]: In my understanding, as described in the section 7 of RFC7597, the first 
paragraph, 
   "For a given MAP domain, the BR and CE MUST be configured with the
   following MAP elements.  The configured values for these elements are
   identical for all CEs and BRs within a given MAP domain.

   o  The Basic Mapping Rule and, optionally, the Forwarding Mapping
      Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and
      Length of EA bits."

In my understanding for above, I think the BR must be configured with the BMR. 

>b2)   mapRuleID OBJECT-TYPE
>           DESCRIPTION
>                        "An identifier used to distinguish the multiple
>mapping
>           rule which is unique with each CE in the same BR.”
>
>[if - The description is unclear. If I understand the purpose of this object, it
>is to give a unique identifier to each rule. If this is the case, I would propose:
>“A unique identifier used to distinguish mapping
>           rules.”

[Yu]:Yes, your understanding is right. I will update the description as yours.

>b3) The DESCRIPTION fields of  mapRulePSIDLen and mapRuleOffset are
>identical. The text makes sense for mapRulePSIDLen, but is incorrect for
>mapRuleOffset.

[Yu]: Opps, sorry, it's a fault. 
   I will change the definition as below:
   mapRuleOffset OBJECT-TYPE
       SYNTAX     Unsigned32(0..15)
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
          " The number of the mapRuleOffset is 6 by default as to exclude the 
           System ports (0-1023). It is provided via the "Rule Port Mapping Parameters"
          in the Basic Mapping Rule."
       DEFVAL {6}
       ::= { mapRuleEntry 9 }


>b4)   RulePSID ::= TEXTUAL-CONVENTION
>      DISPLAY-HINT "0x:"
>      STATUS       current
>      DESCRIPTION
>          "It represents the PSID represented in the hexadecimal
>version
>           so as to display it more clearly."
>      SYNTAX       OCTET STRING (SIZE (4))
>
>[if - Is 4 correct here? The allowable range for the PSID is 0..65535 which is
>2 octets]

[Yu]: I will update it to   "SYNTAX       OCTET STRING (SIZE (2))"


> b5)  mapRuleEALen OBJECT-TYPE
>       SYNTAX     Unsigned32
>       MAX-ACCESS read-only
>       STATUS     current
>       DESCRIPTION
>          "The length of the Embedded-Address (EA) defined in
>           mapping rule which will be assigned to CE."
>      REFERENCE
>            "EA: section 3 of RFC 7597."
>       ::= { mapRuleEntry 10 }
>
>[if - This can also be constrained for allowable values (0..48)]

[Yu]：Thanks for your remind. I will update it to  "SYNTAX    Unsigned32(0..48)"

>b6) mapRuleType
>
>[if - The choice that is being presented here isn’t inline with the F-Flag field
>described in sec 4.1 of RFC7598 (and by extension the FMR description in
>RFC7597). The F flag defines if a rule can be used for forwarding (i.e. mesh
>mode), not if it is a a BMR or an FMR (a BMR can be used for mesh mode if
>the F flag is set). Any of the received rules can be considered as a suitable
>BMR via the longest prefix match.

[Yu]: I will update the definition as below: 

 RuleType ::= TEXTUAL-CONVENTION
      STATUS       current
      DESCRIPTION
         "This enumeration provides the type of the mapping rule. It defines
          tree types of mapping rules here: 
          bmr: Basic Mapping Rule (Not Forwarding Mapping Rule),
          fmr: Forwarding Mapping Rule (Not Basic Mapping Rule),
          bmrAndfmr: Basic & Forwarding Mapping Rule. The Basic Mapping Rule
          may also be a Forwarding Mapping Rule for mesh mode."
      REFERENCE   "bmr, fmr: section 5 of RFC 7597.
                   bmrAndfmr: section 5 of RFC 7597， section 4.1 of RFC 7598."
      SYNTAX       INTEGER {
          bmr(1),
          fmr(2),
          bmAndfmr(3)
          }

mapRuleType OBJECT-TYPE
       SYNTAX     RuleType
       MAX-ACCESS read-only
       STATUS     current
       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."
      REFERENCE
            "bmr, fmr: section 5 of RFC 7597.
             bmrAndfmr: section 5 of RFC 7597， section 4.1 of RFC 7598."
       ::= { mapRuleEntry 11 }


Thanks again for you review.

Cheers
Yu
______________________________________________
>Softwires mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/softwires