[bess] Secdir last call review of draft-ietf-bess-mvpn-expl-track-11

[Christian Huitema]

Reviewer: Christian Huitema
Review result: Has Nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I have reviewed version 11 of draft-ietf-bess-mvpn-expl-track. From a security
point of view this draft is almost ready, except for the small issue that no
mitigation is proposed for the one vulnerability discussed in the security
section.

Multicast VPN (MVPN) operates by setting a routing tree between the ingress
site and the egress sites. In MVPN, that tree is built by the network provider,
and includes multicast nodes inside the network as well as the customer facing
"provider edge" routers. Ingress nodes do not necessarily know how many egress
nodes have joined the multicast tree at a given time. The purpose of Explicit
Tracking is to provide that information.

Explicit tracking procedures are defined by RFC 6513, RFC 6514, and RFC 6625.
They rely on MVPN tunnel attributes to trigger the setup of Selective Provider
Multicast Service Interface Auto-Discovery routes. The current draft
complements these procedures to cover a number of cases not yet covered, in
particular when the multicast groups for which information is desired are
indentified by wild cards instead of the full combination of source and group
identifiers. This is done by defining an additional flag (LIR-pF) in the tunnel
attributes.

The security considerations list only one issue: that abuse of wild card
definitions in large networks could trigger a large amount of explicit tracking
traffic, which might affect the performance of the control plane. Otherwise,
this draft does not change the security properties of MVPN discussed in RFC
6513 and RFC 6514. That seems fair, but the draft then says that studying
mitigations for the potential abuse is out of scope, which leaves me a bit
puzzled. I can think of a variety of techniques to either spread the explicit
tracking traffic over time, rate limit it, or aggregate it in intermediate
nodes. Some of those techniques could probably be proposed as a basic
mitigation.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

[Jaikumar Somasundaram]

Thanks a lot Jorge, for your help to clarify that the traffic towards CE will 
get dropped
when the Primary Path failed, until the a new DF is elected and becomes in 
forwarding state,
as per RFC7432.

Thanks & Regards
Jaikumar S

From: Jaikumar Somasundaram
Sent: Friday, October 5, 2018 10:37 AM
To: 'Rabadan, Jorge (Nokia - US/Mountain View)' ; 
bess@ietf.org
Cc: Jiang He ; P Muthu Arul Mozhi 

Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Thanks Jorge.

I think that this optimization is not mentioned in the RFC 7432.

Section 8.5 of RFC 7432:

  In the case of link or port failure, the affected PE withdraws its
  Ethernet Segment route.  This will re-trigger the service carving
  procedures on all the PEs in the redundancy group.  For PE node
  failure, or upon PE commissioning or decommissioning, the PEs
  re-trigger the service carving.

Section 13.2.1 of RFC 7432:


  - If the PE is not the designated forwarder on any of the ESIs for

 the Ethernet tag, the default behavior is for it to drop the

 packet.

Section 14.1.1 of RFC 7432:


   If there is more than one backup PE for a given ES, the remote PE

   MUST use the primary PE's withdrawal of its set of Ethernet A-D per

   ES routes as a trigger to start flooding traffic for the associated

   MAC addresses (as long as flooding of unknown unicast packets is

   administratively allowed), as it is not possible to select a single

   backup PE.

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 10:11 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jai,

Yes, but see my other email.. if you only have two PEs in the ES, you may 
optimize things.
Thanks.
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 5:39 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jorge,

Yes, new DF will be identified after the new election.
Election process will need to wait for DF election timer period, say 3s or the 
configured timer period.
Until this DF election timer expiry and new DF is identified, the traffic 
towards CE coming to the node this PE
will get dropped. Please let me know if my understanding is right?

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 8:06 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Jai,

The new DF becomes DF because it re-runs DF election.
Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 12:23 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 3:33 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Thanks Jorge for the quick reply.
Please find further question below.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mai