Subject: [Idr] draft-cgray-ietf-bgp-exceptions

From: Cameron Gray <[email-masked]>
Date: Sun, 26 Jul 2015 20:43:35 +0000

My PhD work surrounds applying traditional graph theory to Internet Security.  One of the ideas so far, is the concept of Exceptions.  A routing message designed to prevent traffic matching the NLRI information from reaching the destination.  Effectively, allowing the BGP infrastructure to be used as a collaborative, distributed packet filter.  This could mean (after a successful deployment to a critical mass) the end of traditional packet based attacks by stopping them at (or as close as reasonably possible) the source.

I have submitted a personal Internet Draft for adding such a capability to BGP-4;
https://tools.ietf.org/html/draft-cgray-ietf-bgpexceptions-00
taking all that I could reasonable foresee into account.  I welcome all feedback and discussion on this draft.

There is further work to be completed (by me) for a protocol to offload calculation of the Exceptions required to a general-purpose server as Clique Detection and other graph solutions are NP-Hard.  Additionally I will create the prototype implementation, most likely using Quagga as a basis.

Thank you all for your time and consideration.

Cameron Gray
Doctoral Student
School of Computer Science

Email: [email-masked]

Bangor University, Bangor, Gwynedd, LL57 2DG, UK.

Rhif Elusen Gofrestredig 1141565 - Registered Charity No. 1141565

Gall y neges e-bost hon, ac unrhyw atodiadau a anfonwyd gyda hi, gynnwys deunydd cyfrinachol ac wedi eu bwriadu i'w defnyddio'n unig gan y sawl y cawsant eu cyfeirio ato (atynt). Os ydych wedi derbyn y neges e-bost hon trwy gamgymeriad, rhowch wybod i'r anfonwr ar unwaith a dilewch y neges. Os na fwriadwyd anfon y neges atoch chi, rhaid i chi beidio a defnyddio, cadw neu ddatgelu unrhyw wybodaeth a gynhwysir ynddi. Mae unrhyw farn neu safbwynt yn eiddo i'r sawl a'i hanfonodd yn unig ac nid yw o anghenraid yn cynrychioli barn Prifysgol Bangor. Nid yw Prifysgol Bangor yn gwarantu bod y neges e-bost hon neu unrhyw atodiadau yn rhydd rhag firysau neu 100% yn ddiogel. Oni bai fod hyn wedi ei ddatgan yn uniongyrchol yn nhestun yr e-bost, nid bwriad y neges e-bost hon yw ffurfio contract rhwymol - mae rhestr o lofnodwyr awdurdodedig ar gael o Swyddfa Cyllid Prifysgol Bangor.

This email and any attachments may contain confidential material and is solely for the use of the intended recipient(s). If you have received this email in error, please notify the sender immediately and delete this email. If you are not the intended recipient(s), you must not use, retain or disclose any information contained in this email. Any views or opinions are solely those of the sender and do not necessarily represent those of Bangor University. Bangor University does not guarantee that this email or any attachments are free from viruses or 100% secure. Unless expressly stated in the body of the text of the email, this email is not intended to form a binding contract - a list of authorised signatories is available from the Bangor University Finance Office.

---

From: "Thomas Mangin" <[email-masked]>
Date: Mon, 27 Jul 2015 08:50:39 +0100

Hello Cameron,

Small things :
> This attribute is a single 6-bit unsigned value (0-127) ..
This should read 7-bit or (0-63)

I am not sure the encoding example is clear enough / right.

Could you please also explain why this proposal is superior to the 
already widely deployed RTBH.
https://tools.ietf.org/rfc/rfc3882.txt and 
https://tools.ietf.org/html/rfc5635

I fail to grasp the advantage of your solution.

Thomas

http://exa.net.uk/about/contact-us
On 26 Jul 2015, at 21:43, Cameron Gray wrote:

