One document matched: draft-yourtchenko-humansafe-ipv6-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-yourtchenko-humansafe-ipv6-00"
ipr="trust200902">
<front>
<title abbrev="Human-safe IPv6 addressing">
Human-safe IPv6: Cryptographic transformation of hostnames as a base for secure and manageable addressing</title>
<author fullname="Andrew Yourtchenko" initials="A." surname="Yourtchenko">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>De Kleetlaan, 7</street>
<city>Brussels</city>
<region>Diegem</region>
<code>B-1831</code>
<country>Belgium</country>
</postal>
<email>ayourtch@cisco.com</email>
</address>
</author>
<author fullname="Salman Asadullah" initials="S." surname="Asadullah">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>sasad@cisco.com</email>
</address>
</author>
<author fullname="Mircea Pisica" initials="M." surname="Pisica">
<organization abbrev="BT">BT</organization>
<address>
<!--
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
-->
<email>mircea.pisica@bt.com</email>
</address>
</author>
<date year="2012" />
<workgroup>opsec</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
</section>
<section title="Caveats of version -00">
<t>(section to be removed in the -01)</t>
<t>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.
</t>
</section>
<section title="Notational Conventions">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="problem_statement" title="Problem Statement">
<t>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</t>
</section>
<section anchor="proposed_solution" title="Proposed Solution">
<t>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 corresponding to hostname, encrypted with a
site-wide "secret".</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="hostnametoblob" title="Deriving the Cleartext Blob from Hostname">
<t>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.</t>
</section>
<section anchor="encryption" title="Encrypting the Cleartext Blob">
<t>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.</t>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>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.</t>
<t>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.</t>
</section>
<section title="Acknowledgements">
<t>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, ...</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
</references>
<!--
<references title="Informational References">
</references>
-->
<section title="A Sample Implementation">
<figure>
<preamble></preamble>
<artwork><![CDATA[
#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
* 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
*/
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++) {
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]);
exit(1);
}
exit(0);
}
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Changes">
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:07:30 |