• No results found

Independent Local Locator Substrate Indirection Transport


Academic year: 2021

Share "Independent Local Locator Substrate Indirection Transport"


Loading.... (view fulltext now)

Full text


Mälardalens  Högskola  



 Independent  Local  Locator  Substrate  Indirection  Transport    


Mats  Björkman  –  Mälardalens  University  –    mats.bjorkman@mdh.se     Javier  Ubillos  –  SICS  –    jav@sics.se    




Pablo  Santibanez  Jara  –  kaishos@gmail.com     Mikael  Svensson  –  micke.svensson@gmail.com    






Interoperation  between  IPv4  and  IPv6  on  a  global  scale  is  largely  an  unsolved  problem,  and   in  principle  a  problem  without  a  proper  solution.  The  32-­‐bit  IPv4  address  can  simply  not   express  all  possible  IPv6  hosts.    

Today,  IP  plays  a  double  role.  It  is  both  a  topological  locator  as  well  as  a  host  identity.  By   decoupling  the  two  roles  a  communication  could  also  span  over  incompatible  locator   domains  (e.g.  IPv4  and  IPv6).  The  Host  Identity  Protocol  (HIP)  [W16]  uses  this  decoupling  by   providing  two  discrete  data  structures,  one  for  the  host  identity  and  one  for  the  interfaces   locator.  

 By  extending  HIP  to  allow  differently  formatted  locators,  and  with  the  help  of  an  Identity   Router,  one  could  cross  past  differing  locator  domains  without  the  individual  hosts  needing   to  be  configured  for  any  particular  domain  other  than  their  own.    

The  goal  of  this  thesis  is  to  investigate  possible  methods  and  architectures  to  allow  this  kind   of  locator  domain  interoperability  and  to  implement  a  proof  of  concept  gateway.  

The  first  part  of  the  thesis  consists  of  the  exploration  of  the  problem  domain.  Collecting  the   requirements  of  HIP  enabled  hosts,  and  to  define  a  method  for  the  interoperability  of  two   HIP-­‐hosts  residing  in  two  differing  locator  domains  (IPv4/IPv6  will  be  assumed  for  scope   limiting  purposes).  The  output  of  this  part  will  be  a  set  of  requirements,  a  suggested  solution   and  a  rationale  for  the  chosen  solution.  The  second  part  consists  of  the  design  and  

implementation  of  the  required  components  for  the  interoperation.  At  the  time  of  writing,   the  foreseen  components  will  be:  a  parameter  to  HIP  and  a  gateway,  however,  this  is  subject   to  change  depending  on  the  output  of  part  one.  The  expected  output  of  part  two  is  a  design   specification,  an  implementation  plan  for  the  components  and  finally  the  implementation  of   the  defined  components.  


Table  of  content  

Abbreviations ...5  

Background  and  purpose ...6  

Related  work  (relevant  theory) ...6  

1.1  Host  Identity  Protocol ...6  

1.1.1  Current  IPv4,  IPv6  namespace  and  identifiers...6  

1.1.2  Base  exchange ...7  

1.2  Similar  protocols...7  

1.2.1  MobileIP ...7  Mobile  IP  base ...8  Home  agents  and  foreign  agents...8  Foreign  agent  and  home  agent  tables...9  Similarities ...9  Differences ...9  Current  use ...9   1.3.1  i3...10  i3  base...10  Mobility ...11  Similarities ...11  Differences ...11  Current  use ...11   1.4.1  Shim6...12  Shim6  base ...12  Mobility ...13  Similarities ...13   2.0  Problem  formulation ...14   2.1  Background  problem ...14   2.1.1  SICS-­‐ONE  router...14   2.2  Scope ...14  

3.0  Analysis  of  the  problem...16  

3.1  Requirements ...16  

3.1.1  Packets  and  IP  header ...16    


3.1.2  DNS,  DHT,  HOST...16   3.1.3  Parameters ...16   4.0  Model/method ...17   4.1  Gateway  concept...17   4.2  Rendezvous  server...17   4.2.1  Relay  service ...17   5.0  Solution ...19   5.1  Possible  solutions ...19   5.1.1  Relay  server ...19  Build  the  gateway...19  

6.0  Results,  analysis  of  results,  recommendations,  future  work...20  

6.1  Chosen  solution ...20  

6.2  Gateway  project ...20  

6.3.0  Results ...20  

6.3.1  Handshake  and  ESP  with  HIPL  client  and  server...20  

6.3.2  Handshake  and  ESP  with  non-­‐HIPL  client  and  server ...21  

6.3.3  ESP  and  birthday  problem ...22  

6.3.4  HIP  and  mobility  with  the  gateway ...23  

6.4  Recommendations...23  

6.4.1  Security...23  

6.4.1  Birthday  problem...24  

6.5  Future  work ...24  

6.5.1  Development  of  a  gateway...24  

6.5.2  Coding...24  

Summary  and  conclusions...25  

Summary ...25   Conclusion ...25   References...26   Appendix...27        



API   Application  Programming  Interface   DHT    Distributed  Hash  Table  

DNS   Domain  Name  System  

DoS   Denial  of  Service  

DDoS   Distributed  Denial  of  Service   ED    Endpoint  Descriptor  

FQDN    Fully  Qualified  Domain  Name   HIP    Host  Identity  Protocol   HI    Host  Identifier  

HIPL   HIP  for  Linux   HIT    Host  Identity  Tag  

IETF    Internet  Engineering  Task  Force   Initiator   Host  that  wants  to  start  a  association    

IP   Internet  Protocol  

IPv4   Internet  Protocol  version  4   IPv6    Internet  Protocol  version  6   IPSec   Internet  Protocol  security  

I3   Internet  Indirection  Infrastructure   LSI   Local  Scope  Identifier  

Responder   Host  that  responds  to  an  association  request   RR    Resource  Record  

RVS   Rendezvous  server    

SSH   Secure  Shell  

TCP   Transport  Control  Protocol   UDP   User  Datagram  Protocol  

UI   User  Interface  

WLAN   Wireless  Local  Area  Network    


Background  and  purpose    

There  is  a  lot  of  work  done  in  this  area  when  it  comes  to  implementing  and  using  gateways,   but  there  is  no  real  implementation  that  would  suit  the  new  protocol  such  as  the  host   identity  protocol.  

The  company  we  are  doing  this  thesis  for  (SICS)  have  done  a  similar  solution  with  another   company  and  that  code  is  closed  due  to  licensing  and  therefore  cannot  be  used  in  

commercial  products  such  as  a  router.  

