HIP-WG meeting, IETF62 Using HI P with Legacy Applications - - PowerPoint PPT Presentation

hip wg meeting ietf62 using hi p with legacy applications
SMART_READER_LITE
LIVE PREVIEW

HIP-WG meeting, IETF62 Using HI P with Legacy Applications - - PowerPoint PPT Presentation

HIP-WG meeting, IETF62 Using HI P with Legacy Applications (draft-henderson-hip-applications-00.txt) March 9, 2005 Tom Henderson 1 HIP working group Draft scope Intended to replace the Appendix A of the base specification Should


slide-1
SLIDE 1

1

HIP working group

HIP-WG meeting, IETF62 Using HI P with Legacy Applications (draft-henderson-hip-applications-00.txt)

March 9, 2005 Tom Henderson

slide-2
SLIDE 2

2

HIP working group

Draft scope

  • Intended to replace the Appendix A of the base

specification

  • Should not be required for HIP interoperability
  • Does not cover HIP-aware applications and API

– assumes that applications are not recompiled for HIP

  • Eventually intended to be suitable for an

Informational RFC

slide-3
SLIDE 3

3

HIP working group

Architecture and terminology

Referral: When an application passes what it assumes to be an IP address to another application on another host (e.g., FTP PORT command)

user space kernel

Legacy application BEET ESP HIP daemon

PF_INET PF_KEY PF_RAW

HIP SPDB

resolver

transport

DNS

IP layer HIP SADB

slide-4
SLIDE 4

4

HIP working group

Possibilities

How does application or user cause HIP to be invoked?

  • 1. Applications use IP addresses
  • 2. Applications use DNS names
  • 3. Applications use IP address-sized HITs or LSIs
slide-5
SLIDE 5

5

HIP working group

  • 1. I P address

user space kernel

Legacy application BEET ESP HIP daemon

PF_INET PF_KEY PF_RAW

HIP SPDB HIP SADB transport IP layer

  • Manually configure

address-to-HIT binding

  • Opportunistically

(don’t care about peer HIT)

  • Use reverse+forward

DNS lookup IP address used here, but HIP used by system

Pros: Naturally supports application-level referrals Cons: May have weaker security properties than use of HITs (depends on several factors); may be cumbersome (manual configuration)

slide-6
SLIDE 6

6

HIP working group

  • 2. DNS hooks

user space kernel

Legacy application BEET ESP HIP daemon

PF_INET PF_KEY PF_RAW

HIP SPDB

DNS resolver LSI/HIT returned by resolver

transport

System caches LSI to address binding

IP layer HIP SADB

Options:

  • 1. Have resolver return LSIs (HITs) instead of IP

addresses

  • 2. Use HIP-suffix in FQDN (e.g., www.ietf.org.hip)
slide-7
SLIDE 7

7

HIP working group

DNS issues

  • Should we spoof IP addresses in resolver calls?
  • Referrals

– Non-routable LSIs do not support referrals – Routable LSIs may work, but may require infrastructure support

  • When should system garbage-collect the LSI to

address bindings?

slide-8
SLIDE 8

8

HIP working group

  • 3. Connecting to HI Ts directly

user space kernel

Legacy application BEET ESP HIP daemon

PF_INET PF_KEY PF_RAW

HIT resolution?

transport HIP SPDB

connect(HIT)

  • r sendto(HIT)

IP layer HIP SADB

Pros: Most direct and secure naming semantics Cons: Application-level referrals; HIT-to-address resolution; distinguishing between HIT and IPv6 address

slide-9
SLIDE 9

9

HIP working group

Next steps

  • Pekka provided initial security section
  • Suggest to move LSI material from base

specification to this draft