Internet DRAFT - draft-yourtchenko-opsec-humansafe-ipv6
draft-yourtchenko-opsec-humansafe-ipv6
opsec A. Yourtchenko
Internet-Draft S. Asadullah
Intended status: Standards Track Cisco
Expires: September 3, 2012 M. Pisica
BT
March 2, 2012
Human-safe IPv6: Cryptographic transformation of hostnames as a base for
secure and manageable addressing
draft-yourtchenko-opsec-humansafe-ipv6-00
Abstract
Although the IPv6 address space within a single /64 subnet is very
large, the typical distribution of the addresses in this space is
very non-uniform. This non-uniformity, together with the dictionary-
based DNS brute-force enumeration, allows practical remote mapping of
the IPv6 addresses in these subnets. This document proposes a
technique which can be used to decrease the exposure of the server
subnets to trivial scanning. As a side effect, the proposed
technique allows to drastically simplify the address management.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Yourtchenko, et al. Expires September 3, 2012 [Page 1]
Internet-Draft Human-safe IPv6 addressing March 2012
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Caveats of version -00 . . . . . . . . . . . . . . . . . . . . 3
3. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 3
6. Deriving the Cleartext Blob from Hostname . . . . . . . . . . . 4
7. Encrypting the Cleartext Blob . . . . . . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
11. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. A Sample Implementation . . . . . . . . . . . . . . . 5
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Yourtchenko, et al. Expires September 3, 2012 [Page 2]
Internet-Draft Human-safe IPv6 addressing March 2012
1. Introduction
The conventional wisdom says that a typical IPv6 subnet has the
address space of 2^64 addresses, which makes it impossible to scan.
This results in commonly held assertion that it is impossible to scan
the IPv6 subnets, and the protocol is inherently more secure against
scanning than IPv4. However, the currently deployed addressing
techniques do not provide for a uniform distribution of the hosts
within the entirety of the space - certain addresses are much more
frequently used than the others. As a result, for the mostly-server
subnets, more often than not one can realistically map the hosts that
are present on that segment.
2. Caveats of version -00
(section to be removed in the -01)
This version of the document does assume the 64-bit Interface ID can
have any values, whereas there are various restrictions that need to
be taken into account (e.g., the U/L bit value). This is done
deliberately as -00 is aimed at illustrating the principle and
collecting the feedback from the community. Addressing these will be
done as part of the future work on the document and the accompanying
code.
3. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
4. Problem Statement
The problem is twofold: first, from the security point of view, one
should try to avoid the easy to guess patterns that the traditional
address assignment entails. At the same time, the naive approach of
assigning purely random addresses to servers is not very scalable in
real world for maintenance reasons
5. Proposed Solution
The idea is to exploit the randomness property of the encryption
function output. The interface identifier, used within the IPv6
address of the host, would be derived from the 64-bit data
Yourtchenko, et al. Expires September 3, 2012 [Page 3]
Internet-Draft Human-safe IPv6 addressing March 2012
corresponding to hostname, encrypted with a site-wide "secret".
This satisfies the requirement of having the interface identifiers
evenly distributed within the 2^64 space within the subnet; At the
same time, such a formal mechanism of generating the host ID allows
to reduce the maintenance overhead for the assignment and operation
of the IPv6 addresses. Also it would allow, if needed, a DNS-less
operation - after the network-wide secret is disseminated, the
generation of the interface IDs can be distributed.
For flexibility, we define the forward and reverse transformation
between the hostname and interface identifier as a two step process -
the first step is to derive from the hostname the 64-bit "cleartext
blob", which is being encrypted in the second step. Of course for
the decryption the steps are reversed.
This document does not propose to replace/eliminate any of the
existing address definition schemes, nor does it require the
implementation in the devices - the addresses can be generated and
assigned manually, and the enclosed algorithm can be used within the
address management application.
6. Deriving the Cleartext Blob from Hostname
The method that is used to perform a 1:1 mapping of the hostname into
the cleartext blob will determine the maximum length of the hostname.
The most simple and obvious method used to illustrate the principle
is an identity transform - therefore the hostname is itself the
cleartext blob, and therefore the maximum length is 8 characters.
Assuming the host name is using the characters from the range
[0-9a-z-_], this would mean using 6 bits per character - therefore
allowing to increase the maximum stored hostname length up to 10
characters. Potentially one can use other compression mechanisms -
e.g. Huffman encoding or arithmetic encoding - however, one must
leave a sufficient number of invalid values to detect the possible
typos in the address.
7. Encrypting the Cleartext Blob
Any good enough encryption mechanism with the block size of 64 bit
will suffice. For the demonstration purposes we choose DES - but
possibly other encryption mechanisms can be used.
Yourtchenko, et al. Expires September 3, 2012 [Page 4]
Internet-Draft Human-safe IPv6 addressing March 2012
8. Security Considerations
Since the hostnames are not a secret data after one makes a
connection to the server, one may argue that if an encryption
algorithm is vulnerable to a known plaintext attack, this approach
may make the mapping job easier.
Also, the fact that the encryption key distribution is rather wide,
one may have concerns about the exposure of the hostnames from the
addresses. However, we note that the scope of this proposal is
merely to raise the barrier for the anonymous remote mapping, as well
as to make the address management easier.
9. Acknowledgements
The authors are thankful to the following people for their review and
valuable comments: Gunter Van de Velde, Warren Kumari, Ron Broersma,
Jan Zorz, Ragnar Anfinsen, ...
10. IANA Considerations
This document has no IANA actions.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Appendix A. A Sample Implementation
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <openssl/des.h>
#include <arpa/inet.h>
#include <ctype.h>
/*
* A sample implementation of the human-safe
* IPv6 addressing algorithm.
* Requires the OpenSSL library, please compile
Yourtchenko, et al. Expires September 3, 2012 [Page 5]
Internet-Draft Human-safe IPv6 addressing March 2012
* with "gcc human-safe.c -lssl"
*/
/*
* Encrypt and Decrypt routines are using DES as an example of
* a symmetric encryption that has a 64-bit block size.
*/
int encrypt(char *dst, char *src, char *key) {
int n=0;
DES_cblock k;
DES_key_schedule sch;
memset(k, 0, sizeof(k));
memcpy(k, key, 8);
DES_set_odd_parity(&k);
if (DES_set_key_checked(&k, &sch) < 0) {
printf("Error checking key\n");
}
DES_ecb_encrypt( (unsigned char (*)[8])src,
(unsigned char (*)[8])dst, &sch, DES_ENCRYPT);
return n;
}
int decrypt(char *dst, char *src, char *key) {
int n=0;
DES_cblock k;
DES_key_schedule sch;
memset(k, 0, sizeof(k));
memcpy(k, key, 8);
DES_set_odd_parity(&k);
if (DES_set_key_checked(&k, &sch) < 0) {
printf("Error checking key\n");
}
DES_ecb_encrypt( (unsigned char (*)[8])src,
(unsigned char (*)[8])dst, &sch, DES_DECRYPT);
return n;
}
/*
* For the reference implementation, the mapping of the hostname
* to cleartext blob is an identity transform
*/
Yourtchenko, et al. Expires September 3, 2012 [Page 6]
Internet-Draft Human-safe IPv6 addressing March 2012
int hostname_enc(char *dst, char *src) {
memcpy(dst, src, 8);
return 1;
}
int hostname_dec(char *dst, char *src) {
int i;
for(i=0;i<8;i++) {
if(!isalnum(src[i])) {
return 0;
}
}
memcpy(dst, src, 8);
/* If it was the full-length string, null-terminate it */
dst[8] = 0;
return 1;
}
/* Main functions */
host_to_addr(char *addr, char *host, char *prefix, char *secret) {
int i;
char blob[8];
char xor_block[8];
inet_pton(AF_INET6, prefix, addr);
/* zero out the interface id part of /64 */
for (i=8; i<16; i++) {
addr[i] = 0;
}
hostname_enc(blob, host);
encrypt(&addr[8], blob, secret);
encrypt(xor_block, addr, secret);
for(i=0; i<8; i++) {
addr[i+8] ^= xor_block[i];
}
return i;
}
int addr_to_host(char *host, char *addr, char *secret) {
char aptr[16];
char blob[8];
char xor_block[8];
int i;
memcpy(aptr, addr, 16);
encrypt(xor_block, addr, secret);
for(i=0;i<8;i++) {
Yourtchenko, et al. Expires September 3, 2012 [Page 7]
Internet-Draft Human-safe IPv6 addressing March 2012
aptr[8+i] ^= xor_block[i];
}
decrypt(blob, &aptr[8], secret);
if (!hostname_dec(host, blob)) {
printf("Hostname decode failed, address error ?\n");
return 0;
}
return 1;
}
void usage(char *name) {
printf("Usage: \n");
printf(" %s <secret> encode <prefix> <hostname>\n", name);
printf(" %s <secret> decode <address>\n", name);
}
int main(int argc, char* argv[]) {
char *secret;
char *operation;
char *prefix;
char *hostname;
char hostname_decoded[42];
char addr_encoded[16];
char buf[42];
if (argc < 4) {
usage(argv[0]);
exit(1);
}
secret = argv[1];
operation = argv[2];
if (0 == strcmp(operation, "encode")) {
prefix = argv[3];
hostname = argv[4];
host_to_addr(addr_encoded, hostname, prefix, secret);
inet_ntop(AF_INET6, addr_encoded, buf, sizeof(buf));
printf("%s\n", buf);
} else if (0 == strcmp(operation, "decode")) {
prefix = argv[3];
inet_pton(AF_INET6, prefix, addr_encoded);
addr_to_host(hostname_decoded, addr_encoded, secret);
printf("%s\n", hostname_decoded);
} else {
usage(argv[0]);
Yourtchenko, et al. Expires September 3, 2012 [Page 8]
Internet-Draft Human-safe IPv6 addressing March 2012
exit(1);
}
exit(0);
}
Appendix B. Changes
Authors' Addresses
Andrew Yourtchenko
Cisco Systems, Inc.
De Kleetlaan, 7
Brussels, Diegem B-1831
Belgium
Email: ayourtch@cisco.com
Salman Asadullah
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sasad@cisco.com
Mircea Pisica
BT
Email: mircea.pisica@bt.com
Yourtchenko, et al. Expires September 3, 2012 [Page 9]