The  goal  of  the  work  is  to  implement  a  solution  that  would  show  that  there  can  be  

implemented  open  solutions  for  commercial  use  and  in  this  specific  case  be  used  in  a  router   that  SICS  have  developed.  

Related  work  (relevant  theory)  

In  this  chapter  we  are  go  through  HIP  and  similar  protocols  to  give  the  reader  what  the   important  parts  in  mobility  and  security  that  has  to  be  kept  in  a  solution.  

1.1  Host  Identity  Protocol  

1.1.1  Current  IPv4,  IPv6  namespace  and  identifiers  

In  current  internet  with  the  use  of  IPv4  and  IPv6  the  IP  address  represent  a  route  where  the   packets  should  go,  how  to  get  to  their  destination  (routing)  and  who  the  receiver  is  

(endpoint)  as  seen  in  Figure  1.1.  This  is  used  both  in  the  network  layer  and  later  then  in  the   transport  layer,  thus  this  limits  the  mobility  of  a  connection  as  it  only  consist  as  long   everything  stays  the  same  in  every  layer  [W17].  



Figure  1.1  The  role  of  IP  

The  host  identity  protocol  (HIP)  [W16]  architecture  separates  the  end-­‐point  identifier  and   locator  from  each  other,  it  takes  the  role  as  end  point  identifier  and  uses  the  IP  address  as   locator  as  seen  in  Figure  1.2.  The  host  identities  (HI)  are  not  just  names  for  the  interface  but   it  is  also  a  public  key.    

The  HI  is  able  to  be  reached  and  used  by  several  interfaces  at  the  same  time  as  a  machine   using  HIP  can  use  several  HI’s  and  a  HI  can  be  moved  between  physical  devices  without   breaking  the  transport  association  established  with  HI  as  HIP  lies  like  a  waist  between  the   transport  layer  and  IP  addresses  as  seen  in  Figure  1.3.  As  HI  is  a  public  identifier  and  may   vary  in  length  HIP  uses  host  identity  tags  (HIT)  that  is  a  128-­‐bit  long  hash  of  a  HI  to  actual   represent  the  HI,  as  a  HIT  has  the  same  length  as  a  IPv6  address  it  can  be  used  in  the  same   address  fields  that  a  IPv6  address  can.  



Figure  1.2  The  new  HIP  namespace  

HIP  also  provides  mobility,  as  when  a  connection  is  not  bound  to  an  IP  but  a  HI  thus  the  IP   can  change  when  needed  by  a  mobile  device,  a  HIP  association  can  also  be  bound  to  several   normal  IP  addresses  if  wanted.  



Figure  1.3  HIP  as  a  waist  between  the  transport  layer  and  IP  

1.1.2  Base  exchange  

HIP  does  not  just  introduce  a  decoupling  but  also  introduces  a  four-­‐way-­‐handshake  [W16]  as   shown  in  Figure  1.4.    


Figure  1.4  HIP  handshake  

The  handshake  happens  when  a  host  (Host  A)  wants  to  connect  to  another  host  (Host  B).   The  handshake  has  the  following  procedure  simplified:  

1. Host  A  sends  an  initiator  I1  packet.  

2. Host  B  sends  a  reply  packet  R1  with  a  puzzle  that  has  to  be  solved  by  Host  A.   3. Host  A  replies  with  the  solved  puzzle  I2.  

4. Host  B  acknowledges  the  solved  puzzle  and  send  a  R2  packet.   5. An  ESP  connection  is  established  for  sending  further  data.      

 1.2  Similar  protocols  

1.2.1  MobileIP    

In  this  section  we  take  a  look  into  the  working  of  an  Internet  protocol  called  Mobile  IP   Mobile  IPv4  [W14]  Mobile  IPv6  [W15]  and  Mobile  IPv4\IPv6  [W12].  

(8)  Mobile  IP  base  

The  protocol  MobileIP  [W10]  is  similar  to  HIP,  as  it  wants  to  resolve  the  issue  with  the  end-­‐ to-­‐end  connectivity  by  having  locators  that  does  not  change  when  traversing  different   subnets  with  mobile  nodes  (MN).  

A  MN  needs  to  be  configured  to  have  a  home  agent  (HA)  that  is  sets  up  an  association  with   to  communicate  to  correspondent  nodes  (NA)  in  the  Internet  

The  protocol  doesn’t  have  HIT’s  as  HIP  have  but  instead  keeps  the  original  IP  given  by  its  HA   as  shown  in  Figure  1.5  when  visiting  other  subnets,  when  visiting  other  subnets  it  connects   to  CN  and  HA  through  a  foreign  agent  (FA).  


Figure  1.5  A  mobile  node  moving  from  one     subnet  to  another  Home  agents  and  foreign  agents  

The  use  of  the  FA  and  HA  can  be  compared  to  HIP’s  use  of  RVS  where  MN’s  can  keep   connection  with  a  correspondent  node  (CN)  without  tearing  down  existing  links  between   them  when  changing  subnets.    

It  has  as  HIP  a  special  way  to  update  its  change  of  subnet  so  CN  always  can  reach  the  MN.   In  the  case  of  Mobile  IP  a  MN  needs  to  always  communicate  with  a  CN  through  its  HA,  this   means  if  a  MN  changes  to  another  subnet  with  a  FA  it  still  goes  through  the  HA  when   communicating  with  a  CN.  This  can  introduce  to  much  delay  and  links  can  go  down  just   because  a  node  did  not  get  packets  within  some  timeslot.  Therefore  there  is  a  route  

optimization  extension  for  Mobile  IPv4  to  introduce  triangular  routing  between  the  MN  and   CN,  this  means  that  instead  of  going  through  the  HA  a  MN  can  communicate  with  a  CN   through  the  FA  instead  as  shown  in  Figure  1.6.  

In  Mobile  IPv6  a  MN  can  establish  direct  association  with  a  CN  instead  of  using  a  FA,  when  a   MN  is  in  the  its  home  subnet  it  works  similar  as  if  it  were  using  Mobile  IPv4  and  all  

communications  is  directed  through  its  HA.  


Figure  1.6  A  mobile  node  talking  with  a     correspondent  node  through  a    

foreign  agent  (Mobile  IPv4)  

(9)  Foreign  agent  and  home  agent  tables    

HA  and  FA  needs  to  keep  track  of  who  is  a  node  belonging  to  the  subnet  using  a  mobility   binding  see  Figure  1.7  and  visiting  nodes  in  a  visitor  list  see  Figure  1.8.  Both  lists  are  so  that   packets  are  forward  accordingly  to  the  MN’s  [W11].  

