Re: [nvo3] Can Overlay nodes see any difference on how ECMP is used by the underlay in building the IPSec tunnels for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface?

Linda,

To maximize the bandwidth utilization within data center networks, it's much desirable to transport traffic between two NVE/PE nodes across ECMPs of the underlay. It has nothing to do with overlay nodes and overlay controllers.

Best regards,
Xiaohu

> -----Original Message-----
> From: Linda Dunbar
> Sent: Thursday, June 16, 2016 4:15 PM
> To: Tom Herbert; Xuxiaohu; I2NSF@ietf.org
> Cc: Lou Berger; Liyizhou; NVO3; IPsec@ietf.org
> Subject: Can Overlay nodes see any difference on how ECMP is used by the
> underlay in building the IPSec tunnels for a specific time span? (was : Flow
> Security Policies exchanged over I2NSF service layer interface?
> 
> Xiao Hu and Tom,
> 
> Do you think that Overlay nodes will see any difference on How ECMP is used by
> the underlay to build the IPSec tunnel between Ingress/Egress nodes for the
> overlay network nodes?
> 
> If yes, how can Overlay controller specify its specific requests to the underlay? Is
> "needing ECMP" or "Don't care ECMP" be good enough?
> 
> Thanks, Linda
> 
> -----Original Message-----
> From: Tom Herbert [mailto:tom@herbertland.com]
> Sent: Wednesday, June 15, 2016 11:28 PM
> To: Xuxiaohu
> Cc: Lou Berger; Linda Dunbar; Liyizhou; NVO3; IPsec@ietf.org
> Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting IPSec
> connection from the Underlay for a specific time span? (was : Flow Security
> Policies exchanged over I2NSF service layer interface?
> 
> On Wed, Jun 15, 2016 at 8:03 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> > Hi Lou,
> >
> > If IPsec tunnels are used within data centers, the security need is well satisfied.
> However, the ECMP capability built on the UDP tunnels is lost at all. So, how
> about encapsulating IPsec ESP over UDP tunnels for load-balancing
> improvement purpose? Note that this ESP-over-UDP encapsulation is different
> from the ESP-over-UDP encapsulation as described in RFC3948: the former uses
> the UDP tunnel for load-balancing improvement purpose and therefore the
> source port is used as an entropy field, in contrast, the latter uses the UDP
> tunnel for NAT traversal purpose and therefore the source port is set to a
> constant value (i.e.,4500).
> >
> > By the way, I had wrote a draft about this ESP-over-UDP approach (w/o
> submission) three years ago when considering how to use UDP tunnels to
> transport MPLS and IP traffic. If there is enough interest on this ESP-over-UDP
> approach, I can update it and then submit it for further discussion.
> >
> Using the flow label for ECMP (RFC6438) solves this problem without requiring
> the additional overhead of a UDP header.
> 
> Tom
> 
> > Best regards,
> > Xiaohu
> >
> >> -----Original Message-----
> >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lou Berger
> >> Sent: Wednesday, June 15, 2016 11:00 PM
> >> To: Linda Dunbar; Liyizhou; NVO3
> >> Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting
> >> IPSec connection from the Underlay for a specific time span? (was :
> >> Flow Security Policies exchanged over I2NSF service layer interface?
> >>
> >>
> >> Yes -- this is a real use case.
> >>
> >> This use case (overlays interconnected over IPsec tunnels with NVE
> >> end
> >> points) motivated our work on RFC5566 and we built supported for it
> >> (as well as other tunnel technologies) in a quagga based NVO3 controller.
> >> This code is publicly available, but is not yet part of a standard quagga
> release.
> >>
> >> Lou
> >>
> >> On 6/15/2016 8:55 AM, Linda Dunbar wrote:
> >> >
> >> > NVO3 Participants,
> >> >
> >> >
> >> >
> >> > I2NSF (Interface to Network Security function) has a work item in
> >> > defining the flow security policy between domains (which includes
> >> > inquiry of the capability from one domain to another and the actual
> >> > flow policy rules from one domain to another).
> >> >
> >> > Very often, the paths (or links) among nodes of a overlay network
> >> > are provided by other network operators (a.k.a. "underlay
> >> > network").  The flow policy rules are intended to filter out
> >> > unwanted traffic from underlay network so that various attack
> >> > traffic won't saturated the access links to the overlay nodes.
> >> >
> >> >
> >> >
> >> > One interesting scenario brought up is Overlay nodes may need to
> >> > request some traffic to be traversing IPsec channel. To achieve
> >> > this goal, it is necessary for Overlay Network controller to
> >> > inquire if the needed IPsec resource are even available before send
> >> > the request (may even involve AAA process between controllers of
> >> > each corresponding domain ).
> >> >
> >> >
> >> >
> >> > Want to have a survey if people see the use case of Overlay Network
> >> > needing portion of traffic to be through IPSec channel?
> >> >
> >> > IPSec is supposed to be between two end nodes. Here we assume that
> >> > the Overlay nodes don't have the resource or capability for IPsec,
> >> > but expect IPsec between flow's ingress and egress nodes (i.e. NVE).
> >> >
> >> >
> >> >
> >> > Any opinion is appreciated.
> >> >
> >> > Thanks,
> >> >
> >> > Linda
> >> >
> >> >
> >> >
> >> > *From:*Linda Dunbar
> >> > *Sent:* Tuesday, June 14, 2016 4:03 PM
> >> > *To:* 'christian.jacquenet@orange.com'; BOUCADAIR Mohamed IMT/OLN
> >> > *Cc:* I2NSF@ietf.org
> >> > *Subject:* Any use cases of Overlay network requesting IPSec
> >> > connection from the Underlay for a specific time span? (was : Flow
> >> > Security Policies exchanged over I2NSF service layer interface?
> >> >
> >> >
> >> >
> >> > Christian,
> >> >
> >> >
> >> >
> >> > Your feedback seems to suggest that Overlay network Controller may
> >> > send request to the underlay network controller requesting IPsec
> >> > connections among overlay nodes. Do I understand you correctly?
> >> >
> >> >
> >> >
> >> > Are there any use cases of overlay network needing IPSec among
> >> > their nodes only for a specific time span? i.e. Time based IPSec connection?
> >> >
> >> >
> >> >
> >> > Linda
> >> >
> >> >
> >> >
> >> > *From:*christian.jacquenet@orange.com
> >> > <mailto:christian.jacquenet@orange.com>
> >> > [mailto:christian.jacquenet@orange.com]
> >> > *Sent:* Monday, June 13, 2016 11:23 AM
> >> > *To:* Linda Dunbar; BOUCADAIR Mohamed IMT/OLN
> >> > *Subject:* RE: Any feedback on the Protocol Independent Flow
> >> > Security Policies exchanged over I2NSF service layer interface?
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > *[snip]*
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Very often, the paths (or links) among nodes of a overlay network
> >> > are provided by other network operators (a.k.a. "underlay
> >> > network").  Very much like traditional networks placing FW
> >> > (Firewall) or IPS (Intrusion Prevention System) on the wire to
> >> > enforce the flow security rules, I2NSF *_Protocol Independent Flow
> >> > Security Policies_* can be used by overlay networks to request
> >> > certain flow based security rules to be enforced by its underlay
> >> > networks, to prevent the unwanted attacks traffic from occupying
> >> > the physical links and ports to the overlay network nodes, and to
> >> > avoid the overlay nodes' CPU/Storage/Port utilization being
> >> > consumed down by the various attacks.  Here is one example of
> >> > "Overlay Video Communication network" exchange Flow Policies to the
> Underlay network.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > cid:image001.png@01D1B516.7F74E410
> >> >
> >> >
> >> >
> >> > */[CJ] /*The above example clearly shows the necessary interaction
> >> > between the two PDPs/controllers, to make sure that decisions made
> >> > by the network controller accommodate the needs of the video
> >> > customer as possibly expressed towards the video controller: for
> >> > example, customer demands that the confidentiality of the
> >> > videoconference needs to be preserved, thereby suggesting the use
> >> > of the IPsec protocol suite. The video controller may enforce an
> >> > IPsec design based upon the transport mode, whereas the network
> >> > controller is solicited to allocate IPsec resources (read for
> >> > example no AH, ESP in NULL mode) accordingly. This may possibly
> >> > raise conflicting configuration tasks (the video controller uses
> >> > AH, the network controller doesn't), thereby leading to
> >> > inconsistency that may jeopardize the service. Whether BGP FS is
> >> > used to carry security policy information between the two
> >> > controllers is hardly the point, imho: what matters is the
> >> > consistency of the (flow-based security policies enforced by both parties,
> and which should be derived from the customer's requirements (if any).
> >> >
> >> > The goal of I2NSF is to specify the common information model and
> >> > data model for the *_ Protocol Independent Flow Security Policies
> >> > _*which can be queried and set between domains.
> >> >
> >> > [CJ] OK.
> >> >
> >> > * *
> >> >
> >> > https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-
> >> > mit igation-api/ is just the starting point. (needs more work to
> >> > improve the clarity).
> >> > We are asking if people to express their opinion on this work to
> >> > the I2NSF@ietf.org <mailto:I2NSF@ietf.org> list.
> >> >
> >> > [CJ] I need to read this draft and will get back to you
> >> > accordingly, but this may take a couple of weeks as I'm pretty busy for the
> time being.
> >> >
> >> >
> >> >
> >> > I'll let Med further comment as appropriate.
> >> >
> >> >
> >> >
> >> > Cheers,
> >> >
> >> >
> >> >
> >> > Christian.
> >> >
> >> >
> >> >
> >> > Thanks, Linda
> >> >
> >> >
> >> >
> >> >
> >>
> _____________________________________________________________
> >> _________
> >> > ___________________________________________________
> >> >
> >> > Ce message et ses pieces jointes peuvent contenir des informations
> >> > confidentielles ou privilegiees et ne doivent donc pas etre
> >> > diffuses, exploites ou copies sans autorisation. Si vous avez recu
> >> > ce message par erreur, veuillez le signaler a l'expediteur et le
> >> > detruire ainsi que les pieces
> >> jointes. Les messages electroniques etant susceptibles d'alteration,
> >> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> >> >
> >> > This message and its attachments may contain confidential or
> >> > privileged information that may be protected by law; they should
> >> > not be
> >> distributed, used or copied without authorisation.
> >> > If you have received this email in error, please notify the sender
> >> > and delete this
> >> message and its attachments.
> >> > As emails may be altered, Orange is not liable for messages that
> >> > have been
> >> modified, changed or falsified.
> >> > Thank you.
> >> >
> >> >
> >> > _______________________________________________
> >> > nvo3 mailing list
> >> > nvo3@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/nvo3
> >>
> >>
> >> _______________________________________________
> >> nvo3 mailing list
> >> nvo3@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nvo3
> >
> > _______________________________________________
> > nvo3 mailing list
> > nvo3@ietf.org
> > https://www.ietf.org/mailman/listinfo/nvo3