Transcript powerpoint 760KB - HIP RG Supplemental Home Page

Workshop on HIP and Related Architectures
Workshop Overview
November 6, 2004
Tom Henderson, Pekka Nikander, and Scott
Shenker
1
Goals
• Interaction and exchange of ideas
– New name space(s) for the Internet
– Consequences of separating ID/locator
– HIP experimentation and deployment
• Outcomes
– new perspectives for participants
– identify research/experimental directions
– identify areas of consensus or disagreement
2
HIP vs. other approaches
• Although HIP is a current focus of IETF/IRTF,
workshop can consider other identifiers, e.g.
–
–
–
–
–
–
multi6 (SIM, NOID, CB64, WIMP, LIN6, multi6dt)
i3 triggers
non-global identifiers (FARA)
identifiers for web services
SIP URIs / IMS
Identity-based cryptography (DoCoMo paper)
3
Sessions
1. Applying and deploying an ID/locator split
– changing and managing applications and hosts
– dealing with legacy infrastructure and middleboxes
– introducing new infrastructure
2. Overlays, rendezvous, middleboxes, and delegation
– advanced middleboxes and firewalls
– advanced resolution and indirection
3. General architectural directions
– late binding
– encouragement of middleboxes in architecture
– approaches (FARA, HIP, i3, NIMROD, multi6, etc.)
4
Logistics
• $30 fee to cover catering (cash or check)
– Payable to whom?
•
•
•
•
•
Hotel wireless service only?
Availability of white papers on public site?
Working lunch (buffet sandwiches/salad)
Room vacated at 4:30
Discussions can continue at bar/dinner BOFs
tonight and through IETF
– IRTF HIP-RG meeting Friday Nov. 12
5
Session 1:
Applying and deploying an
identifier/locator split
Tom Henderson
6
Session discussion theme
• Assume that users and networks want to
deploy ID/locator separation
• How to “cross the chasm” between
architecture and reality (Early Adopters)?
Architectures
and specs
Deployed systems
and workable
infrastructure
7
Relevant white papers
• “HIP, a Marketing Analysis” by Tim Shepard
• “HIPpy Road Warriors Jumping Hoods over
Road Blocks” by Pekka Nikander
• “Network Attachment and Address
Configuration using HIP” by Seppo Heikkinen
et al.
• “Middlebox Traversal of HIP Communication”
by Martin Stiemerling et al.
• “Can SIP use HIP?” by Tom Henderson
8
Discussion organization
1. Host: Implementing and managing an
ID/locator split
– host and application concerns
2. Network: Making it work in today’s networks
– firewalls
– middleboxes (existing NATs)
– (resolution) infrastructure
3. Incentives: Application/user incentives for
deployment
– what are the killer apps?
9
1. Some host/application concerns
• Managing another set of identifiers
– DNS FQDN and IP can be complicated enough
– securing new identifiers (e.g. against phishing)
• APIs and application IDs
– the referral problem
• Support within network stack
–
–
–
–
changes to IPsec (BEET mode)
locator selection for multihoming
transport responses to mobility and multihoming
safekeeping of cryptographic material within
systems (trusted computing)
10
Experience with HIP
implementations
HIP has been shown to work, but...
• Software not completely ready for prime time
• Not trivial to install
– modified kernel or tap packets to user-space
•
HITs/HIs are cumbersome to deal with
– stored in insecure places
– how to manage multiple identities?
•
•
•
Transport layer issues unsolved
API issues and locator spoofing have been hard
problems
HIP conflicts with host firewall policies (sometimes
outside of control of user)
11
Managing identifiers
• How are average users going to manage a new
name space?
– existing network/DNS configuration can be
confusing even today
– privacy concerns
– non-repudiation/revocation concerns
• Many stack identifiers (e.g. HITs) are not
human readable
– how to securely bind user-friendly names like URIs
to stack names?
12
API issues
What is the identifier used by transport and
applications?
Alternatives:
– Require apps to use to a new resolver library and
become HIP-aware
Legacy apps?
– Spoof a “local scope identifier” as an IP address in
the name resolution
• Problems with referrals and delegation
• What if no DNS query?
– Use IP addresses and do a “host NAT” in the stack
• May cause ambiguity in mobility scenarios
13
In the network stack
• IPsec modifications for BEET mode
• locator selection and management policies
(which to use when?)
– relevant work: MAST, CELP
• locators change and transport protocols
– Congestion control, MTU
– what to do when no locators are active?
• where to store keys?
– should be in hardware somewhere
– how to make this less cumbersome?
14
Discussion
1. What can be done to make management of
new name space(s) easier for users?
• Privacy and security concerns
• Standard ways of including identity in applications
• New vs. legacy applications
2. What names are in use within applications and
APIs, and how to secure the various bindings?
3. How to handle multiple identities and multiple
locators within a stack
• securing the identifiers (e.g., key escrow)
• policy issues for transport connection triggers,
locator selection, etc.
15
2. Making it work in real networks
• Middlebox traversal
– firewall restrictions
– traversing legacy NATs– how??
• Deploying basic infrastructure
– Resolution service (names to locators)
– Dynamic Association Module (NIMROD) – keeping
resolution up-to-date across locator changes
• How much will it cost to support/administer?
16
Legacy middlebox traversal*
• HIP base exchange
– would be a problem for IPv6 NATs
– suggested IPv4 UDP HIP format is problematic for
NATs that use source port for demultiplexing
concurrent streams
– well-known problem of no inbound traffic
– no means to indicate sender’s (public) IP address
• Firewalls have similar (policy) concerns
• IPsec traversal of NATs
• Application-level gateway traversal (e.g. HTTP
proxy)
* Stiemerling, Quittek, and Eggert white paper
17
Infrastructure issues
• Can DNS RRs suffice for name resolution?
• What about deploying (flat) EID to locator
resolution?
– e.g. Wide-scale DHT deployment
• How to optimize resolution services both for
fast lookup and fast update?
– or should update and lookup be handled separately?
• How much will this all cost to deploy and
administer?
* Stiemerling, Quittek, and Eggert white paper
18
Discussion
1. Should we consider IPv4 a “lost cause”
because of NATs/firewalls?
– but can we expect to have pure HIP-aware IPv6
middleboxes?
– or.... is IPv6 deployment a “lost cause”?
2. How much to “defile” the architecture to get it
to work in current or anticipated networks?
– Is transport port # now a fundamental piece of IP
header and should be treated as such?
3. Should work on Teredo/STUNT/NUTSS-like
middleboxes (relays) to traverse transparent
NATs be considered a priority?
19
Discussion (cont.)
4. Will flat (DHT) resolution mechanisms for new
identifiers work on an Internet scale?
5. Should DNS be taken advantage of, or
sidestepped?
6. How to get providers to support resolution
infrastructure, and punch firewall holes?
• how much can we expect it to cost and still get
deployed?
20
3. Deployment incentives
• Can HIP (or other ID/loc split) have an SSHlike success story?
• What applications need this now?
– or are present workarounds “good enough”
• What new applications might be enabled by
ID/locator split?
• How expensive will the deployment be?
21
Some possible applications
• HIPpy road warriors
• HIP + SIP
– use SIP control plane to exchange host identities
– use HIP to secure data plane and provide mobility
• Network configuration
• ??
–
–
–
–
multi6 (site multihoming for IPv6)
trusted computing
peer to peer
anti-spam
22
Road warrior case study (Nikander)
Requirements:
• fully secured
• no user actions and taking no time
• mirrored synchronizing file systems
Challenges:
• NAT and legacy firewalls
• legacy servers
• authentication through “captive” web pages
Solutions:
• Upgrade NATs and firewalls
• Possibly combining HIP and CGA in network access
• HIP over UDP and related bridging/proxying
23
SIP+HIP case study*
• SIP can be used to disseminate Host Identities
– negates somewhat the need for HIP resolvers
• HIP provides man-in-the-middle security in the
data plane
• HIP mobility similar to MIPv6 with RO
• Other HIP benefits similar to purpose-built-keys
or traditional IPsec?
(i.e., is HIP’s utility to SIP only incremental, as
presently defined?)
24
*(Henderson white paper, and draft-tschofenig-hiprg-host-identities-00)
Network configuration*
DHCPDiscover
DHCPRequest
•
•
Additional techniques (SAML, SPKI) to authenticate ephemeral IDs
Related solutions?:
–
–
Cisco Network Admission Control (NAC) and Microsoft Network Access
Protection (NAP)
Transactions for Accessing Public Infrastructure-- TAPI (Nikander et al)
*(Heikkinen, Tschofenig, and Gelbord white paper)
25
Discussion
1. What are the possible killer apps for id/locator
split in general, and HIP in particular?
• enhancing existing apps
• new applications
2. Or is HIP primarily a security (DoS and MITM
prevention) enhancement?
3. Or is HIP a solution in search of a problem?
26
HIP and Related Architectures
Session II: Infrastructure, or Overlays, Rendezvous,
Delegation, and Middleboxes
(Pekka Nikander)
Presentation outline
•About this session
–Related position papers
•A framework for the discussion
–Combinatiorial complexity
•Where is the state?
•Strapping the boots
•Open questions
About this session
•Compared to Session I:
–More open ended
–Less structured
•Just a few slides, and then let it go
•(Backup slides just for the case...)
Related position papers
•Arkko et al: Hi3
•Gurtov & Joseph: Friends or Rivals: HIP and i3
•Eggert et al: HIP Resolution and Rendezvous
•Walfish & Balakrishnan: ID/Loc Split is Useful for
Middleboxes, too
•Tschofenig et al: HIP Middlebox Traversal
•Tschofenig et al: Advanced HIP-based Firewall Traversal
A framework for thought
•Maybe just one protocol (like in i3)
•Maybe separated protocols (like HIP and ESP)
•Maybe additional protocols
–Registration, middle box internal, …
Combinatorial complexity
•Combination of different types of middle boxes?
–Existing NATs and firewalls
–DHT nodes
–Architected HIP-based and firewall
–Application level intermediaries
Where is the state?
•How is the state created
in the network?
–Snooping?
–Protocol?
•How much “state” is there
in the packet?
•Soft state, but softer or
harder?
Packet
Middle box
EID
EID → Locator
EID
EID → EID’ @ Locator
EID*
EID → Locator
Locator*, EID
nothing
<EID@Locator>*
nothing [checks EID]
Bootstraps
•How to arrange initial rendezvous?
–Identity based overlay routing?
–Look up locator(s) from the infrastructure?
•How to find the infrastructure?
–Manual configuration is a bad answer!
–!Anycast? Router advertisement?
–Middle boxes that announce themselves on first communication?
Open questions (1)
•Rendezvous: overlay routing or name resolution?
•Bootstrap: how to find an infrastructure node?
•Layer 3.5 routing:
–How much state in packet vs middle boxes?
–How is the middle box state managed?
–Effects of asymmetric routing?
•What are the limiting and decisive factors?
Open Questions (2)
•Address hiding and DDoS protection
•Combination of different types of middle boxes?
•Operations and management issues?
–Debugging the system
•Dangers of having any centralization
–Aim for decentralised infrastructure?
•How to manage free riding?
Extra slides
i3
i3
Plain HIP without DHT
Plain HIP without DHT
Plain HIP with NAT
Plain HIP with NAT
FA instead of NAT and RVS
HIP Workshop@IETF 61
Architecture Session
James Kempf
DoCoMo Labs USA
45
Papers for this session
• “The FARA Architectural Model”, NewArch
– I’ll include the NewArch final report in the discussion, because it
touches on many of the same issues but discusses them more
broadly
• “The Benefits of Late Binding for HIP-like Mechanisms”,
Lakshminarayanan and Stoica, UCB
• “Exploring Deeper Issues of Separating Identity and Location for
Mobile Hosts” Kempf, Fu, Wood, and Kawahara, DoCoMo
46
Identity in HIP
• Right now in HIP:
– identity management == key management
• Key management is an unsolved problem in the
Internet currently
• Bottom line: Identifier is a computational object with
undefined relationship to offline considerations
47
Identity
48
Tying HIP identifiers to the noncyberworld?
• What it is:
– Pushing identity down into the stack
• Why it might be a good idea:
– Early mitigation of phishing and other security attacks based on
spoofed identity
– Good for naïve users
• Why it might be a bad idea:
– Compromises privacy and anonymity
• Are these the same?
– Bad for sophisticated users
49
DoCoMo Id Crypto
• Use identity-based cryptography to tie non-cyber identity to
security
• Use identity as public key, generate private key from that
– Requires identity-based crypto key generator
– Like Kerberos
• Identity could be DNS name, NAI or any other string
– In principle, authenticatable at I3 or HI3 rendezvous
– Looks like a good idea but...
50
Performance of Boneh/Franklin v.s. RSA
300
250
200
RSA
BF
150
100
50
0
Encryption
RSA:1024 bit modulus
BF: 512 bit P
Decryption
Signature
Verify
51
Stack Architecture
52
Stack Architecture
• HIP works somewhat like a session layer but it’s not
at the OSI model session layer
– Discussion this morning on SIP and HIP
– HIT is session identifier across locator changes
• Is the OSI model out of date?
• Does the stack architecture need some modification?
53
Problem with Layers*
• Pressure for new layer violations due to cross layer
optimization
• Functional dependency causes feature interactions
with loss of extensibility
• Reluctance to change existing implementation leads
to introduction of inter-layer shims
• Out-of-band signaling for middle boxes
*from NewArch final report
54
NewArch Roles?
• Functional units of communication are roles
– Building blocks out of which a communication is built
• Remodularization of large IP protocols
– Congestion control
– Forward Packet
– ...
• Organize data and metadata in packet is different
• But what about backward compatibility?
55
Compiler Model?
• Front end - Role modules activated by events
– Arrival of a packet
– Some application level user action
– ECN
• Back end - Events trigger compilation into standard
stack layers
• Limited, won’t handle complex cases
56
Routing
57
HIP and IP Routing
• HIP uses underlying IP routing
– Locators are IP addresses
– Src/dest IP address pair
• NATs/Firewalls and other middleboxes are reality
• Conventional wisdom is that they will disappear with IPv6
– Well, NATs at least...
– But is will that really be so?
58
Late Binding
• FARA and UCB
• Include identifier in packet
• Source route to network entity that can resolve the
identifier to actual locator
• Removes need for DNS lookup
• Semantics become “send packet to high level id”
rather than “send to address”
59
Discussion
• What are the possible killer apps for id/locator split in
general and HIP in particular?
– Enhancing existing apps
– New apps
• Is HIP primarily a security (DoS and MITM
prevention) enhancement?
• Is HIP a solution in search of a problem?
60
Summary of workshop
Pekka Nikander
61
Important
•Lowest layer of location independence
–Goals of HIP: Narrow or wider focus?
•Tradeoffs in identifier semantics
–Security vs. convenience
•How to coherently incorporate middle boxes
–Enumeration of what are the options
–Discussion on legacy middle boxes and NATs
•Killer apps: NAT, FW, IPv4/v6 crossing layer
•Configuration and management is a hard problem
Round table summary
•What was important to you in today’s discussions?
•What are you planning to work on (based on this)?
Scott & Ion
•What HIP is?
–A: Map public keys to identifiers
–B: Map identifiers to locators
Paul
•Reachability is the important problem
•Confirmation that HIP is not needed
•No killer app needed
Meta-Important
•How IETF deals with architectural questions
•How one evolves into a new architecture
•What are the building blocks for successful apps
•Increased understanding of HIP and connections to
other stuff
•Understanding that there is this confusion of what HIP
really is
–Lack of short term motivation
•SIP may be more important
Misc points
•Late binding
•Location vs. security aspects
•What should there be or not be
•What degree of crypto is needed?
–In Internet, private networks, etc.
•Peer-to-peer as a potential killer app