Each  MN  has  a  care-­‐of  address  that  can  been  seen  as  a  routing  address,  in  its  home  subnet   the  care-­‐of  address  the  MN’s  IP  when  being  in  a  FA  the  MN  updates  it  care-­‐of  address  in  the   HA  and  replaces  it  with  the  FA’s  address.  This  happens  while  the  FA  puts  the  MN’s  HA  and   the  care-­‐of  address  of  the  MN  in  its  visitor  list.  

Mobile  IP  uses  IPSec  and  the  ESP  to  further  send  the  data  between  the  connected  nodes  as   HIP.    

Mobile  IP  has  the  problem  that  with  IPv4  and  IPv6  it  needs  two  protocols  defined  Mobile   IPv4  and  Mobile  IPv6  to  be  able  to  take  care  of  IPv4  or  IPv6  packets,  there  is  a  suggestion  to   merge  Mobile  IPv4  and  IPv6  to  a  single  protocol  but  this  is  out  of  the  scope  of  this  



           Figure  1.7  Mobility  binding  in  home  agent              Figure  1.8  Visitor  list  in  a  foreign  agent  Similarities  

• The  Mobile  IP  protocol  implements  the  following  things  that  are  similar  to  each   other;  

• Both  have  a  locator  that  doesn’t  need  to  change  when  (passing  through)/(switching)   different  subnets.  

• Both  use  nonce’s  to  protect  itself  from  reply  attacks,  in  the  case  of  Mobile  IP  the   nonce  is  done  when  doing  registration  requests  on  HA  and  FAs  and  in  the  case  of  HIP   the  nonce  also  called  R1  generation  counter  is  used  to  protect  when  handshaking,   there  is  also  a  nonce  when  doing  UPDATE:  

• After  a  communication  has  been  established  both  uses  IPSec  ESP  for  further   communication.  

• The  HIP  RVS  can  be  seen  as  a  HA  or  FA  in  Mobile  IP  against  CN.  Differences  

• One  of  the  main  differences  is  the  initial  handshake,  there  is  no  defined  handshake   for  Mobile  IP  but  we  guess  that  a  state  is  created  as  in  normal  TCP/IP  handshake;   there  is  a  paper  on  the  subject  on  introducing  the  HIP  handshake  for  Mobile  IP   [SJYWJ].  

• While  a  MN  requires  that  it  registers  to  a  HA  or  a  FA  the  HIP  node  can  skip  the  RVS   association  if  the  MN  knows  where  to  connect  to.  Current  use  

The  biggest  use  of  Mobile  IP  right  now  is  incorporated  with  Voice  over  Internet  Protocol   (VoIP)  thou  VoIP  may  use  other  technologies  than  Mobile  IP.  

Usually  the  way  of  use  requires  signing  up  to  a  service  and  then  users  have  to  connect  to  the   Internet  with  their  mobile  phones  or  computers  using  WLAN/Wi-­‐Fi.  


1.3.1  i3  

I3  [W9]  is  deployed  using  indirection  to  get  around  the  problem  with  end-­‐to-­‐end  mobility.  I3   is  a  simple  but  powerful  technique  that  assumes  physical  or  logical  indirection  point  

interposed  between  sender  and  receiver  that  relay  traffic  between  them  instead  of  sending   a  packet  directly  to  its  final  destination.  The  packets  are  associated  with  an  identifier  that  is   utilized  by  the  remote  host  to  receive  the  packet.  i3  base  

Internet  Indirection  Infrastructure  (i3)  implements  a  rendezvous-­‐based  abstraction.  I3  is  an   overlay  network  that  uses  Chord  [W2]  protocol  to  route  data.  The  i3  network  is  a  set  of   servers  that  store  triggers  and  forward  packets  between  end-­‐points.  The  address  of  an  end-­‐ point  consists  of  an  IP  address  and  a  port  number.  Packet  and  trigger  identifiers  are  

represented  by  strings  of  'n'  bits.  Triggers  are  comparable  to  routing  entries.  However  there   are  a  few  differences,  routing  entries  on  the  Internet  are  updated  and  maintained  by  special   routing  protocols,  triggers  are  openly  maintained  by  end  hosts.  This  gives  end-­‐hosts  more   flexibility  and  control  in  choosing  the  identifiers  and  the  “paths”  where  they  want  their   packets  to  propagate.  Assumptions  are  made  that  each  end-­‐host  knows  a  list  of  servers,   which  is  obtained  via  a  bootstrapping  mechanism  when  the  end-­‐host  joins  the  i3  network.   When  a  packet  is  sent  by  an  end-­‐host  it  is  handed  to  an  i3  server.    When  the  i3  server  

receives  a  packet  it  will  search  for  the  trigger  matching  the  packet.  Triggers  that  are  matched   in  this  way  tell  the  server  to  forward  the  packet  to  the  end-­‐point  with  the  matching  trigger   and  the  correct  address  as  seen  in  Figure  1.9.  


Figure  1.9  Shown  here  in,  the  I3  network  inserts  a  trigger  (id,R)  to  obtain  all  the  packets  that  associates  with  id.  

I3  will  not  store  packets  in  any  way,  it  only  forwards  them.  I3  is  more  of  a  best-­‐effort   implementation  service.  I3  includes  neither  reliability  nor  ordered  delivery  on  top  of  the  IP   protocol.  To  keep  the  trigger  tables  up  to  date  periodic  updates  are  made  by  the  end-­‐hosts.   When  an  end-­‐host  fails  its  triggers  are  automatically  deleted  from  the  i3  servers.  However  if   there  is  a  failure  on  the  i3  server  side  and  triggers  are  lost  they  will  be  reinserted  next  time   the  end-­‐host  refreshes  it.  To  find  triggers  matching  a  given  packet  i3  use  a  lookup  service   that  maps  an  identifier  space  to  a  set  of  servers.  If  you  are  given  an  id  the  lookup  service  will   find  the  server  that  is  responsible  for  that  id  and  from  that  point  able  to  localize  the  end-­‐ host.  The  format  of  a  trigger  that  is  stored  on  a  responsible  server  is  (id,  addr)  and  this   makes  it  really  easy  to  match  an  id.  A  packet  consists  of  (id,  data)  and  will  be  forwarded    


based  on  its  id  on  the  overlay  network  to  the  same  responsible  server  then  to  be  matched  to   the  trigger  and  forwarded  to  addr  via  IP.  Mobility  

