Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset

From: <[email-masked]>
Date: Thu, 10 Jul 2014 09:48:34 +0000

Hi all,

I've read the draft and IMO it is useful and address a real use case (enforcing infrastructure security ACL).

First issue with existing infrastructure ACL is to make sure that all ACL on all routers are up to date. On this point, the draft does the job.
A second issue with existing ACL is to make sure that the ACL are applied to all the right interfaces. Especially as new interfaces gets deployed, it gets harder to have a hard guaranty that all interfaces have the right type of ACL (someone could deploy a new external interface but forgot to configure it's interface-set type). On this point, IMO the draft could be improved.
To cover this, I would propose to add a range for IANA allocation, and to define a few well know values, such as interfaces running the IGP (which are known to be internal/trusted), interfaces running eBGP (which are known to be external/untrusted).
Such well known types are automatically affected to interfaces by the implementation and hence are not subject to service provider misconfiguration.

This would translate into the proposed following additional text:

6. IANA Considerations 

The IANA is requested to create and maintain a registry entitled
   "Assigned Flow spec interface-set" with the following
   registration procedure:

    Registry Name: Assigned Flow spec interface-set

       Range              Registration Procedures
       -----------        -------------------------
       0x0000-3EFF        Reserved for private use.
       0x3F00-3FFF        Standards Action/Early IANA Allocation.

The IANA is requested to update the registry "Assigned Flow spec interface-set" as follows:

0x3F00: IGP interface
0x3F01: non IGP interface
0x3F02: eBGP interface
0x3F03: non eBGP interface
0x3F04: VRF interface
0x3F05: non VRF interface
	   
---------
Please find below some more minor comments:
1)
"An interface-set extended community with both flags set to zero MUST be
   treated as an error and as consequence, the FlowSpec update MUST be
   discarded."
- What's the reason to discard it? A priori looks to me not the right thing, from a security standpoint, to allow dropping a whole ACL/security rule, by adding a community. (however, I agree that if you can add a community, you can probably alter/drop the rule, hence I can't really provide an example where this would matter).  
Plus IMO, I don't see this as an error. It's just a "NOP" instruction.
- "MUST be discarded": please use the draft-ietf-idr-error-handling terminology (I guess "Treat-as-withdraw" while your term is close to "attribute discard").

2) According to your text in section 4, I would move [I-D.uttaro-idr-bgp-persistence] to Informative reference.

Regards,
Bruno

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Thu, 10 Jul 2014 13:05:08 +0000

Hi Bruno,

Thanks for the comment,

Pls find inline comments.

Thanks,

Stephane

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 10, 2014 11:49
To: idr wg
Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset

Hi all,

[SLI] Good to hear :)

6. IANA Considerations 

0x3F00: IGP interface

[SLI] This may be a good idea, I would be interested by other feedbacks also. But I would support this sort of default inherited interface groups.
	   
---------

[SLI] This was an already identified action ... will be updated in next version.

[SLI] Ack

Regards,
Bruno

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.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Jul 2014 10:22:05 -0400

Bruno,

>        Range              Registration Procedures

As Robert Raszuk had already pointed out off-list, "Why aren't we using wide
communities for this".  :-)

I had intended to let the idea for these constraints circulate a bit for
people to get comfortable with it before bringing up wide comms as the
policy mechanism for it.

-- Jeff

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 07:47:15 +0000

Hi Jeff,

As I said to Robert offline, the main issue I see with wide comm would be the introduced delay of availability of this important use case (I'm talking about multiple years ... while use case is now ...). 
Wide comm is not yet a WG doc ... encoding may still change ...

I also agree that we are quite short in bit and bytes using an extcomm but it sounds usable.

May be a two step approach can be done :
- first standardize using extcomm as for other flowspec actions (we can discuss for sure bits and bytes to optimize the encoding proposal)

Then :
- review all flowspec actions and see how we can use wide comm to enhance usability of them.

Thoughts ?

Best Regards,

Stephane

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Thursday, July 10, 2014 16:22
To: DECRAENE Bruno IMT/OLN
Cc: idr wg
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset

Bruno,

>        Range              Registration Procedures

As Robert Raszuk had already pointed out off-list, "Why aren't we using wide communities for this".  :-)

