NEBULA  Future  Internet  Architecture  

1  

•  E.g.,  food,  exercise,  meds  for  managing  personal  health  –  Interact  w/cloud  for  recommendaAons  &  reminders  

•  Research  ques+ons:  resilience,  adversary  models,  policies,  economics,  etc.  

“Long  tail”  of  apps  not  on  Internet…  

2  

The  BIG  quesAon:  

Given  the  conAnuing  shiM  to  cloud  services  and  modularizable  routers,  for  traffic  where  resilience  maQers:  What  architectural  solu/ons  are  needed  for  a  highly  resilient  Internet?  

3  

NEBULA  research  approach  

•  Goal  of  resilience  in  Future  Internet  to:  HW/  SW  failures,  operator  error,  malicious  behavior  by  ISPs,  end  hosts,  governments  –  If  a  path  exists,  should  find  it  and  use  it  

•  To  do  this,  we  need  progress  on  a  set  of  topics  – Each  topic  is  hard  and  has  mulAple  efforts  

•   NEBULA  is  prototyping  and  validaAng  a  set  of  architectural  ideas  

4  

Threat  Model  •  ISPs  don’t  provide  agreed  service  •  ISPs  disrupt  traffic,  ISP-­‐ISP  or  endpoint-­‐ISP  •  Compromised  routers/parts  of  routers  in  ISPs  •  Packet-­‐flooding  DoS  aQacks  from  botnets  or  compromised  ISPs,  against  endpoints,  internal  links  and  control  traffic  

•  Even  with  no  malice,  components  and  groups  of  components  can  and  will  fail  – Nebula  must  minimize  such  faults  and  if  they  occur,  quickly  idenAfy,  locate  and  recover  

5  

UlAmate  NEBULA  threat  model:    ByzanAne,  no  trust  

•  Assume  that  an  arbitrary  subset  of  the  nodes  and  networks  is  fully  controlled  by  a  ByzanAne  adversary  

6  

Alice  

important.com  

A

CB

Compromised  router  

Adversarial  network  

Future  Internet  requirements  

1.  Route  Control  2.  DoS  resilient  3.  ByzanAne  resilient  to  ISPs  &  users  4.  Highly  reliable  5.  Flexible;  upgradable  w/o  disrupAng  traffic  6.  Supports  cloud  and  ”big  data”;  consistent  with  

mobility,  sensors  7.  No  economic  or  policy  barriers  to  deployment  

7  

Subteams  versus  requirements  Requirement   Subteam  1.  Route  Control   Berkeley,  Penn,  UT  AusAn,  Stanford,  

Stevens,  Princeton  2.  DoS  Resilient   UT  AusAn,  Stanford,  Stevens,  U.  

Washington  3.  ByzanAne  resilient   Cornell,  Penn,  U.  Washington  

4.  Highly  reliable   Cornell,  U.  Del.,  Purdue,  Illinois,    Penn,  Cisco    

5.  Flexible  and  upgradable    

Princeton,  Penn,  Cornell,  Cisco  

6.  Cloud/big  data,  sensors  and  mobility  

Purdue,  Penn,  Princeton,  Stanford,  Cornell,  U.  Washington  

7.  Deployable   MIT,  Penn  8  

Resilience:  how  do  we  get  there?  

•  Routers:  new  fault-­‐tolerant  control  soMware  •  Paths:  exploiAng  path  diversity  for  resilience  •  Failures/malice:  new  ways  to  detect/resist  •  Domains:  resilient  inter-­‐domain  protocols  •  Policy  and  economics:  implicaAons  of  (and  for)  resilience  soluAons  

•  Security  and  privacy:  resilient  approaches  

9  

Algorithms  +  redundancy  =  resilience  

10  

Interconnected  Data  Centers   Router  

Reliability   MulAple  Paths  

End-­‐user  and  ApplicaAon  Control  

policy  

Policy  Enforcement  

Network  Provenance,  DetecAon  &  Debugging  

11  

•  Q1,  P1,  Q6  or  P3  fail.  Access  is  preserved  via  P1,  Q1,  P3  and  Q6  respecAvely.  

•  Q3  or  Q4’s  policy  is  incompaAble  with  Host  1  or  Host  2.  Either  Q4  or  Q3  can  be  used,  or  the  green  path  can  be  exploited  if  it  is  compliant.  

•  P2’s  reliability  is  several  orders  of  magnitude  greater  than  either  Q3  or  Q4.  Does  the  green  path  reliability  dominate  that  of  the  red  path  with  mulAple  transit  links?    

Network  

ApplicaAon  

OS  

Hypervisor  

Network  

SPY  

SPY  

SPY  

Pidgin  

Client

host  failures  network  failures  

Pidgin  –  failure  detecAon  

13  

TorIP:  Capability-­‐Based  Mailboxes  

•  Receivers  should  only  receive  packets  they  request  

•  Mailboxes  support  a  put/get  interface  

•  Data  follows  reverse  path  of  get  request  