The  form  of  mobility  addressed  here  is  when  a  host  (e.g.,  a  laptop)  is  assigned  a  new  address   when  it  moves  from  one  location  to  another.  A  mobile  host  that  changes  its  address  from  R1   to  R2  as  a  result  of  moving  from  one  subnet  to  another  can  maintain  the  end-­‐to-­‐end  

connectivity  by  simply  updating  each  of  its  existing  triggers  from  (id,  R1)  to  (id,  R2).  The   sending  host  does  not  need  to  know  of  the  mobile  host’s  current  location  or  address.   Furthermore,  since  each  packet  is  routed  based  on  its  identifier  to  the  server  that  stores  its   trigger,  no  additional  operation  needs  to  be  done  when  the  sender  moves.  Thus,  i3  can   preserve  end-­‐to-­‐end  connectivity  even  when  both  end-­‐points  move  simultaneously  as  seen   in  Figure  1.10.  



Figure  1.10  When  the  host  moves  around  and  changes  its  address  from  R1  to  R2,  the  trigger  is  updated   from  (id,  R1)  to  (id,  R2).

When  the  host  moves  around  and  changes  its  address  from  R1  to  R2,  the  trigger  is  updated   from  (id,  R1)  to  (id,  R2).  Similarities  

• Triggers  can  be  compared  with  HIT’s  as  it  is  a  form  of  keeping  track  on  end-­‐hosts.   • Both  have  a  locator  that  doesn’t  need  to  change  when  (passing  through)/(switching)  

different  subnets.   • Both  offer  mobility.  

• The  HIP  RVS  can  be  seen  as  an  i3  server.  Differences  

• One  of  the  main  differences  is  the  initial  handshake,  as  there  is  none  for  the  i3.   • The  fact  that  i3  gives  it’s  end-­‐hosts  full  control  on  routing  it  opens  up  for  DDoS  

attacks.  A  malicious  user  can  insert  a  new  hierarchy  of  triggers  where  all  the  triggers   point  to  the  selected  victim.  

• No  encryption  is  used.    

• Since  i3  allows  end-­‐hosts  to  just  refresh  the  trigger  list  themselves  they  can  just  add   new  triggers  and  join  the  network.  There  is  no  strict  registration  needed.  Current  use  

Areas  of  use  including  i3  are  proxies;  secure  intranets  and  NAT  where  the  routing  flexibilities   of  i3  can  be  used.  Some  applications  may  require  third  parties  to  process  the  data  before  it    


reaches  the  destination.  An  example  is  a  wireless  application  protocol  (WAP)  gateway   translating  HTML  web  pages  to  WML  for  wireless  devices.  WML  is  a  lightweight  version  of   HTML  designed  to  run  on  wireless  devices  with  small  screens  and  limited  capabilities.  In  this   case,  the  server  can  forward  the  web  page  to  a  third-­‐party  server  that  implements  the   HTML-­‐WML  transcoding,  which  in  turn  processes  the  data  and  sends  it  to  the  destination  via   WAP.  

In  general,  data  might  need  to  be  transformed  by  a  series  of  third-­‐party  servers  before  it   reaches  the  destination  [W6].  In  today’s  Internet,  the  application  needs  to  know  the  set  of   servers  that  perform  transcoding  and  then  explicitly  forward  data  packets  via  these  servers.   With  i3,  this  functionality  can  be  easily  implemented  by  using  a  stack  of  identifiers.  


1.4.1  Shim6  

This  protocol  specifies  a  layer  3  shim  approach  [W22]  and  a  protocol  of  its  own  to  provide   locator  quickness  under  the  transport  protocol.  It  gives  some  extra  features  such  as  IPv6   failover,  multihoming  and  load  balancing  properties.  Failover  using  different  locator  pairs  are   very  beneficial  if  the  original  one  should  stop  working.  


Figure  1.11  The  shim6  architecture,  picture  taken  from  www.shim6.org  


Shim6  protocol  stack  uses  static  endpoint  identities.  It  refers  both  to  itself  and  a  remote   protocol  stack.  The  shim  layer  offers  a  set  of  associations  between  endpoint  id  pairs  and   locator  sets  as  seen  in  Figure  1.11.  Shim6  base  

When  packets  are  passed  from  the  IP  endpoint  sub-­‐layer  to  the  IP  routing  sub-­‐layer  an   association  is  made  to  a  current  pair  of  locators.  When  receiving  packets  a  reverse  mapping   is  made  on  the  packet  to  remove  the  locator  pair  then  to  associated  endpoint  identity  pair   with  the  packet,  which  is  then  passed  to  the  IP  endpoint  sub-­‐layer.    

The  shim6  approach  is  that  the  endpoint  id  and  the  locators  are  both  IP  addresses.  When   communicating,  the  endpoint  id  is  the  primary  address  to  be  used  between  two  hosts.  The   locators  used  are  just  a  set  of  IP  addresses  that  are  being  associated  with  the  endpoint  in   order  to  keep  track.  This  method  increases  the  efficiency  regarding  changing  dynamic   locators  in  the  protocol  stack.  This  makes  it  easy  for  a  host  to  initiate  a  session  by  using  a    


regular  DNS  [W3]  lookup  on  the  remote  hosts  hostname  using  one  of  its  addresses  as  the   destination  address.    

Packets  can  continue  to  be  exchanged  with  the  remote  host  during  the  session  by  simply   continue  to  use  the  same  destination  address.  If  the  local  host  later  on  starts  a  new  session   with  the  same  remote  host  the  same  destination  address  can  be  used.  The  functionality   offered  with  shim6  changes  nothing  to  the  use  of  addresses  or  endpoint  identifiers  in  the   regular  IPv6  architecture.  Shim6  does  not  initiate  a  new  identifier  name  space;  instead  it   uses  the  locator  that  is  selected  in  the  initial  contact  with  a  new  remote  peer.  It  preserves   upper-­‐layer  identifier  (ULID).  The  upper-­‐level  protocol  will  continue  to  use  upper-­‐level   identifiers  even  though  there  could  be  failures  to  the  network-­‐level  locators.  Thus   eliminating  excessive  faults  that  may  occur.  Mobility  

The  protocol  stack  uses  endpoint  ids  to  refer  the  local  and  remote  protocol  stack  and   therefore  the  shim  layer  can  provide  a  set  of  associations  between  the  endpoint  identity   pairs  and  locator  sets  in  order  to  keep  track.  Similarities  

The  similarities  with  HIPL  protocol  are  that  it  uses  a  set  of  identifiers  to  refer  to  locator  pairs   to  keep  track  on  end-­‐points.  Uses  locators  that  get  updated.  