I had intended to let the idea for these constraints circulate a bit for people to get comfortable with it before bringing up wide comms as the policy mechanism for it.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Jul 2014 10:05:14 +0200

Stephane,

I am not sure why you would not be fine for now with use of regular
community for such group coloring ?

Do you really need to define new extended community which results in need
for implementations in various code bases ?

RFC 5575 already addresses this today by paragraph:

Implementations should provide mechanisms that map an arbitraryBGP
community value (normal or extended) to filtering actions that require
different mappings in different systems in the network.

- - -

As to the draft I think you really meant "AND" not "OR" :)

Multiple instances of the community in a BGP update MUST be
interpreted as a "OR" operation : if a BGP update contains two
interface-set communities with group ID 1 and group ID 2, the filter
would need to be installed on interfaces belonging to Group ID 1 or
Group ID 2.

Otherwise if you meant "OR" you need to elaborate which one out of the two.

Best,
R.

On Fri, Jul 11, 2014 at 9:47 AM, <[email-masked]> wrote:

> Hi Jeff,
>
> As I said to Robert offline, the main issue I see with wide comm would be
> the introduced delay of availability of this important use case (I'm
> talking about multiple years ... while use case is now ...).
> - first standardize using extcomm as for other flowspec actions (we can
> discuss for sure bits and bytes to optimize the encoding proposal)
>
> Then :
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 09:01:46 +0000

Hi Robert,

We need to have a way to encode the direction of the filter, so this part should be registered and standardized for interoperability purpose. Moreover we want something completely automated without having to configure policies on each node describing mapping between community values and filter parameters (direction).

Regarding “AND”/”OR”, the idea is that if NLRI has GroupID1 and GroupID2 attached. It need to be considered as a “match-any”, so it will be applied to interfaces belonging to GroupID1 and interfaces belonging to GroupID2.
For me “AND” would be more a “match all”, saying that the filter would be applied on interfaces that are belonging only to both groups at the same time.
We can rephrase in next version.

Thanks,

Stephane

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, July 11, 2014 10:05
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; DECRAENE Bruno IMT/OLN; idr wg
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset

Stephane,

I am not sure why you would not be fine for now with use of regular community for such group coloring ?

Do you really need to define new extended community which results in need for implementations in various code bases ?

Implementations should provide mechanisms that map an arbitraryBGP community value (normal or extended) to filtering actions that require different mappings in different systems in the network.

- - -

interface-set communities with group ID 1 and group ID 2, the filter would need to be installed on interfaces belonging to Group ID 1 or Group ID 2.

Best,
R.

On Fri, Jul 11, 2014 at 9:47 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jeff,

Then :

Thoughts ?

Best Regards,

Stephane

-----Original Message-----
From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jeffrey Haas
Sent: Thursday, July 10, 2014 16:22
To: DECRAENE Bruno IMT/OLN
Cc: idr wg
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset

Bruno,

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr
_________________________________________________________________________________________________________________________

[email-masked]<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Jul 2014 11:34:18 +0200

Hi,

Well ... direction can also be specified using regular communities ;)

You just need x2....

Cheers,
R.
On Jul 11, 2014 11:02 AM, <[email-masked]> wrote:

>  Hi Robert,
>
>
>
> We need to have a way to encode the direction of the filter, so this part
> should be registered and standardized for interoperability purpose.
> Moreover we want something completely automated without having to configure
> policies on each node describing mapping between community values and
> filter parameters (direction).
>
>
>
> Regarding “AND”/”OR”, the idea is that if NLRI has GroupID1 and GroupID2
> attached. It need to be considered as a “match-any”, so it will be applied
> to interfaces belonging to GroupID1 and interfaces belonging to GroupID2.
>
> For me “AND” would be more a “match all”, saying that the filter would be
> applied on interfaces that are belonging only to both groups at the same
> time.
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Friday, July 11, 2014 10:05
> *To:* LITKOWSKI Stephane SCE/IBNF
> *Cc:* Jeffrey Haas; DECRAENE Bruno IMT/OLN; idr wg
> *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset
>
>
>
> Stephane,
>
>
>