Tier  2  ISP  

Tier  3  ISP  

Tier  1  ISPs  

NEBULA  InteracAon  with  Cisco  •  Up  to  6  FTEs  (peak)  working  on  R3/NEBULA  

–  Cisco  Ludd  interests  centered  on  resilience,  reliability  and  versioning  in  core  routers,  e.g.,  CRS-­‐1  

–  R3  /  NEBULA  split  largely  along  NDA  lines  •  AcAve  parAcipant  in  calls  and  meeAngs  

–  Admin  services,  e.g.,  Cisco  Webex  and  travel  support  –  Access  to  Cisco  proprietary  info  on  core  network  designs  (under  NDA)  

•  Sponsoring  three  research  interns  Summer  ’12  –  CompeAAvely  selected  from  pool  of  applicants  –  Will  intern  at  Cisco  HQ  in  San  Jose,  CA  

14  

Impacts:  Cisco  Ludd,  with  R3  and  NEBULA,  have  yielded  proofs-­‐of-­‐concept.  Current  planning  on  evolving  and  acceleraAng  results  into  deployable  prototypes.  

The  NEBULA  Team  Tom  Anderson  

Ken  Birman  

Robert  Broberg  

MaQhew  Caesar  

Douglas  Comer  

Chase  CoQon  

Michael  Freedman  

Andreas  Haeberlen  

Zack  Ives  

Arvind  Krishnamurthy  

William  Lehr  

Boon  Thau  Loo  

David  Mazieres  

Antonio  Nicolosi  

Jonathan  Smith  

Ion  Stoica  

Robbert  van  Renesse  

Michael  Walfish  

Hakim  Weatherspoon  

Christopher  Yoo  15  

16  

Backup  slides  aMer  here  

QuesAons,  vs.  NEBULA  work  Ins+tu+on   Resilient    

Routers  Resilient  Paths  

Failure  detect  &  debug  

Protocols   Policy  &  Econ.    

Security  &  privacy  

Berkeley   *   *  

Cornell   *   *  

Delaware   *   *  

Illinois   *   *  

MIT   *  

Penn   *   *   *   *  

Princeton   *   *  

Purdue   *   *   *  

Stevens   *   *  

Stanford   *  

UT  AusAn   *   *  

U.  Wash.   *   *   *  17  

Resilient  routers  

•  TCP-­‐R  reliable  TCP  for  fault  tolerant  BGP  •  System  SIS-­‐IS  redundant  registry  •  Replicated  applicaAon  processes  in  router  •  Key-­‐value  store  for  CRS-­‐1  •  Network  debugging  

18  

Resilient  paths  

•  Serval  exploits  available  paths  •  DeclaraAve  networking  constructs  a  rich  graph  •  Data  center  aQachment  to  router  is  path-­‐rich  •  Icing  protects  paths  •  Data  center  interconnect  is  a  path-­‐rich  graph  •  New  algorithms  and  interconnect  for  data  centers  

19  

Failure  detect  and  debug  

•  BGP  Highjack  prevenAon  •  Pidgin  System  •  Secure  Network  Provenance  •  Network  debugging  

20  

Protocols  

•  Serval  •  DeclaraAve  Networking  •  TorIP  •  SoNIC    

21  

Policy  and  Economics  

•  EvoluAon  of  ISPs  in  response  to  architecture  – E.g.,  incenAves  (or  lack  thereof)  to  use  TorIP  – Policy  compliant  ISPs  in  response  to  Icing  

•  Regulators  for,  or  against,  privacy  •  How  does  more  resilience  change  costs:  

– For  infrastructure  such  as  routers?  – For  interconnect?  – For  total  cost  of  operaAon  (TCO)?  

22  

Security  and  Privacy  

•  Icing  •  Secure  Network  Provenance  •  BGP  Highjack  PrevenAon  •  TorIP  

23  

Resilience!  

•  Router  soMware  architectures  for  resilience  •  Resilient  router  interconnecAon  schemes  •  Redundant  policy-­‐compliant  paths  thru  net  •  DetecAng  failures  via  network  provenance,  debugging  networks,  restoring  networks  

•  Reliability  over  Ame,  through  evolvable  edge,  core,  control  plane  and  policies  

24  

A  Comprehensive  Architecture    •  NEBULA  is  an  architecture  for  the  cloud-­‐based  future  Internet  –  Cloud  is  1960s  compu/ng  u/lity  –  Requires  a  new  kind  of  net  

•  Key  goals  – More  secure  and  reliable  – Deployable  and  evolvable  –  Co-­‐design  tech/economics/policy  –  Truly  clean  slate!  

IMP  

Front  and  Back,  CRS-­‐1  25  

Architecture  versus  soluAon  

•  Architecture  allows  mulAple  implementaAons  •  Have  addressed  resilience  comprehensively  •  As  few  moving  parts  as  we  can  have  •  Result:  a  resilient,  secure,  evolvable  future  internet  architecture  

26