It  offers  mobility.  



2.0  Problem  formulation  

2.1  Background  problem  

Due  to  the  extensive  use  of  old  equipment  and  systems  that  relies  on  ipv4  fundamentals  the   legacy  network  and  the  new  network  needs  a  bridge  to  be  done  to  reduce  the  impact  of   costs  and  work  needed  to  upgrade  to  new  equipment  and  systems.  

The  bridge  would  provide  interoperability  between  the  legacy  systems  and  new  ones  thus   providing  a  platform  that  would  not  disturb  the  current  dynamics  of  the  Internet.  

This  bridge  does  exist  for  the  current  normal  IPv4  and  IPv6  protocols  but  as  we  are  working   with  HIP  a  bridge  that  supports  HIP  doesn’t  exist  as  of  yet.  


2.1.1  SICS-­ONE  router  

The  general  idea  was  to  add  this  functionality  to  the  SICS-­‐ONE  router  developed  at  SICS.   SICS-­‐ONE  router  aims  towards  how  to  overcome  the  obstacle  of  different  address  schemes   between  the  IPv4  and  the  IPv6  domains  using  a  set  of  gateway  servers.  The  gateway  servers   provide  the  necessary  abstraction  of  network  addresses  by  routing  the  traffic  between  the   communicating  nodes  using  a  routing  hint  (HINT)  [UA].  The  gateways  are  reached  using   anycast  and  DNS,  also  providing  redundancy.  Gateway  addresses  and  routing  hints  are   provided  by  DNS  together  with  the  host  identity.  The  solution  builds  on  the  ideas  provided   by  the  Node  Identity  architecture.  

Interoperation  between  the  two  namespaces  IPv4  and  IPv6  is  largely  an  unsolved  problem   seen  on  a  global  scale  perspective.  Since  IPv4  consist  only  of  32  bits  it  is  not  possible  to   express  all  the  available  IPv6  hosts.  A  global  migration  to  IPv6  would  seem  unrealistic  due  to   legacy  hardware  and  software  not  to  mention  all  the  excessive  work  needed.  

To  solve  this  problem  with  'ease'  the  SICS-­‐ONE  router  with  this  extra  functionality  would  be   most  beneficial.  

2.2  Scope  

Our  task  is  to  implement  a  gateway  (GW)  [W5]  that  will  act  as  a  bridge  needed  for  

interoperability  between  a  HIP  host  in  an  IPv4  only  network  and  a  HIP  host  in  an  IPv6  only   network.  

This  is  going  to  be  implemented  into  a  router  that  is  developed  in  SICS.  

The  test  scenario  will  be  that  we  will  have  two  hosts,  A  and  B,  A  wants  to  send  something  to   B  using  HIP,  but  A  is  in  an  IPv4  network  only  and  B  is  in  an  IPv6  network  only,  but  it  can  go   the  other  way  around  as  well.  

Host  A  does  not  know  the  more  about  B  than  its  hostname  lets  says  piff.com.  

Host  A  needs  to  ask  a  DNS  about  the  HIT  or  IP  address  of  B,  the  DNS  does  a  lookup  and  sees   that  B  is  in  a  different  network  than  A.  When  the  DNS  return  the  query  it  needs  to  return  the   address  of  a  gateway  and  the  address  of  B  (B’s  address  is  what  we  would  call  a  HINT)  and  the   additional  HIP  information  like  HIT.  

The  name  lookup  sees  that  there  is  an  additional  address  returned  it  puts  the  address  as  a   HINT,  the  HINT  is  then  added  to  the  HIP  packets  as  a  parameter  called  RR_HINT.  

The  packet  is  sent  to  the  gateway  in  the  following  way:   • IP  header  FROM  field  is  A’s  address.  

• IP  header  TO  field  is  the  GW  address.    


• HIP  parameter  RR_HINT  contains  B’s  address    

The  gateway  gets  the  packets  reads  it  and  sees  that  the  parameter  RR_HINT  is  included  thus   it  does  the  following  changes:  

• IP  header  FROM  field  is  changed  to  the  GW  address.   • IP  header  TO  field  is  B’s  address.  

• HIP  parameter  RR_HINT  contains  A’s  address.  

Then  sends  the  packet  to  B  using  the  correct  protocol  (in  this  example  IPv6)  that  is  required   to  send  it  from  the  GW  to  B.  

B  then  processes  it  as  an  ordinary  packet  with  the  exception  it  always  append  the  RR_HINT   parameter  that  it  has  received  in  from  the  gateway.  Then  B  sends  all  the  replays  to  A   through  the  GW,  see  Figure  2.1  for  info  how  the  packets  are  sent.  


Figure  2.1  How  the  communication  between  a  Host  A,  the  DNS,  the  GW  and  Host  B  goes.  


After  the  HIP  handshake  has  taken  place  an  ESP  association  should  be  saved  in  the  gateway   so  the  ESP  traffic  between  the  hosts  are  routed  through  the  gateway  i.e.  that  the  gateway   will  now  work  like  a  SPI-­‐NAT,  meaning  it  matches  the  SPI  that  is  used  to  identify  ESP  packets   and  are  routed  to  a  specific  host.  


3.0  Analysis  of  the  problem  

3.1  Requirements  

3.1.1  Packets  and  IP  header  

The  packets  must  use  HIP,  we  have  to  be  able  to  modify  the  packets  sent  between  two  hosts   in  the  GW  so  they  get  the  right  TO  and  FROM  fields  in  the  IP  headers  as  seen  in  Figure  3.1.  


Figure  3.1  How  the  to  headers  have  in  their  fields,  1,  2  are  packets  going  to  host  B  and  3,  4  are  packets  going  to  

host  A.  


3.1.2  DNS,  DHT,  HOST  

When  a  host  makes  a  query  for  a  specific  address  it  should  get  back  the  address  of  the   gateway  and  the  address  of  the  host  it  is  trying  to  reach  as  seen  in  Figure  3.2.  


Figure  3.2  Query  about  B  and  an  answer  to  with  IP  to  the  gateway  and  IP  of  B  as  a  HINT   3.1.3  Parameters  

The  packets  have  to  carry  information  where  it  is  headed,  where  it  is  from  and  the  address   to  the  gateway,  as  the  HINT  information  cannot  be  put  in  an  ordinary  IPv4  or  IPv6  header  we   have  to  add  this  information  to  the  HIP  section  of  the  packet  as  a  parameter  see  Figure  3.3.   This  parameter  is  later  processed  by  the  gateway.    


