Transcript HIPRG-3
Host Identifier Revocation in
HIP
draft-irtf-hiprg-revocation-01
Dacheng Zhang
IETF 79
Introduction
• Host identities are critical in generating
transient key for communicating between
two hosts
• After a HI is not secure enough any more,
it will be revoked and refreshed.
• This draft tries to discuss the issues with
key revocation and potential solutions in
HIP architectures.
Changes Since the Last Meeting
• Mention the delta CRL in section
• Add the discussion of extending RVSes to
support key revocation.
– When a user revoked it key, it needs to inform
the revocation and the new key to its RVS
– If a host tries to use antique HIT to access the
user, RVS will inform the host
• Correct typos
Investigation in HIP Proxies
draft-irtf-hiprg-proxies-01
Dacheng Zhang
IETF 79
Introduction
• HIP proxies play an important role in the
transition from the current Internet architecture
to the HIP architecture.
• There are various design options of HIP proxies,
each of them has advantages and limitations
respectively
• This draft tries to classify different
implementations of HIP proxies and compare
their performance in different high available
scenarios
Changes Since the Last Meeting
• Correct typos
• Analyze the solutions of separating the
DNS related functions from proxies and
integrating them into DNS resolvers.
Taxonomy
• DNS lookups Intercepting Proxies (DI proxies)
– DI1 proxies, which insert HIT in the AAAA records of
DNS answers
– DI2 proxies, which insert IP addresses from its IP
address pool in the AAAA records of DNS answers
– DI3 proxy, which only obtain information from DNS
lookups but do not modify them
• Non-DNS lookups Intercepting Proxies (N-DI proxies)
DNS Resolvers Supporting DI1
Proxies
• A resolver extended to support a DI1 proxy
returns HITs in DNS answers to ML hosts.
– The resolver needs to transfer other information (e.g,
IP addresses of the HIP hosts and RVSes) of the HIP
hosts to the associated DI1 proxy
DNS Resolvers Supporting DI2
Proxies
• A resolver extended to support a DI2 proxy
returns the IP addresses in the address pool of
the DI2 proxy in DNS answers to ML hosts.
– The resolver needs to transfer other information (e.g,
IP addresses of the HIP hosts, the IP addresses in the
pool which is assigned to the hosts, and RVSes) of
the HIP hosts to the DI2 proxy
– Maintain the mapping information so as to avoid
associated multiple HIs with a single IP address
DNS Resolvers Supporting DI1
Proxies
• Only transfer other information (e.g, IP
addresses of the HIP hosts and RVSes) of the
HIP hosts to the associated DI3 proxy
An issue with DI1 and DI3 Proxies
DNS server
Legacy Host
in a private
network
HIP Proxy1
HIP Proxy2
HIP host in
the public
network
• When there are multiple DI proxies are deployed at the
border of a private network, it is difficult to guarantee a
proxy intercepting DNS lookups can deal with
subsequent communication.
An issue with DI1 and DI3 Proxies
DNS resolver
HIP Proxy1
Legacy Host
in a private
network
HIP Proxy2
HIP host in
the public
network
• DNS resolver can forward the information of HIP hosts to
the proper HIP proxy.
Extensions of Host Identity
Protocol (HIP) with
Hierarchical Information
draft-xu-hip-hierarchical-01
Dacheng Zhang
IETF 79
Introduction
• Hierarchy in an effective way to reduce the
complexity in designing and managing complex
distributed systems
• With hierarchical information, different ID
management systems will get clear boundaries,
which is compatible with reasonable business
models
• This draft attempts to analyse the issues and
solutions in integrating hierarchical information
into HIP architectures.
Changes Since the Last Meeting
• Correct typos
• list some possible attacks on hierarchical
HITs
• Intrusion: Generation of HITs belonging to some
organization.
• Substitution: An attacker tries to use the HIT
already existed in the organization.
• Accumulation: Valid HITs can be prepared in
advance, i.e., collected in a database.
• Polutions on DNS and DHT servers
• DOS attacks on DNS and DHT servers
Any comments will be more than
welcomed