RE: Gen-ART Review of draft-ietf-dime-4over6-provisioning-03

[<[e-mail]>]

Dear Russ,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Russ Housley [mailto:[e-mail]]
> Envoyé : dimanche 12 juillet 2015 23:28
> À : [e-mail]
> Cc : IETF; IETF Gen-ART
> Objet : Gen-ART Review of draft-ietf-dime-4over6-provisioning-03
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> This review is in response to a request for early Gen-ART review.
> 
> Document: draft-ietf-dime-4over6-provisioning-03
> Reviewer: Russ Housley
> Review Date: 2015-07-12
> IETF LC End Date: 2015-07-20
> IESG Telechat date: unknown
> 
> Summary: Almost Ready
> 
> Major Concerns:
> 
> None
> 
> 
> Minor Concerns:
> 
> In section 2.4, please replace "the MAP-E document" with a reference to
> [I-D.ietf-softwire-map].

[Med] Fixed. 

> 
> The Security Considerations section talks about two concerns: (1)
> man-in-the-middle modification of the AVP contents leading to
> misconfiguration, and (2) disclosure of subscriber addresses allowing
> the attacker to track subscriber activity.  If I have understood
> these properly, the second one is more of a privacy consideration.
> Please consider moving this to a separate section on privacy
> considerations.
> 
[Med] I updated the text as follows:

OLD:

7.  Security Considerations

   The AVPs defined in this document face two threats, both dependent on
   man-in-the-middle attacks on the Diameter delivery path.  The more
   serious threat is denial of service through modification of the AVP
   contents leading to misconfiguration.  The lesser threat is
   disclosure of subscriber addresses allowing the attacker to track
   subscriber activity.

   Diameter security is currently provided on a hop-by-hop basis (see
   Section 2.2 of [RFC6733]).  The Diameter end-to-end security problem
   has not been solved, so man-in-the-middle attacks on Diameter peers
   along the path are possible.  The present document does not propose
   to solve that general problem, but simply warn that it exists.

NEW:

6.  Security Considerations

6.1.  Man-In-The-Middle (MITM) Attacks

   The AVPs defined in this document face two threats, both dependent on
   man-in-the-middle (MITM) attacks on the Diameter delivery path.  The
   first threat is denial-of-service (DoS) through modification of the
   AVP contents leading to misconfiguration (e.g., a subscriber may fail
   to access its connectivity service if an invalid IP address was
   configured, the subscriber's traffic can be intercepted by a
   misbehaving node if a fake Border Node has been configured, etc.).
   The second one is related to privacy (see Section 6.2).

   Diameter security is currently provided on a hop-by-hop basis (see
   Section 2.2 of [RFC6733]).  The Diameter end-to-end security problem
   has not been solved, so MITM attacks on Diameter peers along the path
   are possible.  The present document does not propose to solve that
   general problem, but simply warn that it exists.

   Diameter-related security considerations are discussed in Section 13
   of [RFC6733].

6.2.  Privacy

   The AVPs defined in this document reveal privacy-related information
   (e.g., disclose subscriber addresses).  This information can be used
   for tracking proposes.

   The considerations discussed in Section 13.3 of [RFC6733] MUST be
   followed.

> Returning to the first part of the security considerations, please say
> more about the possible consequences of a man-in-the-middle making
> modifications to the AVP contents.  Is there anything that the
> implementer can do to make the attack more difficult to accomplish
> or raise the likelihood of detection?
> 

[Med] These threats are not unique to this specification.  An explicit reference to the security section of the Diameter base specification is called out in the NEW text.

> 
> Other Comments:
> 
> Section 2.6 begins this way: "It appears that two items are common to
> the different transition methods and the corresponding AVPs to carry
> them can be reused...".  By the time this document achieves consensus
> and it is ready to be published as an RFC, there is no longer a need
> for such a soft touch.  I suggest: "There are two items that are common
> to the different transition methods, and the corresponding AVPs to carry
> them can be reused..."

[Med] Done. Thank you.

> 
> Section 3.3 says:
> 
>    64-Multicast-Attributes AVP MUST include at least the ASM-mPrefix64
>    AVP or the SSM-mPrefix64 AVP.
> 
>    Both the ASM-mPrefix64 AVP and the SSM-mPrefix64 AVP MAY be present.
> 
> Would it be more clear to say it this way?
> 
>    64-Multicast-Attributes AVP MUST include the ASM-mPrefix64 AVP or the
>    SSM-mPrefix64 AVP, and it MAY include both.
> 

[Med] Works for me.

> Please provide labels for Figures 5, 6, and 7.  Based on the other
> figures,
> they should probably be:
> 	- Figure 5: LW4over6-Binding AVP
> 	- Figure 6: MAP-E-Attributes AVP
> 	- Figure 7: MAP-Mapping-Rule AVP
> 

[Med] Done. Thank you.