Figure  3.3  How  the  HIP  parameter  can  be  in  the  HIP  packet.  


4.0  Model/method  

There  are  several  methods  to  solve  this  kind  problem  between  two  networks  running   different  protocols  and  one  of  them  is  to  have  some  kind  of  bridge  that  translates  from  one   protocol  to  another.  

We  call  this  method  for  a  gateway  that  has  as  purpose  to  translate  from  one  specific   protocol  to  another.  

There  is  also  a  possible  solution  that  is  introduced  with  HIP,  using  a  rendezvous  server  (RVS)   [W20]  to  forward  packets  as  a  gateway  between  two  HIP  enabled  hosts.  RVS  as  it  is  now  only   handles  the  handshake;  a  third  solution  would  be  using  a  relay  server  that  is  an  experimental   relay  developed  by  a  group  of  people.    


4.1  Gateway  concept


Gateways  also  called  protocol  converters  are  a  software  and/or  hardware  implementation   made  to  interconnect  different  nodes  or  networks  using  different  protocols.  Usually  it  must   convert  one  stack  into  another  regarding  the  different  use  of  protocols.  It  allows  us  to  set  up   a  bridge  and  communicate  with  IPv4  and  IPv6  over  HIP.  The  different  devices  included  in  the   gateway  may  vary  from  protocol/fault/signal  translators,  impedance  matching  and  rate   converters.  

4.2  Rendezvous  server  

The  Host  Identity  Protocol  (HIP)  Architecture  has  introduced  a  rendezvous  mechanism  to   allow  contact  from  a  HIP  node  and  a  moving  mobile  HIP  node  or  a  HIP  node  that  wants  other   means  to  be  contacted  as.  This  mechanism  includes  a  third  party  service,  the  RVS  server  to   allow  this  transition.  

A  RVS  Server  allows  a  HIP  client  to  connect  to  the  RVS  IP  and  from  there  match  a  HIT  of  the   final  destination  where  the  information  will  be  later  sent.  This  allows  multihoming  and   increased  mobility  when  HIP  nodes  notify  their  peers  when  changes  occur  in  the  set  of  IP   addresses  used.  

This  covers  the  initial  part  of  a  base  exchange  but  as  seen  in  the  picture  the  rest  of  the   communication  is  set  between  the  hosts  thus  if  the  hosts  are  in  different  network  types  it   won’t  work  see  Figure  4.1.  

  Figure  4.1  The  use  of  a  RVS  server.  

4.2.1  Relay  service  

The  relay  service  is  a  mechanic  to  address  the  issues  that  are  brought  up  in  RFC  5203  [W19]   and  RFC  5207  [W21]  where  HIP  enabled  hosts  are  behind  NAT  but  can  be  used  as  well  for   hosts  that  are  in  different  networks  for  solving  mapping  issues.  

The  Relay  can  be  used  in  a  RVS  or  implemented  as  a  standalone  service,  implementing  the    


relay  functionality  will  make  the  RVS  a  relay  [W7]  i.e.  a  gateway  for  HIP  hosts  to  use  see   Figure  4.2.    

One  difference  to  a  gateway  is  that  in  a  RVS  or  Relay  the  responder  has  to  register  itself  with   the  relay  server,  as  it  has  to  do  with  a  RVS.    


Figure  4.2  Relay  service  

Thus,  the  following  steps  have  to  be  done:  

1. Responder  (B)  has  to  register  itself  with  the  RVS.   2. Initiator  (A)  query’s  the  DNS  for  B’s  information.  

3. DNS  sends  back  the  IP  of  the  relay  but  uses  the  HIT  of  B  in  the  packet.  

4. The  initiator  connects  to  RVS  with  the  provided  IP  and  uses  the  HIT  of  B  in  the   packet  sent.  

5. The  relay  maps  the  packet  from  the  initiator  using  the  HIT  of  B  and  sends  the   packets  to  B.  

6. Packets  from  the  responder  are  relayed  through  to  A  through  the  RVS.  

The  main  step  that  has  to  be  avoided  in  the  solution  we  have  to  provide  is  step  1  in  the   above  section,  i.e.  that  there  is  no  association  in  the  gateway  until  an  initiator  tries  to  a   connection  to  a  responder  through  the  gateway,  this  is  discussed  in  the  next  chapter.  


We  can  show  one  setup  example  here  using  the  HIPL  projects  RVS  and  Relay  service.   • Start  HIPD  in  all  the  host  that  will  act  as  a  relay  

• In  host  that  will  act  as  a  relay  issue  command:  hipconf  add  service  relay   • At  the  host  acting  as  a  responder  type:  hipconf  add  server  relay  <RELAY-­‐HIT>  


You  will  have  to  do  additional  configuration  right  now  for  it  to  work  with  the  HIPL   implementation.    



5.0  Solution  

5.1  Possible  solutions  

Two  possible  solutions  were  discussed  with  the  supervisor,  one  is  to  make  use  of  the  relay   server  as  it  is  already  implemented  and  another  is  to  build  the  gateway  using  the  HIPL  [W8]   group’s  code  as  base.  

Compared  with  OpenHIP  [W13]  that  is  an  alternative  solution  there  was  just  not  that  much   activity  on  their  development  team  as  HIPL  when  choosing  the  Base  to  build  our  project  on.  

5.1.1  Relay  server  

The  first  solution  were  the  use  of  a  relay  server  is  used  has  the  advantages  that  there  is  no   requirement  to  implement  anything,  it  would  work  with  existing  implementations  of  DHT   and  DNS  services  and  no  more  mapping  between  hosts  would  be  needed.  

The  disadvantage  of  this  is  that  there  has  to  be  a  specific  relay  server  to  connect  to,  as  the   host  who  wants  to  initiate  the  connection  has  to  connect  to  a  relay  server  that  has  the   wanted  host  registered  to  it.  Thus,  the  connecting  host  cannot  just  initiate  a  connection  to   an  arbitrary  client;  it  has  to  know  the  relay  server  in  advance  that  has  the  specific  client  who   is  registered  on  that  server.  Build  the  gateway  

The  second  solution  to  build  a  gateway  with  the  HIPL-­‐projects  code  as  base  would  take  more   time,  but  as  time  is  no  concern  as  there  is  enough  time  allocated  for  this  thesis  this  solution   is  feasible  within  the  time  constraints.  This  would  do  as  long  the  requirements  being  set  by   the  supervisor  are  hold  between  realistic  boundaries  that  can  be  completed  by  the  time  this   thesis.  

