Securing  BGP  

Why  not?  

David  Freedman  –  Claranet  –  ION  Belfast  2014  

Only  two  things  to  talk  about  

•  draH-­‐ieJ-­‐opsec-­‐bgp-­‐security  (BGP  security)  •  CCRSR  /  MANRS  (The  “Manifesto”)  

Why  session  security?  

•  Internet  protocol,  using  BGP,  signals  in-­‐band.  •  BGP  in  many  cases  is  a  simple  TCP  session  between  TCP  peers  usually  you  can  reach  both  (modern  IXPs  excepted).    

•  If  I  can  disrupt  session,  I  can  cause  you  pain.  •  If  I  can  hijack  session,  I  can  cause  you  more.    

Peer   Peer  

draH-­‐ieJ-­‐opsec-­‐bgp-­‐security  •  An  internet  draH  in  the  IETF,  not  a  current  standard.  

•  Part  of  the  OPSEC  working  group,  “Opera[onal  security  capabili[es  for  IP  Network  Infrastructure”.  

•  Concerning  BGP  security.    •  Wri\en  by  vendors  and  operators,  for  the  use  of  operators.    

•  Aims  to  become  IETF  BCP  (Best  current  prac[se).  

Key  topics  covered  

BGP  Security  

Session  Protec[on  

Prefix  Filtering  

A\ribute  Filtering  

Flap  Dampening  

Control  Plane  

Overlapping  work  •  RIPE  Documents  (Rou[ng-­‐WG).  •  BCOP  Documents  (ARIN  and  now  RIPE  Region  BCOP  ini[a[ve).  

•  Industry  fora  presenta[ons  (NANOG  etc..)  •  CCRSR  /  MANRS  •  Vendor  recommenda[ons.  

  Much  consulta[on  undertaken  to  avoid  conflic[ng  informa[on.  

Control  Plane  

•  Recommenda[on  to  use  iACLs  and  CoPP.  •  Pointer  to  RFC6192  “Protec[ng  the  Router  Control  Plane”.  

•  The  above  RFC  published  in  2011  and  is  en[rely  vendor  led  (Juniper  /  Cisco).  

•  Worth  no[ng,  Lack  of  good  CoPP  used  to  be  responsible  for  many  operators  shueng  down  their  peering  ports  when  there  is  an  ‘event’  on  the  exchange.  

Session  Protec[on  

•  MD5  as  minimum,  but  considered  ‘weak’.  

•  TCP-­‐AO  (RFC5925)  and  IPSEC  preferred.  •  TTL  Security  (GTSM)  also  preferred.  •  Block  your  own  address  space  on  ingress,  don’t  leave  this  (spoofing)  vector  open.  

Prefix  Filtering  •  Filter  Bogons  

–  Special  addresses,  now  a  published  registry  for  these  •  h\p://www.iana.org/assignments/iana-­‐ipv4-­‐special-­‐registry/iana-­‐ipv4-­‐special-­‐registry.xml  •  h\p://www.iana.org/assignments/iana-­‐ipv6-­‐special-­‐registry/iana-­‐ipv6-­‐special-­‐registry.xml  

–  Not  allocated  (important  s[ll  in  IPv6  terms)  –  The  above  from  your  friendly  Bogon  feed  provider  (SpaceNet  /  Team  Cymru).  

•  Set  a  sensible  MaxPrefix  (on  peers  and  upstreams).  •  Filter  ‘too  specific’  (e.g  ge  25/49).  •  Filter  your  own  prefixes.  •  Filter  the  IXP  LAN  if  the  IXP  wants  you  to.  •  Some  addi[onal  scenarios  for  your  topology  (and  a  

discussion  about  uRPF  implica[ons).  •  Oh,  and  (for  the  future),  perhaps  do  some  SIDR  origin  

valida[on.    

Flap  Dampening  

•  Ini[ally  a  good  thing  (RIPE-­‐178,  1998).  •  Then  a  bad  thing  (RIPE-­‐378,  2006).  •  Then,  a  good  thing  again  (RFC7196,  2014).  •  Now  RIPE  community  agree  it  may  be  a  good  thing  with  some  tweaks  (RIPE-­‐580,  2013).  

•  Let’s  all  agree  it’s  a  good  thing  again,  and  follow  the  RFC  and  RIPE.  

•  Its  possible  your  vendor  will  do  the  ‘legwork’.  

A\ribute  Filtering  

•  AS_PATH  filtering  –  Careful  what  you  send  and  receive.  –  Try  not  to  accept  your  own  unless  you  know  what  you  are  doing.  

•  NEXT_HOP  filtering  – Do  you  trust  en[rely  what  your  peers  state?  –  Be  aware  of  RTBH  (Blackholing)  though.  

•  COMMUNITIES  scrubbing  (of  your  own)  – Do  you  want  peers/upstreams  to  control  your  rou[ng  policy?  

So  for  this  I-­‐D,  what  next?  

•  In  last  call  for  BCP  as  of  yesterday.  •  Open  for  ‘substan[ve’  comments:  

– On  the  OPSEC  mailing  list    •  h\ps://www.ieJ.org/mailman/lis[nfo/opsec  

– Or  directly  to  the  authors    •  draH-­‐ieJ-­‐opsec-­‐bgp-­‐security@tools.ieJ.org  

•  Expect  to  see  vendors  take  be\er  light  of  this  and  produce  more  helpful  documenta[on/defaults.  

And  now  for  CCRSR  /  MANRS  

•  Originally  “Code  of  Conduct  for  Rou[ng  Security  and  Resilience”  (CCRSR),  but  now  called  “Collec[ve  Responsibility  and  Collabora[on  for  Rou[ng  Resilience  and  Security”  (CRCRRS)!  

•  Originally  a  group  of  large  operators  got  together  and  proposed  a  ‘code’  to  follow,  to  clean  up  issues  with  poor  filtering  ,  rou[ng  and  forwarding  hygiene.    

•  Now  using  ISOC  as  a  neutral  plaJorm  (convener  and  promoter).  

MANRS  •  “Mutually  Agreed  Norms  for  Rou[ng  Security”,  our  document,  which  explains  our  objec[ves:  

• Raise awareness and encourage actions by demonstrating commitment of the growing group of supporters

• Demonstrate industry ability to address complex issues

• Clear and tangible message:

“We do at least this and expect you to do the same”

MANRS  •  Really  it  translates  into  three  ac[ons:  

1.  Prevent  propaga[on  of  incorrect  rou[ng  informa[on.    

2.  Prevent  egress  of  traffic  with  spoofed  source  IP  addresses.    

3.  Facilitate  global  opera[onal  communica[on  and  coordina[on  between  the  network  operators.  

h\p://www.rou[ngmanifesto.org  

What  next?  

•  We  had  extensive  feedback  collec[on  through  industry  mailing  lists.    

•  Now  moving  to  promote  the  material,  and  operators  to  ‘sign  up’  to  the  principles  in  the  document.  

•  Hopefully  minimal  effort  vs.  gain,  posi[ve  public  rela[ons  exercise  for  your  network  as  well.    

Ques[ons