Native HIP API

1
Native HIP API

• Miika Komu ltmiika_at_iki.figt
• Andrei Gurtov gurtov_at_cs.helsinki.fi

2
Current Status

• No major changes
• Some minor corrections pending
• Future work planned
• We need some feedback before continuing

3
Feedback Summary

• Consider supporting also other addresses than IP
  in the API
• The API architecture and Application Specified
  Host Identities seem to be interesting
• Is the ED actually useful? Just use HITs?
• This should not be in the RG (move to WG?)

4
How to Proceed from Here?

• Do you think that this work is useful?
• Plain engineering move to WG?
• Some research ideas on the next slide
• Which of the ideas on the following slide do you
  find useful to proceed on? Feedback, please ?

5
How to Proceed New Ideas

• Opportunistic HIP may be difficult to implement
  using a standard sockets API
• The EDs of the Native HIP API can make it easier
• Alternatively, use Berkeley OCALA architecture
  (caveat dependency to i3?)
• Consider integration to Session or Service Layer
  identifiers?
• Crazy idea communicate EDs on-the-wire to
  support semantics similar to sctp_peeloff()?

6
References

• draft-mkomu-hip-native-api-00.txt
• Applying a Cryptographic Namespace to
  Applications Komu et al
• Application Programming Interfaces for Host
  Identity Protocol Komu
• draft-henderson-hip-applications-01

7
Questions / Feedback

• Miika Komu ltmiika_at_iki.figt
• or
• ltinfrahip_at_hiit.figt