The  disadvantage  with  this  method  is  that  as  the  HIPL  code  is  in  current  development,  thus   using  the  code  from  HIPL  as  base  there  is  the  need  to  choose  a  release  from  the  HIPL  group   that  is  stable  enough  to  use.  This  is  to  make  the  solutions  developed  under  the  time  the   thesis  progresses  not  to  be  broken  as  new  releases  of  the  HIPL  are  released.  As  the  HIPL   code  is  going  to  change  in  the  time  we  are  doing  this  thesis,  the  solutions  we  implement  are   not  going  to  have  any  support  outside  this  thesis  work.  

This  requires  also  the  use  of  a  HINT  parameter  that  has  to  be  implemented  from  an  already   defined  definition  [UA].  SPI-­NAT  

As  a  association  for  the  traffic  after  the  handshake  should  be  established  there  has  to  be   some  database  in  the  gateway  that  saves  and  can  be  used  to  map  between  the  SPI  [W18]   and  addresses  from  each  host  so  that  ESP  packets  are  routed  correctly.  


6.0  Results,  analysis  of  results,  recommendations,  future  work  

6.1  Chosen  solution  

We  picked  Linux  due  to  it  is  a  widely  used  technology  with  extensive  documentation  and   support.  

The  preferred  solution  was  to  implement  our  own  gateway  with  the  HIPL  code  version  1.0.4   release  42  that  was  released  in  June  2009  as  base.  Using  the  HIPL  code  as  base  was  selected   so  that  if  the  results  of  this  thesis  are  to  be  continued  by  the  HIPL  team  there  is  known  code   that  they  can  work  with.  

6.2  Gateway  project  

By  following  the  steps  mentioned  in  the  attachment  1  [Installing-­‐hipl.doc]  we  created  our   own  folder  called  gateway  in  the  HIPL  HIP  source  file  packet.  All  the  perquisites  needed  and   working  operating  system  we  have  choose  is  explained  in  the  attachment  1.  

We  have  all  the  needed  code  in  the  folder  [source  files]/gateway.  

How  the  computers  used  were  setup  is  explained  in  the  attachment  2  [System-­‐setup.doc].  

6.3.0  Results  

6.3.1  Handshake  and  ESP  with  HIPL  client  and  server  

The  result  of  the  thesis  work  and  working  with  the  gateway  code  can  be  seen  in  the   following  see  Figure  6.1  that  is  a  cropped  screenshot  from  a  Wireshark  capture  on  the  host   that  is  running  the  gateway.  


Figure  6.1  Wireshark  capture  

This  shows  as  the  system  setup  document  shows  the  attachment  2  [System-­‐setup.doc]  that   the  handshake  is  done  through  the  gateway  and  then  a  ESP  association  continues  between   host  A  (Initiator)  and  host  B  (Responder)  through  the  gateway.  

Figure  6.2  and  Figure  6.3  show  the  Initiator  and  Responder  after  a  successful  send  and   receive  of  the  packet.  



Figure  6.2  The  client  sending  a  message  hai  


Figure  6.3  The  server  receiving  the  message  ‘hai’  and  replying  

Due  to  the  lag  between  Host  A  the  gateway  and  then  Host  B  there  will  be  a  lot  of  resends  of   packets  in  the  handshake  as  it  seem  that  the  HIP  daemon  requires  a  reply  in  a  short  period   of  time.  

This  we  just  encounter  with  the  HIP  handshake,  the  ESP  traffic  seems  to  be  more  tolerate   when  it  comes  to  how  it  waits  for  a  reply  before  a  resend.  

6.3.2  Handshake  and  ESP  with  non-­HIPL  client  and  server  

We  tried  doing  some  ping61  test  between  an  Initiator  and  Responder  and  could  not  establish  

an  association  because  somewhere  in  the  program  of  ping6  it  did  not  accept  the  address   given  to  it  by  the  HIPL  tool  used.  It  seems  the  address  resolve  was  stuck  in  a  loop  that  it   could  not  get  out  off,  thus  the  handshake  did  not  work  so  the  test  failed.  

We  tested  this  with  an  already  established  association  between  the  Initiator  and  Responder   i.e.  that  a  handshake  had  taken  place,  when  we  then  tried  ping6  the  test  was  successful  as   no  handshake  needed  to  be  done  and  the  traffic  was  encrypted  with  ESP  between  the  hosts.  


1  ping6  is  a  program  to  perform  ping  test  using  the  IPv6  protocol  between  hosts.  


Due  to  time  constraints,  we  could  not  fix  this  and  all  the  debugging  with  different  tools  were   not  possible  because  the  debugging  tools  crashed  when  trying  to  check  for  errors  in  the   program,  as  the  debugging  tools  worked  without  a  problem  with  the  other  parts  of  the  code   we  could  not  investigate  this  problem  further  as  the  time  ran  out.  

6.3.3  ESP  and  birthday  problem    

As  we  have  done  the  database  of  the  gateway  in  such  way  that  there  is  a  unique  SPI  for  all   the  associations  between  different  hosts  we  will  encounter  something  that  is  called  the   birthday  problem/paradox  [W1].  

In  large  networks,  SPI  collisions  are  quite  probable,  compared  to  collision  in  large  end-­‐point   identifier  namespaces.  Therefore,  we  strongly  suggest  a  limited  amount  of  users/sessions   per  router.  Allowing  the  ISP  to  segment  their  networks  and  distribute  these  gateway  routers   strategically  to  avoid  collision  rates  above  1%.  

We  have  used  MATLAB  to  calculate  the  risk  of  collision  for  100,  1000,  10000,  25000,  50000   and  100000  concurrent  sessions,  the  result  and  100  and  1000  were  eliminated  due  to  the   results  of  the  calculations  were  0%  collision  risk.  The  remaining  results  are  presented  below   in  Figure  6.4  (10000  sessions),  Figure  6.5  (25000  sessions),  Figure  6.6  (50000  sessions)  and   Figure  6.7  (100000  sessions)  using  the  code  shown  in  attachment  3.  

Our  estimation  is  that  each  user  has  100  concurrent  sessions.  Calculating  the  collision  rate  in   a  32-­‐bit  environment,  our  results  show  us  that  10000  concurrent  sessions  will  have  roughly   1%  collision  rate.  From  our  previous  assumptions  that  each  user  has  100  sessions  this  gives   us  the  total  amount  of  users  per  router  limited  to  100.  To  build  a  reliable  and  smooth   network  topology  these  routers  need  to  be  deployed  at  each  apartment  block/building.  This   is  our  own  guess,  as  we  have  not  found  any  real  data  about  this.  