> My PhD work surrounds applying traditional graph theory to Internet 
> Security.  One of the ideas so far, is the concept of Exceptions.  A 
> routing message designed to prevent traffic matching the NLRI 
> information from reaching the destination.  Effectively, allowing the 
> BGP infrastructure to be used as a collaborative, distributed packet 
> filter.  This could mean (after a successful deployment to a critical 
> mass) the end of traditional packet based attacks by stopping them at 
> (or as close as reasonably possible) the source.
>
> taking all that I could reasonable foresee into account.  I welcome 
> all feedback and discussion on this draft.
>
> There is further work to be completed (by me) for a protocol to 
> offload calculation of the Exceptions required to a general-purpose 
> server as Clique Detection and other graph solutions are NP-Hard.  
> Additionally I will create the prototype implementation, most likely 
> using Quagga as a basis.
>
> Gall y neges e-bost hon, ac unrhyw atodiadau a anfonwyd gyda hi, 
> gynnwys deunydd cyfrinachol ac wedi eu bwriadu i'w defnyddio'n unig 
> gan y sawl y cawsant eu cyfeirio ato (atynt). Os ydych wedi derbyn y 
> neges e-bost hon trwy gamgymeriad, rhowch wybod i'r anfonwr ar unwaith 
> a dilewch y neges. Os na fwriadwyd anfon y neges atoch chi, rhaid i 
> chi beidio a defnyddio, cadw neu ddatgelu unrhyw wybodaeth a gynhwysir 
> ynddi. Mae unrhyw farn neu safbwynt yn eiddo i'r sawl a'i hanfonodd yn 
> unig ac nid yw o anghenraid yn cynrychioli barn Prifysgol Bangor. Nid 
> yw Prifysgol Bangor yn gwarantu bod y neges e-bost hon neu unrhyw 
> atodiadau yn rhydd rhag firysau neu 100% yn ddiogel. Oni bai fod hyn 
> wedi ei ddatgan yn uniongyrchol yn nhestun yr e-bost, nid bwriad y 
> neges e-bost hon yw ffurfio contract rhwymol - mae rhestr o lofnodwyr 
> awdurdodedig ar gael o Swyddfa Cyllid Prifysgol Bangor.
>
> This email and any attachments may contain confidential material and 
> is solely for the use of the intended recipient(s). If you have 
> received this email in error, please notify the sender immediately and 
> delete this email. If you are not the intended recipient(s), you must 
> not use, retain or disclose any information contained in this email. 
> Any views or opinions are solely those of the sender and do not 
> necessarily represent those of Bangor University. Bangor University 
> does not guarantee that this email or any attachments are free from 
> viruses or 100% secure. Unless expressly stated in the body of the 
> text of the email, this email is not intended to form a binding 
> contract - a list of authorised signatories is available from the 
> Bangor University Finance Office.
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Cameron Gray <[email-masked]>
Date: Mon, 27 Jul 2015 08:06:14 +0000

> On 27 Jul 2015, at 08:50, Thomas Mangin <[email-masked]> wrote:
>
> Hello Cameron,
>
> Small things :

Oops, quite correct.  I will amend the typo.

> I am not sure the encoding example is clear enough / right.

Do you have any suggestion on how to make it clearer?

> Could you please also explain why this proposal is superior to the already widely deployed RTBH.
> https://tools.ietf.org/rfc/rfc3882.txt and https://tools.ietf.org/html/rfc5635
>

RTBH is (at least with my upstreams <-AS29527) hampered by prefix length limits requiring at least a wider block than intended.  It also is predicated on pseudo-well-known community tags and further upstreams/peers translating them appropriately.  I have yet to be requested to or require of my peers to add RTBH community handling which at the very least could be a leak point.

RTBH is effectively equivalent to a less formalised version of the Global Block operation mode I propose.  The AC and HT operation modes offer a more targeted solution to only block traffic at given points and reducing the need for table growth everywhere else.  Additionally my proposal has built in security requirements beyond ‘do the right thing’ noted in 3882 and 5635, requiring the use of RPKI to secure the announcements against false advertisements.

I’m more than happy to extend or amend where necessary but I can see the need for treating these as a form of overlay network rather than just another announcement.

Thank you for taking the time to consider the proposal, regards,

Cameron