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