Searching  for  this  kind  of  data  was  not  in  the  scope  of  this  project.  We  found  our  results   reasonable  and  satisfying  reading  about  LSI/SPI  finding  out  the  fault  limitations.  




6.3.4  HIP  and  mobility  with  the  gateway    

The  gateway  cannot  verify  any  packet  it  receives  from  a  sender,  there  would  be  a  security   risk  to  just  change  association  i.e.  drop  the  current  association  and  establish  a  new  one   between  the  hosts.  

HIP  has  some  security  parameters  to  verify  packets  it  that  are  sent  by  having  signatures  and   HMAC  as  parameter  whose  calculation  are  based  on  the  HIP-­‐header  and  parameters,  this   means  that  there  is  no  problem  in  changing  the  IP-­‐header  and  route  an  update  packet  as   normal  in  the  gateway.  

The  behavior  of  our  implemented  gateway  is  now  that  when  an  update  packet  comes,  the   gateway  will  relay  the  packet  and  begin  to  establish  a  new  association  for  the  host.  This  only   applies  to  update  packets  that  are  for  establishing  a  new  ESP-­‐SPI  association,  but  the  old   association  will  be  kept  and  will  be  only  dropped  if  it  has  not  been  used  for  7200  seconds.   There  are  some  proposals  to  solve  this  security  issues  between  hosts  and  middle  boxes  such   a  gateway,  the  security  problem  may  be  solved  by  introducing  an  additional  nonce  and   challenges  as  discussed  in  End-­‐Host  Authentication  for  HIP  Middle-­‐boxes  [W4].     .  Changing  IP  and  HIPL  

If  a  host  changes  its  IP-­‐address  and  it  wants  to  tell  the  other  host  that  it  has  changed  IP,  so   for  an  IP-­‐update  packet  to  reach  the  corresponding  host  it  has  to  traverse  the  gateway.   The  current  implementation  of  HIPL  is  that  even  if  a  host  initiates  an  IP  change  but  has  not   changed  the  IP,  the  update  packet  is  processed  as  an  IP  change  by  HIPL.  Even  if  it  seems   strange,  this  wont  breach  anything  declared  in  the  HIP  standard,  so  packets  that  are  relayed   through  the  gateway  would  have  the  IP  header  changed  without  the  risk  that  the  receiving   host  will  drop  those  packets  and  the  update  procedure  will  be  done  as  normal  see  Figure   6.8.  


Figure  6.8  A  normal  IP  change,  Host  A  changes  IP  sends  a  Update  packet  and  then  update  packets  with  ACK  are   sent  and  if  all  goes  well  a  ESP  association  is  set  between  the  hosts.  

6.4  Recommendations  

6.4.1  Security  

Recommendations  for  future  work  with  a  middleware  like  a  gateway  would  be  that  there  is   added  security  to  the  gateway,  this  could  range  from  that  the  gateway  verifies  the  sender   with  calculations  of  the  signatures  and  HMAC  and  response  to  update  packets  with  some   kind  of  challenge.  


6.4.1  Birthday  problem  

There  should  be  some  hash  that  can  guarantee  there  will  be  a  very  small  probability  of   collisions  in  the  association  database  of  the  gateway,  such  that  there  is  no  birthday  problem   that  is  needed  to  be  considered  and  possible  to  move  the  gateway  from  the  apartment   building  to  the  ISP’s  distribution  layer.  

6.5  Future  work


6.5.1  Development  of  a  gateway  

From  a  security  perspective,  the  gateway  SHOULD  inspect  packets  received  to  verify  that  it  is   from  a  legitimate  sender  as  it  is  now  it  cannot  confirm  any  packets  and  just  forward  it,  just   forwarding  could  leads  to  vulnerability  of  DDoS  or  other  malicious  denial  of  service  attacks.   There  are  proposals  that  you  introduce  another  4-­‐way  handshake  to  verify  packets  received   in  the  middle-­‐box  also  known  as  gateway  in  this  case  [W4].  


The  HIP-­‐host  could  include  the  challenge  request  and  response  to  solve  the  security  issues   involving  UPDATE  packets  in  HIP  and  the  association  between  hosts  going  through  a  middle-­‐ box  or  gateway  in  our  case.  


6.5.2  Coding  

If  someone  is  going  to  work  the  code  in  the  future  and  then  the  following  things  should  be   done  that  have  not  been  done  by  the  time  this  report  was  written.  

• Divide  the  IPv4  and  IPv6  thread  that  handles  the  handshake  into  two  threads  instead   of  being  one  as  it  is  now,  this  will  probably  speed  up  things.  

• As  different  threads  manipulate  the  SPI  database  there  is  no  critical  section  

coordination  between  the  different  threads  so  information  can  right  now  be  deleted   or  added  into  the  database  with  no  control  and  will  probably  result  in  consistency   problem  when  handling  too  many  hosts.  

• Use  the  HIPL  standard  for  coding,  the  HIPL  groups  uses  a  standard  for  coding  HIPL   and  we  have  not  used  it  so  it  should  be  advised  to  use  it  in  the  future.  

• A  better  lookup  system  for  the  DNS,  right  now  it  uses  three  dig  calls,  a  proper  DNS   call  should  be  done  with  a  response  that  can  be  parsed  that  contains  all  the  

necessary  information  with  just  one  lookup  i.e.  the  lookup  returns  IP  of  Host  A,  IP  of   Host  B  and  HINT.  





Related documents

Our tests show that the proposed system clearly shows the differences between most speech sounds, and that the visualizations for two persons pronouncing the same speech sound

In case of a fire a thermally activated Pressure Relief Device (TPRD) should empty the container before a pressure vessel explosion potentially can occur.. CNG tanks are according

In Monetary Union countries have lower travel costs, because those countries have common currency and don’t need to exchange when goes to another country who is in union.. If

Vid en granskning utav dem två stora regionala tidningarna i landet kan man se utifrån undersökningen att Dagens Nyheter har en något större representation utav

A large amount of previous research on local public transport demand was reviewed and the different estimates obtained in those studies were combined into a data set describing the

Since the series is non stationary, we estimate the long-run relationships between Wir turnover percentage change, Annual Gross Domestic Product growth rate and

Among the Tanzanians interviewed for the book are former vice presi- dent Rashid Kawawa, former prime minister Joseph Warioba, Head of the Mwalimu Nyerere Foundation Joseph

Further, the light rail movement in western Europe and the renaissance of the tram as a major public transport alternative in major cities in western Europe has made the management