diff options
| author | Othmar Gsenger <otti@anytun.org> | 2008-04-12 11:24:13 +0000 |
|---|---|---|
| committer | Othmar Gsenger <otti@anytun.org> | 2008-04-12 11:24:13 +0000 |
| commit | 572823f65b365cd27345ee59d89b115df34c5338 (patch) | |
| tree | 8f9ae97b3480b5fe7f049ec040b0e8aeefab7bd9 | |
| parent | makefile fixes (diff) | |
svn cleanup
74 files changed, 0 insertions, 7570 deletions
diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-00.html b/draft-gsenger-secure-anycast-tunneling-protocol-00.html deleted file mode 100644 index 658213b..0000000 --- a/draft-gsenger-secure-anycast-tunneling-protocol-00.html +++ /dev/null @@ -1,686 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html lang="en"><head><title>secure anycast tunneling protocol (SATP)</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -<meta name="description" content="secure anycast tunneling protocol (SATP)"> -<meta name="keywords" content="satp, Internet-Draft, secure anycast tunneling protocol, anycast, tunnel, secure, protocol"> -<meta name="generator" content="xml2rfc v1.32 (http://xml.resource.org/)"> -<style type='text/css'><!-- - body { - font-family: verdana, charcoal, helvetica, arial, sans-serif; - font-size: small; color: #000; background-color: #FFF; - margin: 2em; - } - h1, h2, h3, h4, h5, h6 { - font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif; - font-weight: bold; font-style: normal; - } - h1 { color: #900; background-color: transparent; text-align: right; } - h3 { color: #333; background-color: transparent; } - - td.RFCbug { - font-size: x-small; text-decoration: none; - width: 30px; height: 30px; padding-top: 2px; - text-align: justify; vertical-align: middle; - background-color: #000; - } - td.RFCbug span.RFC { - font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; - font-weight: bold; color: #666; - } - td.RFCbug span.hotText { - font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; - font-weight: normal; text-align: center; color: #FFF; - } - - table.TOCbug { width: 30px; height: 15px; } - td.TOCbug { - text-align: center; width: 30px; height: 15px; - color: #FFF; background-color: #900; - } - td.TOCbug a { - font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif; - font-weight: bold; font-size: x-small; text-decoration: none; - color: #FFF; background-color: transparent; - } - - td.header { - font-family: arial, helvetica, sans-serif; font-size: x-small; - vertical-align: top; width: 33%; - color: #FFF; background-color: #666; - } - td.author { font-weight: bold; font-size: x-small; margin-left: 4em; } - td.author-text { font-size: x-small; } - - /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ - a.info { - /* This is the key. */ - position: relative; - z-index: 24; - text-decoration: none; - } - a.info:hover { - z-index: 25; - color: #FFF; background-color: #900; - } - a.info span { display: none; } - a.info:hover span.info { - /* The span will display just on :hover state. */ - display: block; - position: absolute; - font-size: smaller; - top: 2em; left: -5em; width: 15em; - padding: 2px; border: 1px solid #333; - color: #900; background-color: #EEE; - text-align: left; - } - - a { font-weight: bold; } - a:link { color: #900; background-color: transparent; } - a:visited { color: #633; background-color: transparent; } - a:active { color: #633; background-color: transparent; } - - p { margin-left: 2em; margin-right: 2em; } - p.copyright { font-size: x-small; } - p.toc { font-size: small; font-weight: bold; margin-left: 3em; } - table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; } - td.toc { font-size: small; font-weight: bold; vertical-align: text-top; } - - ol.text { margin-left: 2em; margin-right: 2em; } - ul.text { margin-left: 2em; margin-right: 2em; } - li { margin-left: 3em; } - - /* RFC-2629 <spanx>s and <artwork>s. */ - em { font-style: italic; } - strong { font-weight: bold; } - dfn { font-weight: bold; font-style: normal; } - cite { font-weight: normal; font-style: normal; } - tt { color: #036; } - tt, pre, pre dfn, pre em, pre cite, pre span { - font-family: "Courier New", Courier, monospace; font-size: small; - } - pre { - text-align: left; padding: 4px; - color: #000; background-color: #CCC; - } - pre dfn { color: #900; } - pre em { color: #66F; background-color: #FFC; font-weight: normal; } - pre .key { color: #33C; font-weight: bold; } - pre .id { color: #900; } - pre .str { color: #000; background-color: #CFF; } - pre .val { color: #066; } - pre .rep { color: #909; } - pre .oth { color: #000; background-color: #FCF; } - pre .err { background-color: #FCC; } - - /* RFC-2629 <texttable>s. */ - table.all, table.full, table.headers, table.none { - font-size: small; text-align: center; border-width: 2px; - vertical-align: top; border-collapse: collapse; - } - table.all, table.full { border-style: solid; border-color: black; } - table.headers, table.none { border-style: none; } - th { - font-weight: bold; border-color: black; - border-width: 2px 2px 3px 2px; - } - table.all th, table.full th { border-style: solid; } - table.headers th { border-style: none none solid none; } - table.none th { border-style: none; } - table.all td { - border-style: solid; border-color: #333; - border-width: 1px 2px; - } - table.full td, table.headers td, table.none td { border-style: none; } - - hr { height: 1px; } - hr.insert { - width: 80%; border-style: none; border-width: 0; - color: #CCC; background-color: #CCC; - } ---></style> -</head> -<body> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> -<tr><td class="header">Network Working Group</td><td class="header">O. Gsenger</td></tr> -<tr><td class="header">Internet-Draft</td><td class="header">June 22, 2007</td></tr> -<tr><td class="header">Expires: December 24, 2007</td><td class="header"> </td></tr> -</table></td></tr></table> -<h1><br />secure anycast tunneling protocol (SATP)<br />draft-gsenger-secure-anycast-tunneling-protocol-00</h1> - -<h3>Status of this Memo</h3> -<p> -By submitting this Internet-Draft, -each author represents that any applicable patent or other IPR claims of which -he or she is aware have been or will be disclosed, -and any of which he or she becomes aware will be disclosed, -in accordance with Section 6 of BCP 79.</p> -<p> -Internet-Drafts are working documents of the Internet Engineering -Task Force (IETF), its areas, and its working groups. -Note that other groups may also distribute working documents as -Internet-Drafts.</p> -<p> -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.”</p> -<p> -The list of current Internet-Drafts can be accessed at -<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p> -<p> -The list of Internet-Draft Shadow Directories can be accessed at -<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p> -<p> -This Internet-Draft will expire on December 24, 2007.</p> - -<h3>Copyright Notice</h3> -<p> -Copyright © The IETF Trust (2007).</p> - -<h3>Abstract</h3> - -<p>The secure anycast tunneling protocol (SATP) defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It allows tunneling of every ETHER TYPE protocol (ethernet, ip ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It can be used as an encrypted alternative to <a class='info' href='#RFC2003'>IP Encapsulation within IP<span> (</span><span class='info'>Perkins, C., “IP Encapsulation within IP,” October 1996.</span><span>)</span></a> [3] and <a class='info' href='#RFC2784'>Generic Routing Encapsulation (GRE)<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.</span><span>)</span></a> [4]. It supports both anycast receivers and senders. - -</p><a name="toc"></a><br /><hr /> -<h3>Table of Contents</h3> -<p class="toc"> -<a href="#anchor1">1.</a> -Introduction<br /> - <a href="#anchor2">1.1.</a> -Notational Conventions<br /> -<a href="#anchor3">2.</a> -Motivation and usage scenarios<br /> - <a href="#anchor4">2.1.</a> -Usage scenarions<br /> - <a href="#anchor5">2.1.1.</a> -Tunneling from unicast hosts over anycast routers to other unicast hosts<br /> - <a href="#anchor6">2.1.2.</a> -Tunneling from unicast hosts to anycast networks<br /> - <a href="#anchor7">2.1.3.</a> -Redundant tunnel connection of 2 networks<br /> - <a href="#anchor8">2.2.</a> -Encapsulation<br /> -<a href="#anchor9">3.</a> -Using SATP on top of IP<br /> - <a href="#anchor10">3.1.</a> -Fragmentation<br /> - <a href="#anchor11">3.2.</a> -ICMP messages<br /> -<a href="#anchor12">4.</a> -Protocol specification<br /> - <a href="#anchor13">4.1.</a> -Header format<br /> - <a href="#anchor14">4.2.</a> -sender ID<br /> - <a href="#anchor15">4.3.</a> -sequence number<br /> - <a href="#anchor16">4.4.</a> -payload<br /> - <a href="#anchor17">4.5.</a> -padding (OPTIONAL)<br /> - <a href="#anchor18">4.6.</a> -padding count (OPTIONAL)<br /> - <a href="#anchor19">4.7.</a> -payload type field<br /> - <a href="#anchor20">4.7.1.</a> -MKI (OPTIONAL)<br /> - <a href="#anchor21">4.7.2.</a> -authentication tag (RECOMMENDED)<br /> - <a href="#anchor22">4.8.</a> -Encryption<br /> -<a href="#anchor23">5.</a> -Security Considerations<br /> - <a href="#anchor24">5.1.</a> -Replay protection<br /> -<a href="#anchor25">6.</a> -IANA Considerations<br /> -<a href="#rfc.references1">7.</a> -References<br /> - <a href="#rfc.references1">7.1.</a> -Normative References<br /> - <a href="#rfc.references2">7.2.</a> -Informational References<br /> -<a href="#rfc.authors">§</a> -Author's Address<br /> -<a href="#rfc.copyright">§</a> -Intellectual Property and Copyright Statements<br /> -</p> -<br clear="all" /> - -<a name="anchor1"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.1"></a><h3>1. -Introduction</h3> - -<p>SATP is a mixture of a generic encapsulation protocol like <a class='info' href='#RFC2784'>GRE<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.</span><span>)</span></a> [4] and a secure tunneling protocol as <a class='info' href='#RFC2401'>IPsec<span> (</span><span class='info'>Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.</span><span>)</span></a> [5] in tunnel mode. It can be used to build redundant virtual private network (VPN) connections. It supports peer to peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines a <a class='info' href='#RFC1546'>Host Anycast Service<span> (</span><span class='info'>Partridge, C., Mendez, T., and W. Milliken, “Host Anycasting Service,” November 1993.</span><span>)</span></a> [6]. Encryption is done per packet, so the protocol is robust against packet loss and routing changes. - To save some header overhead it uses the encryption techniques of <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1]. - -</p> -<a name="anchor2"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.1.1"></a><h3>1.1. -Notational Conventions</h3> - -<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [2]. -</p> -<a name="anchor3"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2"></a><h3>2. -Motivation and usage scenarios</h3> - -<p>This section gives an overview of possible usage scenarios. Please note, that the protocols used in the figures are only examples and that SATP itself does not care about either transport protocols or encapsulated protocols. Routing is not done by SATP and each implemetation MAY choose it's own way of doing this task (e.g. using functions provided by the operating system). SATP is used only to encapsulate and encrypt data. -</p> -<a name="anchor4"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1"></a><h3>2.1. -Usage scenarions</h3> - -<a name="anchor5"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1.1"></a><h3>2.1.1. -Tunneling from unicast hosts over anycast routers to other unicast hosts</h3> -<br /><hr class="insert" /> -<a name="tunnel_mode"></a> - -<p>An example of SATP used to tunnel in a unicast client - anycast server model -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 1 </b></font><br /></td></tr></table><hr class="insert" /> - -<p>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing descition. -</p> -<a name="anchor6"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1.2"></a><h3>2.1.2. -Tunneling from unicast hosts to anycast networks</h3> -<br /><hr class="insert" /> -<a name="open_tunnel_mode"></a> - -<p>An example of SATP used to encrypt data between a unicast host and anycast networks -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 2 </b></font><br /></td></tr></table><hr class="insert" /> - -<p>When the unicast hosts wants to transmit data to one of the anycast DNS servers, it encapsulates the data and sends a SATP packet to the anycast address of the routers. The packet arrives at one of the routers, gets decapsulated and routed to the DNS server. This method can be used to tunnel between a clients and networks providing anycast services. It can also be used the other way to virtually locate a unicast service within anycasted networks. -</p> -<a name="anchor7"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1.3"></a><h3>2.1.3. -Redundant tunnel connection of 2 networks</h3> -<br /><hr class="insert" /> -<a name="connect_networks"></a> - -<p>An example of SATP used to connect 2 networks -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 3 </b></font><br /></td></tr></table><hr class="insert" /> - -<p>Network A has multiple routers, that act as gateway/tunnel endpoints to another network B. This is done to build a redundant encrypted tunnel connection between the two networks. All tunnel endpoints of network A share the same anycast address and all tunnel endpoints of network B share another anycast address. When a packet from network A gets transmitted to network B, it first arrives on one of network A's border routers. Which router is used is determined by network A's internal routing. This router encapsulates the package and sends it to the anycast address of the network B routers. The SATP packet arrives at one of network B's routers and gets decapsulated and routed to it's destination within network B. -</p> -<a name="anchor8"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.2"></a><h3>2.2. -Encapsulation</h3> - -<p>SATP does not depend on which lower layer protocols is used, but this section gives an example of how packets could look like. - -</p><br /><hr class="insert" /> -<a name="transport_udp"></a> - -<p>Examples of SATP used with different lower layer and payload protocols -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - -Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - -Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - -Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - -Tunneling of IPv6 over IPv4 with RTP payload -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 4 </b></font><br /></td></tr></table><hr class="insert" /> - -<a name="anchor9"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.3"></a><h3>3. -Using SATP on top of IP</h3> - -<a name="anchor10"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.3.1"></a><h3>3.1. -Fragmentation</h3> - -<p> - The only way of fully supporting fragmentation would be to synchronise fragments between all anycast servers. This is considered to be too much overhead, so there are two non perfect solutions for these problems. Either fragmentation HAS TO be disabled or if not all fragments arrive at the same server the ip datagramm HAS TO be discarded. As routing changes are not expected to occure very frequently, the encapsulated protocol can do a retransmission and all fragments will arrive at the new server. - -</p> -<p>If the payload type is IP and the ip headers's Don't Fragment (DF) bit is set, than the DF bit of the outer IP header HAS TO be set as well. -</p> -<a name="anchor11"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.3.2"></a><h3>3.2. -ICMP messages</h3> - -<p>ICMP messages MUST be relayed according to <a class='info' href='#RFC2003'>rfc2003 section 4<span> (</span><span class='info'>Perkins, C., “IP Encapsulation within IP,” October 1996.</span><span>)</span></a> [3]. This is needed for path MTU detection. -</p> -<a name="anchor12"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4"></a><h3>4. -Protocol specification</h3> - -<a name="anchor13"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.1"></a><h3>4.1. -Header format</h3> -<br /><hr class="insert" /> -<a name="prot_header_table"></a> - -<p>Protocol Format -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | sender ID # | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ + | - | | .... payload ... | | - | |-------------------------------+-------------------------------+ | - | | padding (OPT) | pad count(OPT)| payload type | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 5 </b></font><br /></td></tr></table><hr class="insert" /> - -<p> -</p> -<a name="anchor14"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.2"></a><h3>4.2. -sender ID</h3> - -<p>The sender ID is a 16 bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address -</p> -<a name="anchor15"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.3"></a><h3>4.3. -sequence number</h3> - -<p>The sequence number is a 32 bit unsigned integer in network byte order. It starts with a random value and is increased by 1 for every sent packet. After the maximum value, it starts over from 0. This overrun causes the ROC to be increased. -</p> -<a name="anchor16"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.4"></a><h3>4.4. -payload</h3> - -<p>A packet of the type payload type (e.g. an IP packet). -</p> -<a name="anchor17"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.5"></a><h3>4.5. -padding (OPTIONAL)</h3> - -<p>Padding of max 255 octets. -None of the pre-defined encryption transforms uses any padding; for - these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding lenght. -</p> -<a name="anchor18"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.6"></a><h3>4.6. -padding count (OPTIONAL)</h3> - -<p>The number of octets of the padding field. This field is optional. It's presence is signaled by the key management and not by this protocol. If this field isn't present, the padding field MUST NOT be present as well. -</p> -<a name="anchor19"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.7"></a><h3>4.7. -payload type field</h3> - -<p>The payload type field defines the payload protocol. ETHER TYPE protocol numbers are used. <a href='http://www.iana.org/assignments/ethernet-numbers'>See IANA assigned ethernet numbers</a> . The values 0000-05DC are reserverd and MUST NOT be used. - <br /><hr class="insert" /> -<a name="prot_type_table"></a> - -<p>Some examples for protocol types -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> -HEX -0000 Reserved -.... Reserved -05DC Reserved -0800 Internet IP (IPv4) -6558 transparent ethernet bridging -86DD IPv6 -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 6 </b></font><br /></td></tr></table><hr class="insert" /> - - -<a name="anchor20"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.7.1"></a><h3>4.7.1. -MKI (OPTIONAL)</h3> - -<p>The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See <a class='info' href='#RFC3711'>SRTP Section 3.1<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1] for details -</p> - -<a name="anchor21"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.7.2"></a><h3>4.7.2. -authentication tag (RECOMMENDED)</h3> - -<p>The authentication tag is RECOMMENDED and of configurable length. It contains a cryptographic checksum of the sender ID, sequence number and the encrypted portion, but not of the MKI. On sender side encryption HAS TO be done before calculating the authentication tag. A receiver HAS TO calculate the authentication tag before decrypting the encrypted portion. -</p> - - -<a name="anchor22"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.8"></a><h3>4.8. -Encryption</h3> - -<p>Encryption is done in the same way as for <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1]. This section will only discuss some small changes that HAVE TO be made. Please read <a class='info' href='#RFC3711'>SRTP RFC3711 section 3-9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1] for details. -</p> -<p>The least significant bits of SSRC are replaced by the sender ID and the rest is filled with zeros. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC. -</p><br /><hr class="insert" /> -<a name="srtp_vs_satp"></a> - -<p>Difference between SRTP and SATP -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 7 </b></font><br /></td></tr></table><hr class="insert" /> - -<a name="anchor23"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.5"></a><h3>5. -Security Considerations</h3> - -<p>As SATP uses the same encrytion technics as <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1], it shares the same security issues. This section will only discuss some small changes. Please read <a class='info' href='#RFC3711'>SRTP RFC3711 section 9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1] for details. -</p> -<a name="anchor24"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.5.1"></a><h3>5.1. -Replay protection</h3> - -<p>Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SHOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast receiver. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack. -</p> -<a name="anchor25"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.6"></a><h3>6. -IANA Considerations</h3> - -<p>The protocol is intended to be used on top of IP or on top of UDP (to be compatible with NAT routers), so UDP and IP protocol numbers have to be assiged by IANA. -</p> -<a name="rfc.references"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.7"></a><h3>7. -References</h3> - -<a name="rfc.references1"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>7.1. Normative References</h3> -<table width="99%" border="0"> -<tr><td class="author-text" valign="top"><a name="RFC3711">[1]</a></td> -<td class="author-text">Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “<a href="ftp://ftp.isi.edu/in-notes/rfc3711.txt">The Secure Real-time Transport Protocol (SRTP)</a>,” RFC 3711, March 2004.</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC2119">[2]</a></td> -<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC2003">[3]</a></td> -<td class="author-text"><a href="mailto:perk@watson.ibm.com">Perkins, C.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2003.txt">IP Encapsulation within IP</a>,” RFC 2003, October 1996 (<a href="ftp://ftp.isi.edu/in-notes/rfc2003.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2003.xml">XML</a>).</td></tr> -</table> - -<a name="rfc.references2"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>7.2. Informational References</h3> -<table width="99%" border="0"> -<tr><td class="author-text" valign="top"><a name="RFC2784">[4]</a></td> -<td class="author-text"><a href="mailto:dino@procket.com">Farinacci, D.</a>, <a href="mailto:tony1@home.net">Li, T.</a>, <a href="mailto:stan_hanks@enron.net">Hanks, S.</a>, <a href="mailto:dmm@cisco.com">Meyer, D.</a>, and <a href="mailto:pst@juniper.net">P. Traina</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2784.txt">Generic Routing Encapsulation (GRE)</a>,” RFC 2784, March 2000.</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC2401">[5]</a></td> -<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>,” RFC 2401, November 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2401.xml">XML</a>).</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC1546">[6]</a></td> -<td class="author-text"><a href="mailto:craig@bbn.com">Partridge, C.</a>, <a href="mailto:tmendez@bbn.com">Mendez, T.</a>, and <a href="mailto:milliken@bbn.com">W. Milliken</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc1546.txt">Host Anycasting Service</a>,” RFC 1546, November 1993.</td></tr> -</table> - -<a name="rfc.authors"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>Author's Address</h3> -<table width="99%" border="0" cellpadding="0" cellspacing="0"> -<tr><td class="author-text"> </td> -<td class="author-text">Othmar Gsenger</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Puerstingerstr 32</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Saalfelden 5760</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">AT</td></tr> -<tr><td class="author" align="right">Phone: </td> -<td class="author-text"></td></tr> -<tr><td class="author" align="right">Email: </td> -<td class="author-text"><a href="mailto:satp@gsenger.com">satp@gsenger.com</a></td></tr> -<tr><td class="author" align="right">URI: </td> -<td class="author-text"><a href="http://www.gsenger.com/satp/">http://www.gsenger.com/satp/</a></td></tr> -</table> -<a name="rfc.copyright"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>Full Copyright Statement</h3> -<p class='copyright'> -Copyright © The IETF Trust (2007).</p> -<p class='copyright'> -This document is subject to the rights, -licenses and restrictions contained in BCP 78, -and except as set forth therein, -the authors retain all their rights.</p> -<p class='copyright'> -This document and the information contained herein are provided -on an “AS IS” basis and THE CONTRIBUTOR, -THE ORGANIZATION HE/SHE REPRESENTS -OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST -AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, -EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT -THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY -IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR -PURPOSE.</p> -<h3>Intellectual Property</h3> -<p class='copyright'> -The IETF takes no position regarding the validity or scope of any -Intellectual Property Rights or other rights that might be claimed -to pertain to the implementation or use of the technology -described in this document or the extent to which any license -under such rights might or might not be available; nor does it -represent that it has made any independent effort to identify any -such rights. -Information on the procedures with respect to -rights in RFC documents can be found in BCP 78 and BCP 79.</p> -<p class='copyright'> -Copies of IPR disclosures made to the IETF Secretariat and any -assurances of licenses to be made available, -or the result of an attempt made to obtain a general license or -permission for the use of such proprietary rights by implementers or -users of this specification can be obtained from the IETF on-line IPR -repository at <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p> -<p class='copyright'> -The IETF invites any interested party to bring to its attention -any copyrights, -patents or patent applications, -or other -proprietary rights that may cover technology that may be required -to implement this standard. -Please address the information to the IETF at <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p> -<h3>Acknowledgment</h3> -<p class='copyright'> -Funding for the RFC Editor function is provided by -the IETF Administrative Support Activity (IASA).</p> -</body></html> diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-00.txt b/draft-gsenger-secure-anycast-tunneling-protocol-00.txt deleted file mode 100644 index fb3ca45..0000000 --- a/draft-gsenger-secure-anycast-tunneling-protocol-00.txt +++ /dev/null @@ -1,952 +0,0 @@ - - - -Network Working Group O. Gsenger -Internet-Draft June 22, 2007 -Expires: December 24, 2007 - - - secure anycast tunneling protocol (SATP) - draft-gsenger-secure-anycast-tunneling-protocol-00 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - 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." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on December 24, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 1] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -Abstract - - The secure anycast tunneling protocol (SATP) defines a protocol used - for communication between any combination of unicast and anycast - tunnel endpoints. It allows tunneling of every ETHER TYPE protocol - (ethernet, ip ...). SATP directly includes cryptography and message - authentication based on the methodes used by SRTP. It can be used as - an encrypted alternative to IP Encapsulation within IP [3] and - Generic Routing Encapsulation (GRE) [4]. It supports both anycast - receivers and senders. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 - 2. Motivation and usage scenarios . . . . . . . . . . . . . . . . 4 - 2.1. Usage scenarions . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.1. Tunneling from unicast hosts over anycast routers - to other unicast hosts . . . . . . . . . . . . . . . . 4 - 2.1.2. Tunneling from unicast hosts to anycast networks . . . 5 - 2.1.3. Redundant tunnel connection of 2 networks . . . . . . 5 - 2.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Using SATP on top of IP . . . . . . . . . . . . . . . . . . . 8 - 3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. ICMP messages . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Protocol specification . . . . . . . . . . . . . . . . . . . . 9 - 4.1. Header format . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2. sender ID . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.3. sequence number . . . . . . . . . . . . . . . . . . . . . 9 - 4.4. payload . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.5. padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 9 - 4.6. padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 10 - 4.7. payload type field . . . . . . . . . . . . . . . . . . . . 10 - 4.7.1. MKI (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10 - 4.7.2. authentication tag (RECOMMENDED) . . . . . . . . . . . 10 - 4.8. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 5.1. Replay protection . . . . . . . . . . . . . . . . . . . . 12 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 7.2. Informational References . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Intellectual Property and Copyright Statements . . . . . . . . . . 17 - - - - - - -Gsenger Expires December 24, 2007 [Page 2] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -1. Introduction - - SATP is a mixture of a generic encapsulation protocol like GRE [4] - and a secure tunneling protocol as IPsec [5] in tunnel mode. It can - be used to build redundant virtual private network (VPN) connections. - It supports peer to peer tunnels, where tunnel endpoints can be any - combination of unicast, multicast or anycast hosts, so it defines a - Host Anycast Service [6]. Encryption is done per packet, so the - protocol is robust against packet loss and routing changes. To save - some header overhead it uses the encryption techniques of SRTP [1]. - -1.1. Notational Conventions - - The keywords "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 [2]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 3] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -2. Motivation and usage scenarios - - This section gives an overview of possible usage scenarios. Please - note, that the protocols used in the figures are only examples and - that SATP itself does not care about either transport protocols or - encapsulated protocols. Routing is not done by SATP and each - implemetation MAY choose it's own way of doing this task (e.g. using - functions provided by the operating system). SATP is used only to - encapsulate and encrypt data. - -2.1. Usage scenarions - -2.1.1. Tunneling from unicast hosts over anycast routers to other - unicast hosts - - An example of SATP used to tunnel in a unicast client - anycast - server model - - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint - - Figure 1 - - In this scenario the payload gets encapsuleted into a SATP packet by - a unicast host and gets transmitted to one of the anycast routers. - It than gets decapsulated by the router. This router makes a routing - descision based on the underlying protocol and transmits a new SATP - package to one or more unicast hosts depending on the routing - descition. - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 4] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -2.1.2. Tunneling from unicast hosts to anycast networks - - An example of SATP used to encrypt data between a unicast host and - anycast networks - - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - - - Figure 2 - - When the unicast hosts wants to transmit data to one of the anycast - DNS servers, it encapsulates the data and sends a SATP packet to the - anycast address of the routers. The packet arrives at one of the - routers, gets decapsulated and routed to the DNS server. This method - can be used to tunnel between a clients and networks providing - anycast services. It can also be used the other way to virtually - locate a unicast service within anycasted networks. - -2.1.3. Redundant tunnel connection of 2 networks - - An example of SATP used to connect 2 networks - - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - - - - - -Gsenger Expires December 24, 2007 [Page 5] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - Figure 3 - - Network A has multiple routers, that act as gateway/tunnel endpoints - to another network B. This is done to build a redundant encrypted - tunnel connection between the two networks. All tunnel endpoints of - network A share the same anycast address and all tunnel endpoints of - network B share another anycast address. When a packet from network - A gets transmitted to network B, it first arrives on one of network - A's border routers. Which router is used is determined by network - A's internal routing. This router encapsulates the package and sends - it to the anycast address of the network B routers. The SATP packet - arrives at one of network B's routers and gets decapsulated and - routed to it's destination within network B. - -2.2. Encapsulation - - SATP does not depend on which lower layer protocols is used, but this - section gives an example of how packets could look like. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 6] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - Examples of SATP used with different lower layer and payload - protocols - - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - - Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - - Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - - Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - - Tunneling of IPv6 over IPv4 with RTP payload - - Figure 4 - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 7] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -3. Using SATP on top of IP - -3.1. Fragmentation - - The only way of fully supporting fragmentation would be to - synchronise fragments between all anycast servers. This is - considered to be too much overhead, so there are two non perfect - solutions for these problems. Either fragmentation HAS TO be - disabled or if not all fragments arrive at the same server the ip - datagramm HAS TO be discarded. As routing changes are not expected - to occure very frequently, the encapsulated protocol can do a - retransmission and all fragments will arrive at the new server. - - If the payload type is IP and the ip headers's Don't Fragment (DF) - bit is set, than the DF bit of the outer IP header HAS TO be set as - well. - -3.2. ICMP messages - - ICMP messages MUST be relayed according to rfc2003 section 4 [3]. - This is needed for path MTU detection. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 8] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -4. Protocol specification - -4.1. Header format - - Protocol Format - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | sender ID # | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ + | - | | .... payload ... | | - | |-------------------------------+-------------------------------+ | - | | padding (OPT) | pad count(OPT)| payload type | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ - - Figure 5 - -4.2. sender ID - - The sender ID is a 16 bit unsigned integer. It HAS TO be unique for - every sender sharing the same anycast address - -4.3. sequence number - - The sequence number is a 32 bit unsigned integer in network byte - order. It starts with a random value and is increased by 1 for every - sent packet. After the maximum value, it starts over from 0. This - overrun causes the ROC to be increased. - -4.4. payload - - A packet of the type payload type (e.g. an IP packet). - -4.5. padding (OPTIONAL) - - Padding of max 255 octets. None of the pre-defined encryption - transforms uses any padding; for these, the plaintext and encrypted - payload sizes match exactly. Transforms are based on transforms of - the SRTP protocol and these transforms might use the RTP padding - - - -Gsenger Expires December 24, 2007 [Page 9] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - format, so a RTP like padding is supported. If the padding count - field is present, than the padding count field MUST be set to the - padding lenght. - -4.6. padding count (OPTIONAL) - - The number of octets of the padding field. This field is optional. - It's presence is signaled by the key management and not by this - protocol. If this field isn't present, the padding field MUST NOT be - present as well. - -4.7. payload type field - - The payload type field defines the payload protocol. ETHER TYPE - protocol numbers are used. See IANA assigned ethernet numbers [7] . - The values 0000-05DC are reserverd and MUST NOT be used. - - Some examples for protocol types - - HEX - 0000 Reserved - .... Reserved - 05DC Reserved - 0800 Internet IP (IPv4) - 6558 transparent ethernet bridging - 86DD IPv6 - - Figure 6 - -4.7.1. MKI (OPTIONAL) - - The MKI (Master Key Identifier) is OPTIONAL and of configurable - length. See SRTP Section 3.1 [1] for details - -4.7.2. authentication tag (RECOMMENDED) - - The authentication tag is RECOMMENDED and of configurable length. It - contains a cryptographic checksum of the sender ID, sequence number - and the encrypted portion, but not of the MKI. On sender side - encryption HAS TO be done before calculating the authentication tag. - A receiver HAS TO calculate the authentication tag before decrypting - the encrypted portion. - -4.8. Encryption - - Encryption is done in the same way as for SRTP [1]. This section - will only discuss some small changes that HAVE TO be made. Please - read SRTP RFC3711 section 3-9 [1] for details. - - - -Gsenger Expires December 24, 2007 [Page 10] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - The least significant bits of SSRC are replaced by the sender ID and - the rest is filled with zeros. For the SRTP SEQ the 16 least - significant bits of the SATP sequence number are used and the 16 most - significant bits of the sequence number replace the 16 least - significant bits of the SRTP ROC. - - Difference between SRTP and SATP - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 7 - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 11] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -5. Security Considerations - - As SATP uses the same encrytion technics as SRTP [1], it shares the - same security issues. This section will only discuss some small - changes. Please read SRTP RFC3711 section 9 [1] for details. - -5.1. Replay protection - - Replay protection is done by a replay list. Every anycast receiver - has it's own replay list, which SHOULDN'T be syncronised, because of - massive overhead. This leads to an additional possible attack. A - attacker is able to replay a captured packet once to every anycast - receiver. This attack is considered of be very unlikely, because - multiple attack hosts in different loactions are needed to reach the - seperate anycast receivers and the number of replays is limited to - the count of receivers - 1. Such replays might also happen because - of routing problems, so a payload protocol HAS TO be robust against a - small number of duplicated packages. The window size and position - HAS TO be syncronised between multible anycast receivers to limit - this attack. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 12] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -6. IANA Considerations - - The protocol is intended to be used on top of IP or on top of UDP (to - be compatible with NAT routers), so UDP and IP protocol numbers have - to be assiged by IANA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 13] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -7. References - -7.1. Normative References - - [1] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, March 2004. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Perkins, C., "IP Encapsulation within IP", RFC 2003, - October 1996. - -7.2. Informational References - - [4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, - "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. - - [5] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [6] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 14] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -URIs - - [7] <http://www.iana.org/assignments/ethernet-numbers> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 15] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -Author's Address - - Othmar Gsenger - Puerstingerstr 32 - Saalfelden 5760 - AT - - Phone: - Email: satp@gsenger.com - URI: http://www.gsenger.com/satp/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 24, 2007 [Page 16] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Gsenger Expires December 24, 2007 [Page 17] - diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-00.xml b/draft-gsenger-secure-anycast-tunneling-protocol-00.xml deleted file mode 100644 index cf1f91b..0000000 --- a/draft-gsenger-secure-anycast-tunneling-protocol-00.xml +++ /dev/null @@ -1,294 +0,0 @@ -<?xml version='1.0'?> - <!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd' [ - - <!ENTITY rfc1546 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1546.xml'> - <!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'> - <!ENTITY rfc3068 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml'> - <!ENTITY rfc2784 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2784.xml'> - <!ENTITY rfc2401 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2401.xml'> - <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> - <!ENTITY rfc2003 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2003.xml'> -]> -<?rfc toc='yes'?> - <rfc ipr='full3978' docName='draft-gsenger-secure-anycast-tunneling-protocol-00'> - <front> - <title>secure anycast tunneling protocol (SATP)</title> - - <author initials='O.G.' surname='Gsenger' - fullname='Othmar Gsenger'> - <organization></organization> - - <address> - <postal> - <street>Puerstingerstr 32</street> - <city>Saalfelden</city> - <code>5760</code> - <country>AT</country> - </postal> - - <phone></phone> - <email>satp@gsenger.com</email> - <uri>http://www.gsenger.com/satp/</uri> - </address> - </author> - - <date month='June' year='2007' /> - - <area>General</area> - <workgroup></workgroup> - <keyword>satp</keyword> - <keyword>Internet-Draft</keyword> - <keyword>secure anycast tunneling protocol</keyword> - <keyword>anycast</keyword> - <keyword>tunnel</keyword> - <keyword>secure</keyword> - <keyword>protocol</keyword> - <abstract> - <t>The secure anycast tunneling protocol (SATP) defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It allows tunneling of every ETHER TYPE protocol (ethernet, ip ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It can be used as an encrypted alternative to <xref target="RFC2003">IP Encapsulation within IP</xref> and <xref target="RFC2784">Generic Routing Encapsulation (GRE)</xref>. It supports both anycast receivers and senders. - </t> - </abstract> - </front> - <middle> - <section title='Introduction'> - <t>SATP is a mixture of a generic encapsulation protocol like <xref target="RFC2784">GRE</xref> and a secure tunneling protocol as <xref target="RFC2401">IPsec</xref> in tunnel mode. It can be used to build redundant virtual private network (VPN) connections. It supports peer to peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines a <xref target="RFC1546">Host Anycast Service</xref>. Encryption is done per packet, so the protocol is robust against packet loss and routing changes. - To save some header overhead it uses the encryption techniques of <xref target="RFC3711">SRTP</xref>. - </t> - <section title='Notational Conventions'> - <t>The keywords "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">RFC2119</xref>.</t> - </section> - </section> - <section title="Motivation and usage scenarios"> - <t>This section gives an overview of possible usage scenarios. Please note, that the protocols used in the figures are only examples and that SATP itself does not care about either transport protocols or encapsulated protocols. Routing is not done by SATP and each implemetation MAY choose it's own way of doing this task (e.g. using functions provided by the operating system). SATP is used only to encapsulate and encrypt data.</t> - <section title="Usage scenarions"> - - <section title='Tunneling from unicast hosts over anycast routers to other unicast hosts'> - <figure anchor="tunnel_mode"> - <preamble>An example of SATP used to tunnel in a unicast client - anycast server model</preamble> - <artwork> - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint - </artwork> - </figure> - <t>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing descition.</t> - </section> - - <section title='Tunneling from unicast hosts to anycast networks'> - <figure anchor="open_tunnel_mode"> - <preamble>An example of SATP used to encrypt data between a unicast host and anycast networks</preamble> - <artwork> - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - - </artwork> - </figure> - <t>When the unicast hosts wants to transmit data to one of the anycast DNS servers, it encapsulates the data and sends a SATP packet to the anycast address of the routers. The packet arrives at one of the routers, gets decapsulated and routed to the DNS server. This method can be used to tunnel between a clients and networks providing anycast services. It can also be used the other way to virtually locate a unicast service within anycasted networks.</t> - </section> - <section title='Redundant tunnel connection of 2 networks'> - <figure anchor="connect_networks"> - <preamble>An example of SATP used to connect 2 networks</preamble> - <artwork> - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - - </artwork> - </figure> - - <t>Network A has multiple routers, that act as gateway/tunnel endpoints to another network B. This is done to build a redundant encrypted tunnel connection between the two networks. All tunnel endpoints of network A share the same anycast address and all tunnel endpoints of network B share another anycast address. When a packet from network A gets transmitted to network B, it first arrives on one of network A's border routers. Which router is used is determined by network A's internal routing. This router encapsulates the package and sends it to the anycast address of the network B routers. The SATP packet arrives at one of network B's routers and gets decapsulated and routed to it's destination within network B.</t> - </section> - </section> - <section title="Encapsulation"> - <t>SATP does not depend on which lower layer protocols is used, but this section gives an example of how packets could look like. - </t> - <figure anchor="transport_udp"> - <preamble>Examples of SATP used with different lower layer and payload protocols</preamble> - <artwork> - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - -Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - -Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - -Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - -Tunneling of IPv6 over IPv4 with RTP payload - </artwork> - </figure> - </section> - </section> - <section title="Using SATP on top of IP"> - <section title="Fragmentation"> - <t> - The only way of fully supporting fragmentation would be to synchronise fragments between all anycast servers. This is considered to be too much overhead, so there are two non perfect solutions for these problems. Either fragmentation HAS TO be disabled or if not all fragments arrive at the same server the ip datagramm HAS TO be discarded. As routing changes are not expected to occure very frequently, the encapsulated protocol can do a retransmission and all fragments will arrive at the new server. - </t><t>If the payload type is IP and the ip headers's Don't Fragment (DF) bit is set, than the DF bit of the outer IP header HAS TO be set as well.</t> - </section> - <section title="ICMP messages"> - <t>ICMP messages MUST be relayed according to <xref target="RFC2003">rfc2003 section 4</xref>. This is needed for path MTU detection.</t> - </section> - </section> - <section title="Protocol specification"> - <section title="Header format"> - <figure anchor="prot_header_table"> - <preamble>Protocol Format</preamble> - <artwork> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | sender ID # | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ + | - | | .... payload ... | | - | |-------------------------------+-------------------------------+ | - | | padding (OPT) | pad count(OPT)| payload type | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ -</artwork> -</figure> -<t></t> - </section> - <section title="sender ID"> - <t>The sender ID is a 16 bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address</t> - </section> - <section title="sequence number"> - <t>The sequence number is a 32 bit unsigned integer in network byte order. It starts with a random value and is increased by 1 for every sent packet. After the maximum value, it starts over from 0. This overrun causes the ROC to be increased.</t> - </section> - <section title="payload"> - <t>A packet of the type payload type (e.g. an IP packet).</t> - </section> - <section title="padding (OPTIONAL)"> - <t>Padding of max 255 octets. -None of the pre-defined encryption transforms uses any padding; for - these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding lenght.</t> - </section> - <section title="padding count (OPTIONAL)"> - <t>The number of octets of the padding field. This field is optional. It's presence is signaled by the key management and not by this protocol. If this field isn't present, the padding field MUST NOT be present as well.</t> - </section> - <section title="payload type field"> - <t>The payload type field defines the payload protocol. ETHER TYPE protocol numbers are used. <eref target="http://www.iana.org/assignments/ethernet-numbers">See IANA assigned ethernet numbers</eref> . The values 0000-05DC are reserverd and MUST NOT be used. - <figure anchor="prot_type_table"> - <preamble>Some examples for protocol types</preamble> - <artwork> -HEX -0000 Reserved -.... Reserved -05DC Reserved -0800 Internet IP (IPv4) -6558 transparent ethernet bridging -86DD IPv6 -</artwork> -</figure> - <section title="MKI (OPTIONAL)"> - <t>The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See <xref target="RFC3711">SRTP Section 3.1</xref> for details</t> - </section> - <section title="authentication tag (RECOMMENDED)"> - <t>The authentication tag is RECOMMENDED and of configurable length. It contains a cryptographic checksum of the sender ID, sequence number and the encrypted portion, but not of the MKI. On sender side encryption HAS TO be done before calculating the authentication tag. A receiver HAS TO calculate the authentication tag before decrypting the encrypted portion.</t> - </section> -</t> - </section> - <section title="Encryption"> - <t>Encryption is done in the same way as for <xref target="RFC3711">SRTP</xref>. This section will only discuss some small changes that HAVE TO be made. Please read <xref target="RFC3711">SRTP RFC3711 section 3-9</xref> for details. </t><t>The least significant bits of SSRC are replaced by the sender ID and the rest is filled with zeros. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC.</t> - <figure anchor="srtp_vs_satp"> - <preamble>Difference between SRTP and SATP</preamble> - <artwork> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - </artwork> - </figure> - </section> - </section> - <section title="Security Considerations"> - <t>As SATP uses the same encrytion technics as <xref target="RFC3711">SRTP</xref>, it shares the same security issues. This section will only discuss some small changes. Please read <xref target="RFC3711">SRTP RFC3711 section 9</xref> for details.</t> - <section title="Replay protection"> - <t>Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SHOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast receiver. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack.</t> - </section> - </section> - <section title="IANA Considerations"> - <t>The protocol is intended to be used on top of IP or on top of UDP (to be compatible with NAT routers), so UDP and IP protocol numbers have to be assiged by IANA.</t> - </section> - </middle> - <back> - <references title="Normative References"> - &rfc3711; - &rfc2119; - &rfc2003; - </references> - <references title="Informational References"> - &rfc2784; - &rfc2401; - &rfc1546; - </references> - </back> - </rfc> diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-01.html b/draft-gsenger-secure-anycast-tunneling-protocol-01.html deleted file mode 100644 index 11a369e..0000000 --- a/draft-gsenger-secure-anycast-tunneling-protocol-01.html +++ /dev/null @@ -1,695 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html lang="en"><head><title>secure anycast tunneling protocol (SATP)</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -<meta name="description" content="secure anycast tunneling protocol (SATP)"> -<meta name="keywords" content="satp, Internet-Draft, secure anycast tunneling protocol, anycast, tunnel, secure, protocol"> -<meta name="generator" content="xml2rfc v1.32 (http://xml.resource.org/)"> -<style type='text/css'><!-- - body { - font-family: verdana, charcoal, helvetica, arial, sans-serif; - font-size: small; color: #000; background-color: #FFF; - margin: 2em; - } - h1, h2, h3, h4, h5, h6 { - font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif; - font-weight: bold; font-style: normal; - } - h1 { color: #900; background-color: transparent; text-align: right; } - h3 { color: #333; background-color: transparent; } - - td.RFCbug { - font-size: x-small; text-decoration: none; - width: 30px; height: 30px; padding-top: 2px; - text-align: justify; vertical-align: middle; - background-color: #000; - } - td.RFCbug span.RFC { - font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; - font-weight: bold; color: #666; - } - td.RFCbug span.hotText { - font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; - font-weight: normal; text-align: center; color: #FFF; - } - - table.TOCbug { width: 30px; height: 15px; } - td.TOCbug { - text-align: center; width: 30px; height: 15px; - color: #FFF; background-color: #900; - } - td.TOCbug a { - font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif; - font-weight: bold; font-size: x-small; text-decoration: none; - color: #FFF; background-color: transparent; - } - - td.header { - font-family: arial, helvetica, sans-serif; font-size: x-small; - vertical-align: top; width: 33%; - color: #FFF; background-color: #666; - } - td.author { font-weight: bold; font-size: x-small; margin-left: 4em; } - td.author-text { font-size: x-small; } - - /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ - a.info { - /* This is the key. */ - position: relative; - z-index: 24; - text-decoration: none; - } - a.info:hover { - z-index: 25; - color: #FFF; background-color: #900; - } - a.info span { display: none; } - a.info:hover span.info { - /* The span will display just on :hover state. */ - display: block; - position: absolute; - font-size: smaller; - top: 2em; left: -5em; width: 15em; - padding: 2px; border: 1px solid #333; - color: #900; background-color: #EEE; - text-align: left; - } - - a { font-weight: bold; } - a:link { color: #900; background-color: transparent; } - a:visited { color: #633; background-color: transparent; } - a:active { color: #633; background-color: transparent; } - - p { margin-left: 2em; margin-right: 2em; } - p.copyright { font-size: x-small; } - p.toc { font-size: small; font-weight: bold; margin-left: 3em; } - table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; } - td.toc { font-size: small; font-weight: bold; vertical-align: text-top; } - - ol.text { margin-left: 2em; margin-right: 2em; } - ul.text { margin-left: 2em; margin-right: 2em; } - li { margin-left: 3em; } - - /* RFC-2629 <spanx>s and <artwork>s. */ - em { font-style: italic; } - strong { font-weight: bold; } - dfn { font-weight: bold; font-style: normal; } - cite { font-weight: normal; font-style: normal; } - tt { color: #036; } - tt, pre, pre dfn, pre em, pre cite, pre span { - font-family: "Courier New", Courier, monospace; font-size: small; - } - pre { - text-align: left; padding: 4px; - color: #000; background-color: #CCC; - } - pre dfn { color: #900; } - pre em { color: #66F; background-color: #FFC; font-weight: normal; } - pre .key { color: #33C; font-weight: bold; } - pre .id { color: #900; } - pre .str { color: #000; background-color: #CFF; } - pre .val { color: #066; } - pre .rep { color: #909; } - pre .oth { color: #000; background-color: #FCF; } - pre .err { background-color: #FCC; } - - /* RFC-2629 <texttable>s. */ - table.all, table.full, table.headers, table.none { - font-size: small; text-align: center; border-width: 2px; - vertical-align: top; border-collapse: collapse; - } - table.all, table.full { border-style: solid; border-color: black; } - table.headers, table.none { border-style: none; } - th { - font-weight: bold; border-color: black; - border-width: 2px 2px 3px 2px; - } - table.all th, table.full th { border-style: solid; } - table.headers th { border-style: none none solid none; } - table.none th { border-style: none; } - table.all td { - border-style: solid; border-color: #333; - border-width: 1px 2px; - } - table.full td, table.headers td, table.none td { border-style: none; } - - hr { height: 1px; } - hr.insert { - width: 80%; border-style: none; border-width: 0; - color: #CCC; background-color: #CCC; - } ---></style> -</head> -<body> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> -<tr><td class="header">Network Working Group</td><td class="header">O. Gsenger</td></tr> -<tr><td class="header">Internet-Draft</td><td class="header">January 23, 2008</td></tr> -<tr><td class="header">Expires: July 26, 2008</td><td class="header"> </td></tr> -</table></td></tr></table> -<h1><br />secure anycast tunneling protocol (SATP)<br />draft-gsenger-secure-anycast-tunneling-protocol-01</h1> - -<h3>Status of this Memo</h3> -<p> -By submitting this Internet-Draft, -each author represents that any applicable patent or other IPR claims of which -he or she is aware have been or will be disclosed, -and any of which he or she becomes aware will be disclosed, -in accordance with Section 6 of BCP 79.</p> -<p> -Internet-Drafts are working documents of the Internet Engineering -Task Force (IETF), its areas, and its working groups. -Note that other groups may also distribute working documents as -Internet-Drafts.</p> -<p> -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.”</p> -<p> -The list of current Internet-Drafts can be accessed at -<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p> -<p> -The list of Internet-Draft Shadow Directories can be accessed at -<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p> -<p> -This Internet-Draft will expire on July 26, 2008.</p> - -<h3>Copyright Notice</h3> -<p> -Copyright © The IETF Trust (2008).</p> - -<h3>Abstract</h3> - -<p>The secure anycast tunneling protocol (SATP) defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It allows tunneling of every ETHER TYPE protocol (ethernet, ip ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It can be used as an encrypted alternative to <a class='info' href='#RFC2003'>IP Encapsulation within IP<span> (</span><span class='info'>Perkins, C., “IP Encapsulation within IP,” October 1996.</span><span>)</span></a> [3] and <a class='info' href='#RFC2784'>Generic Routing Encapsulation (GRE)<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.</span><span>)</span></a> [4]. It supports both anycast receivers and senders. - -</p><a name="toc"></a><br /><hr /> -<h3>Table of Contents</h3> -<p class="toc"> -<a href="#anchor1">1.</a> -Introduction<br /> - <a href="#anchor2">1.1.</a> -Notational Conventions<br /> -<a href="#anchor3">2.</a> -Motivation and usage scenarios<br /> - <a href="#anchor4">2.1.</a> -Usage scenarions<br /> - <a href="#anchor5">2.1.1.</a> -Tunneling from unicast hosts over anycast routers to other unicast hosts<br /> - <a href="#anchor6">2.1.2.</a> -Tunneling from unicast hosts to anycast networks<br /> - <a href="#anchor7">2.1.3.</a> -Redundant tunnel connection of 2 networks<br /> - <a href="#anchor8">2.2.</a> -Encapsulation<br /> -<a href="#anchor9">3.</a> -Using SATP on top of IP<br /> - <a href="#anchor10">3.1.</a> -Fragmentation<br /> - <a href="#anchor11">3.2.</a> -ICMP messages<br /> -<a href="#anchor12">4.</a> -Protocol specification<br /> - <a href="#anchor13">4.1.</a> -Header format<br /> - <a href="#anchor14">4.2.</a> -sequence number<br /> - <a href="#anchor15">4.3.</a> -sender ID<br /> - <a href="#anchor16">4.4.</a> -MUX<br /> - <a href="#anchor17">4.5.</a> -payload type field<br /> - <a href="#anchor18">4.6.</a> -payload<br /> - <a href="#anchor19">4.7.</a> -padding (OPTIONAL)<br /> - <a href="#anchor20">4.8.</a> -padding count (OPTIONAL)<br /> - <a href="#anchor21">4.9.</a> -MKI (OPTIONAL)<br /> - <a href="#anchor22">4.10.</a> -authentication tag (RECOMMENDED)<br /> - <a href="#anchor23">4.11.</a> -Encryption<br /> -<a href="#anchor24">5.</a> -Security Considerations<br /> - <a href="#anchor25">5.1.</a> -Replay protection<br /> -<a href="#anchor26">6.</a> -IANA Considerations<br /> -<a href="#rfc.references1">7.</a> -References<br /> - <a href="#rfc.references1">7.1.</a> -Normative References<br /> - <a href="#rfc.references2">7.2.</a> -Informational References<br /> -<a href="#rfc.authors">§</a> -Author's Address<br /> -<a href="#rfc.copyright">§</a> -Intellectual Property and Copyright Statements<br /> -</p> -<br clear="all" /> - -<a name="anchor1"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.1"></a><h3>1. -Introduction</h3> - -<p>SATP is a mixture of a generic encapsulation protocol like <a class='info' href='#RFC2784'>GRE<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.</span><span>)</span></a> [4] and a secure tunneling protocol as <a class='info' href='#RFC2401'>IPsec<span> (</span><span class='info'>Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.</span><span>)</span></a> [5] in tunnel mode. It can be used to build redundant virtual private network (VPN) connections. It supports peer to peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines a <a class='info' href='#RFC1546'>Host Anycast Service<span> (</span><span class='info'>Partridge, C., Mendez, T., and W. Milliken, “Host Anycasting Service,” November 1993.</span><span>)</span></a> [6]. Encryption is done per packet, so the protocol is robust against packet loss and routing changes. - To save some header overhead it uses the encryption techniques of <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1]. - -</p> -<a name="anchor2"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.1.1"></a><h3>1.1. -Notational Conventions</h3> - -<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [2]. -</p> -<a name="anchor3"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2"></a><h3>2. -Motivation and usage scenarios</h3> - -<p>This section gives an overview of possible usage scenarios. Please note, that the protocols used in the figures are only examples and that SATP itself does not care about either transport protocols or encapsulated protocols. Routing is not done by SATP and each implemetation MAY choose it's own way of doing this task (e.g. using functions provided by the operating system). SATP is used only to encapsulate and encrypt data. -</p> -<a name="anchor4"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1"></a><h3>2.1. -Usage scenarions</h3> - -<a name="anchor5"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1.1"></a><h3>2.1.1. -Tunneling from unicast hosts over anycast routers to other unicast hosts</h3> -<br /><hr class="insert" /> -<a name="tunnel_mode"></a> - -<p>An example of SATP used to tunnel in a unicast client - anycast server model -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 1 </b></font><br /></td></tr></table><hr class="insert" /> - -<p>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing descition. -</p> -<a name="anchor6"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1.2"></a><h3>2.1.2. -Tunneling from unicast hosts to anycast networks</h3> -<br /><hr class="insert" /> -<a name="open_tunnel_mode"></a> - -<p>An example of SATP used to encrypt data between a unicast host and anycast networks -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 2 </b></font><br /></td></tr></table><hr class="insert" /> - -<p>When the unicast hosts wants to transmit data to one of the anycast DNS servers, it encapsulates the data and sends a SATP packet to the anycast address of the routers. The packet arrives at one of the routers, gets decapsulated and routed to the DNS server. This method can be used to tunnel between a clients and networks providing anycast services. It can also be used the other way to virtually locate a unicast service within anycasted networks. -</p> -<a name="anchor7"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1.3"></a><h3>2.1.3. -Redundant tunnel connection of 2 networks</h3> -<br /><hr class="insert" /> -<a name="connect_networks"></a> - -<p>An example of SATP used to connect 2 networks -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 3 </b></font><br /></td></tr></table><hr class="insert" /> - -<p>Network A has multiple routers, that act as gateway/tunnel endpoints to another network B. This is done to build a redundant encrypted tunnel connection between the two networks. All tunnel endpoints of network A share the same anycast address and all tunnel endpoints of network B share another anycast address. When a packet from network A gets transmitted to network B, it first arrives on one of network A's border routers. Which router is used is determined by network A's internal routing. This router encapsulates the package and sends it to the anycast address of the network B routers. The SATP packet arrives at one of network B's routers and gets decapsulated and routed to it's destination within network B. -</p> -<a name="anchor8"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.2"></a><h3>2.2. -Encapsulation</h3> - -<p>SATP does not depend on which lower layer protocols is used, but this section gives an example of how packets could look like. - -</p><br /><hr class="insert" /> -<a name="transport_udp"></a> - -<p>Examples of SATP used with different lower layer and payload protocols -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - -Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - -Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - -Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - -Tunneling of IPv6 over IPv4 with RTP payload -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 4 </b></font><br /></td></tr></table><hr class="insert" /> - -<a name="anchor9"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.3"></a><h3>3. -Using SATP on top of IP</h3> - -<a name="anchor10"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.3.1"></a><h3>3.1. -Fragmentation</h3> - -<p> - The only way of fully supporting fragmentation would be to synchronise fragments between all anycast servers. This is considered to be too much overhead, so there are two non perfect solutions for these problems. Either fragmentation HAS TO be disabled or if not all fragments arrive at the same server the ip datagramm HAS TO be discarded. As routing changes are not expected to occure very frequently, the encapsulated protocol can do a retransmission and all fragments will arrive at the new server. - -</p> -<p>If the payload type is IP and the ip headers's Don't Fragment (DF) bit is set, than the DF bit of the outer IP header HAS TO be set as well. -</p> -<a name="anchor11"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.3.2"></a><h3>3.2. -ICMP messages</h3> - -<p>ICMP messages MUST be relayed according to <a class='info' href='#RFC2003'>rfc2003 section 4<span> (</span><span class='info'>Perkins, C., “IP Encapsulation within IP,” October 1996.</span><span>)</span></a> [3]. This is needed for path MTU detection. -</p> -<a name="anchor12"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4"></a><h3>4. -Protocol specification</h3> - -<a name="anchor13"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.1"></a><h3>4.1. -Header format</h3> -<br /><hr class="insert" /> -<a name="prot_header_table"></a> - -<p>Protocol Format -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sender ID | MUX | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | | payload type | | | - | +-------------------------------+ + | - | | .... payload ... | | - | | +-------------------------------+ | - | | | padding (OPT) | pad count(OPT)| | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 5 </b></font><br /></td></tr></table><hr class="insert" /> - -<p> -</p> -<a name="anchor14"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.2"></a><h3>4.2. -sequence number</h3> - -<p>The sequence number is a 32 bit unsigned integer in network byte order. It starts with a random value and is increased by 1 for every sent packet. After the maximum value, it starts over from 0. This overrun causes the ROC to be increased. -</p> -<a name="anchor15"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.3"></a><h3>4.3. -sender ID</h3> - -<p>The sender ID is a 16 bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address -</p> -<a name="anchor16"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.4"></a><h3>4.4. -MUX</h3> - -<p>The MUX (multiplex) field is a 16 bit unsigned integer. It is used to destinguish multible tunnel connections. -</p> -<a name="anchor17"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.5"></a><h3>4.5. -payload type field</h3> - -<p>The payload type field defines the payload protocol. ETHER TYPE protocol numbers are used. <a href='http://www.iana.org/assignments/ethernet-numbers'>See IANA assigned ethernet numbers</a> . The values 0000-05DC are reserverd and MUST NOT be used. - <br /><hr class="insert" /> -<a name="prot_type_table"></a> - -<p>Some examples for protocol types -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> -HEX -0000 Reserved -.... Reserved -05DC Reserved -0800 Internet IP (IPv4) -6558 transparent ethernet bridging -86DD IPv6 -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 6 </b></font><br /></td></tr></table><hr class="insert" /> - - - -<a name="anchor18"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.6"></a><h3>4.6. -payload</h3> - -<p>A packet of the type payload type (e.g. an IP packet). -</p> -<a name="anchor19"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.7"></a><h3>4.7. -padding (OPTIONAL)</h3> - -<p>Padding of max 255 octets. -None of the pre-defined encryption transforms uses any padding; for - these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding lenght. -</p> -<a name="anchor20"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.8"></a><h3>4.8. -padding count (OPTIONAL)</h3> - -<p>The number of octets of the padding field. This field is optional. It's presence is signaled by the key management and not by this protocol. If this field isn't present, the padding field MUST NOT be present as well. -</p> -<a name="anchor21"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.9"></a><h3>4.9. -MKI (OPTIONAL)</h3> - -<p>The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See <a class='info' href='#RFC3711'>SRTP Section 3.1<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1] for details -</p> -<a name="anchor22"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.10"></a><h3>4.10. -authentication tag (RECOMMENDED)</h3> - -<p>The authentication tag is RECOMMENDED and of configurable length. It contains a cryptographic checksum of the sender ID, sequence number and the encrypted portion, but not of the MKI. On sender side encryption HAS TO be done before calculating the authentication tag. A receiver HAS TO calculate the authentication tag before decrypting the encrypted portion. -</p> -<a name="anchor23"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.11"></a><h3>4.11. -Encryption</h3> - -<p>Encryption is done in the same way as for <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1]. This section will only discuss some small changes that HAVE TO be made. Please read <a class='info' href='#RFC3711'>SRTP RFC3711 section 3-9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1] for details. -</p> -<p>The least significant bits of SSRC are replaced by the sender ID and the rest is filled with zeros. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC. -</p><br /><hr class="insert" /> -<a name="srtp_vs_satp"></a> - -<p>Difference between SRTP and SATP -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 7 </b></font><br /></td></tr></table><hr class="insert" /> - -<a name="anchor24"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.5"></a><h3>5. -Security Considerations</h3> - -<p>As SATP uses the same encrytion technics as <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1], it shares the same security issues. This section will only discuss some small changes. Please read <a class='info' href='#RFC3711'>SRTP RFC3711 section 9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1] for details. -</p> -<a name="anchor25"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.5.1"></a><h3>5.1. -Replay protection</h3> - -<p>Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SHOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast receiver. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack. -</p> -<a name="anchor26"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.6"></a><h3>6. -IANA Considerations</h3> - -<p>The protocol is intended to be used on top of IP or on top of UDP (to be compatible with NAT routers), so UDP and IP protocol numbers have to be assiged by IANA. -</p> -<a name="rfc.references"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.7"></a><h3>7. -References</h3> - -<a name="rfc.references1"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>7.1. Normative References</h3> -<table width="99%" border="0"> -<tr><td class="author-text" valign="top"><a name="RFC3711">[1]</a></td> -<td class="author-text">Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “<a href="ftp://ftp.isi.edu/in-notes/rfc3711.txt">The Secure Real-time Transport Protocol (SRTP)</a>,” RFC 3711, March 2004.</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC2119">[2]</a></td> -<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC2003">[3]</a></td> -<td class="author-text"><a href="mailto:perk@watson.ibm.com">Perkins, C.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2003.txt">IP Encapsulation within IP</a>,” RFC 2003, October 1996 (<a href="ftp://ftp.isi.edu/in-notes/rfc2003.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2003.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2003.xml">XML</a>).</td></tr> -</table> - -<a name="rfc.references2"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>7.2. Informational References</h3> -<table width="99%" border="0"> -<tr><td class="author-text" valign="top"><a name="RFC2784">[4]</a></td> -<td class="author-text"><a href="mailto:dino@procket.com">Farinacci, D.</a>, <a href="mailto:tony1@home.net">Li, T.</a>, <a href="mailto:stan_hanks@enron.net">Hanks, S.</a>, <a href="mailto:dmm@cisco.com">Meyer, D.</a>, and <a href="mailto:pst@juniper.net">P. Traina</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2784.txt">Generic Routing Encapsulation (GRE)</a>,” RFC 2784, March 2000.</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC2401">[5]</a></td> -<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>,” RFC 2401, November 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2401.xml">XML</a>).</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC1546">[6]</a></td> -<td class="author-text"><a href="mailto:craig@bbn.com">Partridge, C.</a>, <a href="mailto:tmendez@bbn.com">Mendez, T.</a>, and <a href="mailto:milliken@bbn.com">W. Milliken</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc1546.txt">Host Anycasting Service</a>,” RFC 1546, November 1993.</td></tr> -</table> - -<a name="rfc.authors"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>Author's Address</h3> -<table width="99%" border="0" cellpadding="0" cellspacing="0"> -<tr><td class="author-text"> </td> -<td class="author-text">Othmar Gsenger</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Puerstingerstr 32</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Saalfelden 5760</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">AT</td></tr> -<tr><td class="author" align="right">Phone: </td> -<td class="author-text"></td></tr> -<tr><td class="author" align="right">Email: </td> -<td class="author-text"><a href="mailto:satp@gsenger.com">satp@gsenger.com</a></td></tr> -<tr><td class="author" align="right">URI: </td> -<td class="author-text"><a href="http://www.gsenger.com/satp/">http://www.gsenger.com/satp/</a></td></tr> -</table> -<a name="rfc.copyright"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>Full Copyright Statement</h3> -<p class='copyright'> -Copyright © The IETF Trust (2008).</p> -<p class='copyright'> -This document is subject to the rights, -licenses and restrictions contained in BCP 78, -and except as set forth therein, -the authors retain all their rights.</p> -<p class='copyright'> -This document and the information contained herein are provided -on an “AS IS” basis and THE CONTRIBUTOR, -THE ORGANIZATION HE/SHE REPRESENTS -OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST -AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, -EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT -THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY -IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR -PURPOSE.</p> -<h3>Intellectual Property</h3> -<p class='copyright'> -The IETF takes no position regarding the validity or scope of any -Intellectual Property Rights or other rights that might be claimed -to pertain to the implementation or use of the technology -described in this document or the extent to which any license -under such rights might or might not be available; nor does it -represent that it has made any independent effort to identify any -such rights. -Information on the procedures with respect to -rights in RFC documents can be found in BCP 78 and BCP 79.</p> -<p class='copyright'> -Copies of IPR disclosures made to the IETF Secretariat and any -assurances of licenses to be made available, -or the result of an attempt made to obtain a general license or -permission for the use of such proprietary rights by implementers or -users of this specification can be obtained from the IETF on-line IPR -repository at <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p> -<p class='copyright'> -The IETF invites any interested party to bring to its attention -any copyrights, -patents or patent applications, -or other -proprietary rights that may cover technology that may be required -to implement this standard. -Please address the information to the IETF at <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p> -<h3>Acknowledgment</h3> -<p class='copyright'> -Funding for the RFC Editor function is provided by -the IETF Administrative Support Activity (IASA).</p> -</body></html> diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-01.txt b/draft-gsenger-secure-anycast-tunneling-protocol-01.txt deleted file mode 100644 index 317fb87..0000000 --- a/draft-gsenger-secure-anycast-tunneling-protocol-01.txt +++ /dev/null @@ -1,952 +0,0 @@ - - - -Network Working Group O. Gsenger -Internet-Draft January 23, 2008 -Expires: July 26, 2008 - - - secure anycast tunneling protocol (SATP) - draft-gsenger-secure-anycast-tunneling-protocol-01 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - 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." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 26, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 1] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -Abstract - - The secure anycast tunneling protocol (SATP) defines a protocol used - for communication between any combination of unicast and anycast - tunnel endpoints. It allows tunneling of every ETHER TYPE protocol - (ethernet, ip ...). SATP directly includes cryptography and message - authentication based on the methodes used by SRTP. It can be used as - an encrypted alternative to IP Encapsulation within IP [3] and - Generic Routing Encapsulation (GRE) [4]. It supports both anycast - receivers and senders. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 - 2. Motivation and usage scenarios . . . . . . . . . . . . . . . . 4 - 2.1. Usage scenarions . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.1. Tunneling from unicast hosts over anycast routers - to other unicast hosts . . . . . . . . . . . . . . . . 4 - 2.1.2. Tunneling from unicast hosts to anycast networks . . . 5 - 2.1.3. Redundant tunnel connection of 2 networks . . . . . . 5 - 2.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Using SATP on top of IP . . . . . . . . . . . . . . . . . . . 8 - 3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. ICMP messages . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Protocol specification . . . . . . . . . . . . . . . . . . . . 9 - 4.1. Header format . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2. sequence number . . . . . . . . . . . . . . . . . . . . . 9 - 4.3. sender ID . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.4. MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.5. payload type field . . . . . . . . . . . . . . . . . . . . 10 - 4.6. payload . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.7. padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10 - 4.8. padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 10 - 4.9. MKI (OPTIONAL) . . . . . . . . . . . . . . . . . . . . . . 10 - 4.10. authentication tag (RECOMMENDED) . . . . . . . . . . . . . 10 - 4.11. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 5.1. Replay protection . . . . . . . . . . . . . . . . . . . . 12 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 7.2. Informational References . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Intellectual Property and Copyright Statements . . . . . . . . . . 17 - - - - - -Gsenger Expires July 26, 2008 [Page 2] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -1. Introduction - - SATP is a mixture of a generic encapsulation protocol like GRE [4] - and a secure tunneling protocol as IPsec [5] in tunnel mode. It can - be used to build redundant virtual private network (VPN) connections. - It supports peer to peer tunnels, where tunnel endpoints can be any - combination of unicast, multicast or anycast hosts, so it defines a - Host Anycast Service [6]. Encryption is done per packet, so the - protocol is robust against packet loss and routing changes. To save - some header overhead it uses the encryption techniques of SRTP [1]. - -1.1. Notational Conventions - - The keywords "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 [2]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 3] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -2. Motivation and usage scenarios - - This section gives an overview of possible usage scenarios. Please - note, that the protocols used in the figures are only examples and - that SATP itself does not care about either transport protocols or - encapsulated protocols. Routing is not done by SATP and each - implemetation MAY choose it's own way of doing this task (e.g. using - functions provided by the operating system). SATP is used only to - encapsulate and encrypt data. - -2.1. Usage scenarions - -2.1.1. Tunneling from unicast hosts over anycast routers to other - unicast hosts - - An example of SATP used to tunnel in a unicast client - anycast - server model - - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint - - Figure 1 - - In this scenario the payload gets encapsuleted into a SATP packet by - a unicast host and gets transmitted to one of the anycast routers. - It than gets decapsulated by the router. This router makes a routing - descision based on the underlying protocol and transmits a new SATP - package to one or more unicast hosts depending on the routing - descition. - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 4] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -2.1.2. Tunneling from unicast hosts to anycast networks - - An example of SATP used to encrypt data between a unicast host and - anycast networks - - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - - - Figure 2 - - When the unicast hosts wants to transmit data to one of the anycast - DNS servers, it encapsulates the data and sends a SATP packet to the - anycast address of the routers. The packet arrives at one of the - routers, gets decapsulated and routed to the DNS server. This method - can be used to tunnel between a clients and networks providing - anycast services. It can also be used the other way to virtually - locate a unicast service within anycasted networks. - -2.1.3. Redundant tunnel connection of 2 networks - - An example of SATP used to connect 2 networks - - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - - - - - -Gsenger Expires July 26, 2008 [Page 5] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - - Figure 3 - - Network A has multiple routers, that act as gateway/tunnel endpoints - to another network B. This is done to build a redundant encrypted - tunnel connection between the two networks. All tunnel endpoints of - network A share the same anycast address and all tunnel endpoints of - network B share another anycast address. When a packet from network - A gets transmitted to network B, it first arrives on one of network - A's border routers. Which router is used is determined by network - A's internal routing. This router encapsulates the package and sends - it to the anycast address of the network B routers. The SATP packet - arrives at one of network B's routers and gets decapsulated and - routed to it's destination within network B. - -2.2. Encapsulation - - SATP does not depend on which lower layer protocols is used, but this - section gives an example of how packets could look like. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 6] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - - Examples of SATP used with different lower layer and payload - protocols - - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - - Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - - Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - - Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - - Tunneling of IPv6 over IPv4 with RTP payload - - Figure 4 - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 7] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -3. Using SATP on top of IP - -3.1. Fragmentation - - The only way of fully supporting fragmentation would be to - synchronise fragments between all anycast servers. This is - considered to be too much overhead, so there are two non perfect - solutions for these problems. Either fragmentation HAS TO be - disabled or if not all fragments arrive at the same server the ip - datagramm HAS TO be discarded. As routing changes are not expected - to occure very frequently, the encapsulated protocol can do a - retransmission and all fragments will arrive at the new server. - - If the payload type is IP and the ip headers's Don't Fragment (DF) - bit is set, than the DF bit of the outer IP header HAS TO be set as - well. - -3.2. ICMP messages - - ICMP messages MUST be relayed according to rfc2003 section 4 [3]. - This is needed for path MTU detection. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 8] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -4. Protocol specification - -4.1. Header format - - Protocol Format - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sender ID | MUX | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | | payload type | | | - | +-------------------------------+ + | - | | .... payload ... | | - | | +-------------------------------+ | - | | | padding (OPT) | pad count(OPT)| | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ - - Figure 5 - -4.2. sequence number - - The sequence number is a 32 bit unsigned integer in network byte - order. It starts with a random value and is increased by 1 for every - sent packet. After the maximum value, it starts over from 0. This - overrun causes the ROC to be increased. - -4.3. sender ID - - The sender ID is a 16 bit unsigned integer. It HAS TO be unique for - every sender sharing the same anycast address - -4.4. MUX - - The MUX (multiplex) field is a 16 bit unsigned integer. It is used - to destinguish multible tunnel connections. - - - - - - - -Gsenger Expires July 26, 2008 [Page 9] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -4.5. payload type field - - The payload type field defines the payload protocol. ETHER TYPE - protocol numbers are used. See IANA assigned ethernet numbers [7] . - The values 0000-05DC are reserverd and MUST NOT be used. - - Some examples for protocol types - - HEX - 0000 Reserved - .... Reserved - 05DC Reserved - 0800 Internet IP (IPv4) - 6558 transparent ethernet bridging - 86DD IPv6 - - Figure 6 - -4.6. payload - - A packet of the type payload type (e.g. an IP packet). - -4.7. padding (OPTIONAL) - - Padding of max 255 octets. None of the pre-defined encryption - transforms uses any padding; for these, the plaintext and encrypted - payload sizes match exactly. Transforms are based on transforms of - the SRTP protocol and these transforms might use the RTP padding - format, so a RTP like padding is supported. If the padding count - field is present, than the padding count field MUST be set to the - padding lenght. - -4.8. padding count (OPTIONAL) - - The number of octets of the padding field. This field is optional. - It's presence is signaled by the key management and not by this - protocol. If this field isn't present, the padding field MUST NOT be - present as well. - -4.9. MKI (OPTIONAL) - - The MKI (Master Key Identifier) is OPTIONAL and of configurable - length. See SRTP Section 3.1 [1] for details - -4.10. authentication tag (RECOMMENDED) - - The authentication tag is RECOMMENDED and of configurable length. It - contains a cryptographic checksum of the sender ID, sequence number - - - -Gsenger Expires July 26, 2008 [Page 10] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - - and the encrypted portion, but not of the MKI. On sender side - encryption HAS TO be done before calculating the authentication tag. - A receiver HAS TO calculate the authentication tag before decrypting - the encrypted portion. - -4.11. Encryption - - Encryption is done in the same way as for SRTP [1]. This section - will only discuss some small changes that HAVE TO be made. Please - read SRTP RFC3711 section 3-9 [1] for details. - - The least significant bits of SSRC are replaced by the sender ID and - the rest is filled with zeros. For the SRTP SEQ the 16 least - significant bits of the SATP sequence number are used and the 16 most - significant bits of the sequence number replace the 16 least - significant bits of the SRTP ROC. - - Difference between SRTP and SATP - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 7 - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 11] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -5. Security Considerations - - As SATP uses the same encrytion technics as SRTP [1], it shares the - same security issues. This section will only discuss some small - changes. Please read SRTP RFC3711 section 9 [1] for details. - -5.1. Replay protection - - Replay protection is done by a replay list. Every anycast receiver - has it's own replay list, which SHOULDN'T be syncronised, because of - massive overhead. This leads to an additional possible attack. A - attacker is able to replay a captured packet once to every anycast - receiver. This attack is considered of be very unlikely, because - multiple attack hosts in different loactions are needed to reach the - seperate anycast receivers and the number of replays is limited to - the count of receivers - 1. Such replays might also happen because - of routing problems, so a payload protocol HAS TO be robust against a - small number of duplicated packages. The window size and position - HAS TO be syncronised between multible anycast receivers to limit - this attack. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 12] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -6. IANA Considerations - - The protocol is intended to be used on top of IP or on top of UDP (to - be compatible with NAT routers), so UDP and IP protocol numbers have - to be assiged by IANA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 13] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -7. References - -7.1. Normative References - - [1] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, March 2004. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Perkins, C., "IP Encapsulation within IP", RFC 2003, - October 1996. - -7.2. Informational References - - [4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, - "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. - - [5] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [6] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 14] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -URIs - - [7] <http://www.iana.org/assignments/ethernet-numbers> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 15] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -Author's Address - - Othmar Gsenger - Puerstingerstr 32 - Saalfelden 5760 - AT - - Phone: - Email: satp@gsenger.com - URI: http://www.gsenger.com/satp/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires July 26, 2008 [Page 16] - -Internet-Draft secure anycast tunneling protocol (SATP) January 2008 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Gsenger Expires July 26, 2008 [Page 17] - diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-01.xml b/draft-gsenger-secure-anycast-tunneling-protocol-01.xml deleted file mode 100644 index 1f41079..0000000 --- a/draft-gsenger-secure-anycast-tunneling-protocol-01.xml +++ /dev/null @@ -1,299 +0,0 @@ -<?xml version='1.0'?> - <!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd' [ - - <!ENTITY rfc1546 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1546.xml'> - <!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'> - <!ENTITY rfc3068 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml'> - <!ENTITY rfc2784 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2784.xml'> - <!ENTITY rfc2401 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2401.xml'> - <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> - <!ENTITY rfc2003 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2003.xml'> -]> -<?rfc toc='yes'?> - <rfc ipr='full3978' docName='draft-gsenger-secure-anycast-tunneling-protocol-01'> - <front> - <title>secure anycast tunneling protocol (SATP)</title> - - <author initials='O.G.' surname='Gsenger' - fullname='Othmar Gsenger'> - <organization></organization> - - <address> - <postal> - <street>Puerstingerstr 32</street> - <city>Saalfelden</city> - <code>5760</code> - <country>AT</country> - </postal> - - <phone></phone> - <email>satp@gsenger.com</email> - <uri>http://www.gsenger.com/satp/</uri> - </address> - </author> - - <date month='January' year='2008' /> - - <area>General</area> - <workgroup></workgroup> - <keyword>satp</keyword> - <keyword>Internet-Draft</keyword> - <keyword>secure anycast tunneling protocol</keyword> - <keyword>anycast</keyword> - <keyword>tunnel</keyword> - <keyword>secure</keyword> - <keyword>protocol</keyword> - <abstract> - <t>The secure anycast tunneling protocol (SATP) defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It allows tunneling of every ETHER TYPE protocol (ethernet, ip ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It can be used as an encrypted alternative to <xref target="RFC2003">IP Encapsulation within IP</xref> and <xref target="RFC2784">Generic Routing Encapsulation (GRE)</xref>. It supports both anycast receivers and senders. - </t> - </abstract> - </front> - <middle> - <section title='Introduction'> - <t>SATP is a mixture of a generic encapsulation protocol like <xref target="RFC2784">GRE</xref> and a secure tunneling protocol as <xref target="RFC2401">IPsec</xref> in tunnel mode. It can be used to build redundant virtual private network (VPN) connections. It supports peer to peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines a <xref target="RFC1546">Host Anycast Service</xref>. Encryption is done per packet, so the protocol is robust against packet loss and routing changes. - To save some header overhead it uses the encryption techniques of <xref target="RFC3711">SRTP</xref>. - </t> - <section title='Notational Conventions'> - <t>The keywords "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">RFC2119</xref>.</t> - </section> - </section> - <section title="Motivation and usage scenarios"> - <t>This section gives an overview of possible usage scenarios. Please note, that the protocols used in the figures are only examples and that SATP itself does not care about either transport protocols or encapsulated protocols. Routing is not done by SATP and each implemetation MAY choose it's own way of doing this task (e.g. using functions provided by the operating system). SATP is used only to encapsulate and encrypt data.</t> - <section title="Usage scenarions"> - - <section title='Tunneling from unicast hosts over anycast routers to other unicast hosts'> - <figure anchor="tunnel_mode"> - <preamble>An example of SATP used to tunnel in a unicast client - anycast server model</preamble> - <artwork> - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint - </artwork> - </figure> - <t>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing descition.</t> - </section> - - <section title='Tunneling from unicast hosts to anycast networks'> - <figure anchor="open_tunnel_mode"> - <preamble>An example of SATP used to encrypt data between a unicast host and anycast networks</preamble> - <artwork> - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - - </artwork> - </figure> - <t>When the unicast hosts wants to transmit data to one of the anycast DNS servers, it encapsulates the data and sends a SATP packet to the anycast address of the routers. The packet arrives at one of the routers, gets decapsulated and routed to the DNS server. This method can be used to tunnel between a clients and networks providing anycast services. It can also be used the other way to virtually locate a unicast service within anycasted networks.</t> - </section> - <section title='Redundant tunnel connection of 2 networks'> - <figure anchor="connect_networks"> - <preamble>An example of SATP used to connect 2 networks</preamble> - <artwork> - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - - </artwork> - </figure> - - <t>Network A has multiple routers, that act as gateway/tunnel endpoints to another network B. This is done to build a redundant encrypted tunnel connection between the two networks. All tunnel endpoints of network A share the same anycast address and all tunnel endpoints of network B share another anycast address. When a packet from network A gets transmitted to network B, it first arrives on one of network A's border routers. Which router is used is determined by network A's internal routing. This router encapsulates the package and sends it to the anycast address of the network B routers. The SATP packet arrives at one of network B's routers and gets decapsulated and routed to it's destination within network B.</t> - </section> - </section> - <section title="Encapsulation"> - <t>SATP does not depend on which lower layer protocols is used, but this section gives an example of how packets could look like. - </t> - <figure anchor="transport_udp"> - <preamble>Examples of SATP used with different lower layer and payload protocols</preamble> - <artwork> - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - -Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - -Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - -Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - -Tunneling of IPv6 over IPv4 with RTP payload - </artwork> - </figure> - </section> - </section> - <section title="Using SATP on top of IP"> - <section title="Fragmentation"> - <t> - The only way of fully supporting fragmentation would be to synchronise fragments between all anycast servers. This is considered to be too much overhead, so there are two non perfect solutions for these problems. Either fragmentation HAS TO be disabled or if not all fragments arrive at the same server the ip datagramm HAS TO be discarded. As routing changes are not expected to occure very frequently, the encapsulated protocol can do a retransmission and all fragments will arrive at the new server. - </t><t>If the payload type is IP and the ip headers's Don't Fragment (DF) bit is set, than the DF bit of the outer IP header HAS TO be set as well.</t> - </section> - <section title="ICMP messages"> - <t>ICMP messages MUST be relayed according to <xref target="RFC2003">rfc2003 section 4</xref>. This is needed for path MTU detection.</t> - </section> - </section> - <section title="Protocol specification"> - <section title="Header format"> - <figure anchor="prot_header_table"> - <preamble>Protocol Format</preamble> - <artwork> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sender ID | MUX | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | | payload type | | | - | +-------------------------------+ + | - | | .... payload ... | | - | | +-------------------------------+ | - | | | padding (OPT) | pad count(OPT)| | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ -</artwork> -</figure> -<t></t> - </section> - <section title="sequence number"> - <t>The sequence number is a 32 bit unsigned integer in network byte order. It starts with a random value and is increased by 1 for every sent packet. After the maximum value, it starts over from 0. This overrun causes the ROC to be increased.</t> - </section> - <section title="sender ID"> - <t>The sender ID is a 16 bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address</t> - </section> - <section title="MUX"> - <t>The MUX (multiplex) field is a 16 bit unsigned integer. It is used to destinguish multible tunnel connections.</t> - </section> - <section title="payload type field"> - <t>The payload type field defines the payload protocol. ETHER TYPE protocol numbers are used. <eref target="http://www.iana.org/assignments/ethernet-numbers">See IANA assigned ethernet numbers</eref> . The values 0000-05DC are reserverd and MUST NOT be used. - <figure anchor="prot_type_table"> - <preamble>Some examples for protocol types</preamble> - <artwork> -HEX -0000 Reserved -.... Reserved -05DC Reserved -0800 Internet IP (IPv4) -6558 transparent ethernet bridging -86DD IPv6 -</artwork> -</figure> -</t> - </section> - <section title="payload"> - <t>A packet of the type payload type (e.g. an IP packet).</t> - </section> - <section title="padding (OPTIONAL)"> - <t>Padding of max 255 octets. -None of the pre-defined encryption transforms uses any padding; for - these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding lenght.</t> - </section> - <section title="padding count (OPTIONAL)"> - <t>The number of octets of the padding field. This field is optional. It's presence is signaled by the key management and not by this protocol. If this field isn't present, the padding field MUST NOT be present as well.</t> - </section> - <section title="MKI (OPTIONAL)"> - <t>The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See <xref target="RFC3711">SRTP Section 3.1</xref> for details</t> - </section> - <section title="authentication tag (RECOMMENDED)"> - <t>The authentication tag is RECOMMENDED and of configurable length. It contains a cryptographic checksum of the sender ID, sequence number and the encrypted portion, but not of the MKI. On sender side encryption HAS TO be done before calculating the authentication tag. A receiver HAS TO calculate the authentication tag before decrypting the encrypted portion.</t> - </section> - <section title="Encryption"> - <t>Encryption is done in the same way as for <xref target="RFC3711">SRTP</xref>. This section will only discuss some small changes that HAVE TO be made. Please read <xref target="RFC3711">SRTP RFC3711 section 3-9</xref> for details. </t><t>The least significant bits of SSRC are replaced by the sender ID and the rest is filled with zeros. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC.</t> - <figure anchor="srtp_vs_satp"> - <preamble>Difference between SRTP and SATP</preamble> - <artwork> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - </artwork> - </figure> - </section> - </section> - <section title="Security Considerations"> - <t>As SATP uses the same encrytion technics as <xref target="RFC3711">SRTP</xref>, it shares the same security issues. This section will only discuss some small changes. Please read <xref target="RFC3711">SRTP RFC3711 section 9</xref> for details.</t> - <section title="Replay protection"> - <t>Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SHOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast receiver. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack.</t> - </section> - </section> - <section title="IANA Considerations"> - <t>The protocol is intended to be used on top of IP or on top of UDP (to be compatible with NAT routers), so UDP and IP protocol numbers have to be assiged by IANA.</t> - </section> - </middle> - <back> - <references title="Normative References"> - &rfc3711; - &rfc2119; - &rfc2003; - </references> - <references title="Informational References"> - &rfc2784; - &rfc2401; - &rfc1546; - </references> - </back> - </rfc> diff --git a/ice-ietf-tutorial.pdf b/ice-ietf-tutorial.pdf Binary files differdeleted file mode 100644 index 4e10ab6..0000000 --- a/ice-ietf-tutorial.pdf +++ /dev/null diff --git a/internet-draft-satp.html b/internet-draft-satp.html deleted file mode 100644 index 6c6a5c6..0000000 --- a/internet-draft-satp.html +++ /dev/null @@ -1,686 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html lang="en"><head><title>secure anycast tunneling protocol (SATP)</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -<meta name="description" content="secure anycast tunneling protocol (SATP)"> -<meta name="keywords" content="satp, Internet-Draft, secure anycast tunneling protocol, anycast, tunnel, secure, protocol"> -<meta name="generator" content="xml2rfc v1.32 (http://xml.resource.org/)"> -<style type='text/css'><!-- - body { - font-family: verdana, charcoal, helvetica, arial, sans-serif; - font-size: small; color: #000; background-color: #FFF; - margin: 2em; - } - h1, h2, h3, h4, h5, h6 { - font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif; - font-weight: bold; font-style: normal; - } - h1 { color: #900; background-color: transparent; text-align: right; } - h3 { color: #333; background-color: transparent; } - - td.RFCbug { - font-size: x-small; text-decoration: none; - width: 30px; height: 30px; padding-top: 2px; - text-align: justify; vertical-align: middle; - background-color: #000; - } - td.RFCbug span.RFC { - font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; - font-weight: bold; color: #666; - } - td.RFCbug span.hotText { - font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; - font-weight: normal; text-align: center; color: #FFF; - } - - table.TOCbug { width: 30px; height: 15px; } - td.TOCbug { - text-align: center; width: 30px; height: 15px; - color: #FFF; background-color: #900; - } - td.TOCbug a { - font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif; - font-weight: bold; font-size: x-small; text-decoration: none; - color: #FFF; background-color: transparent; - } - - td.header { - font-family: arial, helvetica, sans-serif; font-size: x-small; - vertical-align: top; width: 33%; - color: #FFF; background-color: #666; - } - td.author { font-weight: bold; font-size: x-small; margin-left: 4em; } - td.author-text { font-size: x-small; } - - /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ - a.info { - /* This is the key. */ - position: relative; - z-index: 24; - text-decoration: none; - } - a.info:hover { - z-index: 25; - color: #FFF; background-color: #900; - } - a.info span { display: none; } - a.info:hover span.info { - /* The span will display just on :hover state. */ - display: block; - position: absolute; - font-size: smaller; - top: 2em; left: -5em; width: 15em; - padding: 2px; border: 1px solid #333; - color: #900; background-color: #EEE; - text-align: left; - } - - a { font-weight: bold; } - a:link { color: #900; background-color: transparent; } - a:visited { color: #633; background-color: transparent; } - a:active { color: #633; background-color: transparent; } - - p { margin-left: 2em; margin-right: 2em; } - p.copyright { font-size: x-small; } - p.toc { font-size: small; font-weight: bold; margin-left: 3em; } - table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; } - td.toc { font-size: small; font-weight: bold; vertical-align: text-top; } - - ol.text { margin-left: 2em; margin-right: 2em; } - ul.text { margin-left: 2em; margin-right: 2em; } - li { margin-left: 3em; } - - /* RFC-2629 <spanx>s and <artwork>s. */ - em { font-style: italic; } - strong { font-weight: bold; } - dfn { font-weight: bold; font-style: normal; } - cite { font-weight: normal; font-style: normal; } - tt { color: #036; } - tt, pre, pre dfn, pre em, pre cite, pre span { - font-family: "Courier New", Courier, monospace; font-size: small; - } - pre { - text-align: left; padding: 4px; - color: #000; background-color: #CCC; - } - pre dfn { color: #900; } - pre em { color: #66F; background-color: #FFC; font-weight: normal; } - pre .key { color: #33C; font-weight: bold; } - pre .id { color: #900; } - pre .str { color: #000; background-color: #CFF; } - pre .val { color: #066; } - pre .rep { color: #909; } - pre .oth { color: #000; background-color: #FCF; } - pre .err { background-color: #FCC; } - - /* RFC-2629 <texttable>s. */ - table.all, table.full, table.headers, table.none { - font-size: small; text-align: center; border-width: 2px; - vertical-align: top; border-collapse: collapse; - } - table.all, table.full { border-style: solid; border-color: black; } - table.headers, table.none { border-style: none; } - th { - font-weight: bold; border-color: black; - border-width: 2px 2px 3px 2px; - } - table.all th, table.full th { border-style: solid; } - table.headers th { border-style: none none solid none; } - table.none th { border-style: none; } - table.all td { - border-style: solid; border-color: #333; - border-width: 1px 2px; - } - table.full td, table.headers td, table.none td { border-style: none; } - - hr { height: 1px; } - hr.insert { - width: 80%; border-style: none; border-width: 0; - color: #CCC; background-color: #CCC; - } ---></style> -</head> -<body> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> -<tr><td class="header">Network Working Group</td><td class="header">O. Gsenger</td></tr> -<tr><td class="header">Internet-Draft</td><td class="header">June 21, 2007</td></tr> -<tr><td class="header">Expires: December 23, 2007</td><td class="header"> </td></tr> -</table></td></tr></table> -<h1><br />secure anycast tunneling protocol (SATP)<br />draft-gsenger-secure-anycast-tunneling-protocol-00</h1> - -<h3>Status of this Memo</h3> -<p> -By submitting this Internet-Draft, -each author represents that any applicable patent or other IPR claims of which -he or she is aware have been or will be disclosed, -and any of which he or she becomes aware will be disclosed, -in accordance with Section 6 of BCP 79.</p> -<p> -Internet-Drafts are working documents of the Internet Engineering -Task Force (IETF), its areas, and its working groups. -Note that other groups may also distribute working documents as -Internet-Drafts.</p> -<p> -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.”</p> -<p> -The list of current Internet-Drafts can be accessed at -<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p> -<p> -The list of Internet-Draft Shadow Directories can be accessed at -<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p> -<p> -This Internet-Draft will expire on December 23, 2007.</p> - -<h3>Copyright Notice</h3> -<p> -Copyright © The IETF Trust (2007).</p> - -<h3>Abstract</h3> - -<p>The secure anycast tunneling protocol (SATP) defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It allows tunneling of every ETHER TYPE protocol (ethernet, ip ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It can be used as an encrypted alternative to <a class='info' href='#RFC2003'>IP Encapsulation within IP<span> (</span><span class='info'>Perkins, C., “IP Encapsulation within IP,” October 1996.</span><span>)</span></a> [3] and <a class='info' href='#RFC2784'>Generic Routing Encapsulation (GRE)<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.</span><span>)</span></a> [4]. It supports both anycast receivers and senders. - -</p><a name="toc"></a><br /><hr /> -<h3>Table of Contents</h3> -<p class="toc"> -<a href="#anchor1">1.</a> -Introduction<br /> - <a href="#anchor2">1.1.</a> -Notational Conventions<br /> -<a href="#anchor3">2.</a> -Motivation and usage scenarios<br /> - <a href="#anchor4">2.1.</a> -Usage scenarions<br /> - <a href="#anchor5">2.1.1.</a> -Tunneling from unicast hosts over anycast routers to other unicast hosts<br /> - <a href="#anchor6">2.1.2.</a> -Tunneling from unicast hosts to anycast networks<br /> - <a href="#anchor7">2.1.3.</a> -Redundant tunnel connection of 2 networks<br /> - <a href="#anchor8">2.2.</a> -Encapsulation<br /> -<a href="#anchor9">3.</a> -Using SATP on top of IP<br /> - <a href="#anchor10">3.1.</a> -Fragmentation<br /> - <a href="#anchor11">3.2.</a> -ICMP messages<br /> -<a href="#anchor12">4.</a> -Protocol specification<br /> - <a href="#anchor13">4.1.</a> -Header format<br /> - <a href="#anchor14">4.2.</a> -sender ID<br /> - <a href="#anchor15">4.3.</a> -sequence number<br /> - <a href="#anchor16">4.4.</a> -payload<br /> - <a href="#anchor17">4.5.</a> -padding (OPTIONAL)<br /> - <a href="#anchor18">4.6.</a> -padding count (OPTIONAL)<br /> - <a href="#anchor19">4.7.</a> -payload type field<br /> - <a href="#anchor20">4.7.1.</a> -MKI (OPTIONAL)<br /> - <a href="#anchor21">4.7.2.</a> -authentication tag (RECOMMENDED)<br /> - <a href="#anchor22">4.8.</a> -Encryption<br /> -<a href="#anchor23">5.</a> -Security Considerations<br /> - <a href="#anchor24">5.1.</a> -Replay protection<br /> -<a href="#anchor25">6.</a> -IANA Considerations<br /> -<a href="#rfc.references1">7.</a> -References<br /> - <a href="#rfc.references1">7.1.</a> -Normative References<br /> - <a href="#rfc.references2">7.2.</a> -Informational References<br /> -<a href="#rfc.authors">§</a> -Author's Address<br /> -<a href="#rfc.copyright">§</a> -Intellectual Property and Copyright Statements<br /> -</p> -<br clear="all" /> - -<a name="anchor1"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.1"></a><h3>1. -Introduction</h3> - -<p>SATP is a mixture of a generic encapsulation protocol like <a class='info' href='#RFC2784'>GRE<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.</span><span>)</span></a> [4] and a secure tunneling protocol as <a class='info' href='#RFC2401'>IPsec<span> (</span><span class='info'>Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.</span><span>)</span></a> [5] in tunnel mode. It can be used to build redundant virtual private network (VPN) connections. It supports peer to peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines a <a class='info' href='#RFC1546'>Host Anycast Service<span> (</span><span class='info'>Partridge, C., Mendez, T., and W. Milliken, “Host Anycasting Service,” November 1993.</span><span>)</span></a> [6]. Encryption is done per packet, so the protocol is robust against packet loss and routing changes. - To save some header overhead it uses the encryption techniques of <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1]. - -</p> -<a name="anchor2"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.1.1"></a><h3>1.1. -Notational Conventions</h3> - -<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [2]. -</p> -<a name="anchor3"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2"></a><h3>2. -Motivation and usage scenarios</h3> - -<p>This section gives an overview of possible usage scenarios. Please note, that the protocols used in the figures are only examples and that SATP itself does not care about either transport protocols or encapsulated protocols. Routing is not done by SATP and each implemetation MAY choose it's own way of doing this task (e.g. using functions provided by the operating system). SATP is used only to encapsulate and encrypt data. -</p> -<a name="anchor4"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1"></a><h3>2.1. -Usage scenarions</h3> - -<a name="anchor5"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1.1"></a><h3>2.1.1. -Tunneling from unicast hosts over anycast routers to other unicast hosts</h3> -<br /><hr class="insert" /> -<a name="tunnel_mode"></a> - -<p>An example of SATP used to tunnel in a unicast client - anycast server model -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 1 </b></font><br /></td></tr></table><hr class="insert" /> - -<p>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing descition. -</p> -<a name="anchor6"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1.2"></a><h3>2.1.2. -Tunneling from unicast hosts to anycast networks</h3> -<br /><hr class="insert" /> -<a name="open_tunnel_mode"></a> - -<p>An example of SATP used to encrypt data between a unicast host and anycast networks -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 2 </b></font><br /></td></tr></table><hr class="insert" /> - -<p>When the unicast hosts wants to transmit data to one of the anycast DNS servers, it encapsulates the data and sends a SATP packet to the anycast address of the routers. The packet arrives at one of the routers, gets decapsulated and routed to the DNS server. This method can be used to tunnel between a clients and networks providing anycast services. It can also be used the other way to virtually locate a unicast service within anycasted networks. -</p> -<a name="anchor7"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.1.3"></a><h3>2.1.3. -Redundant tunnel connection of 2 networks</h3> -<br /><hr class="insert" /> -<a name="connect_networks"></a> - -<p>An example of SATP used to connect 2 networks -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 3 </b></font><br /></td></tr></table><hr class="insert" /> - -<p>Network A has multiple routers, that act as gateway/tunnel endpoints to another network B. This is done to build a redundant encrypted tunnel connection between the two networks. All tunnel endpoints of network A share the same anycast address and all tunnel endpoints of network B share another anycast address. When a packet from network A gets transmitted to network B, it first arrives on one of network A's border routers. Which router is used is determined by network A's internal routing. This router encapsulates the package and sends it to the anycast address of the network B routers. The SATP packet arrives at one of network B's routers and gets decapsulated and routed to it's destination within network B. -</p> -<a name="anchor8"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.2.2"></a><h3>2.2. -Encapsulation</h3> - -<p>SATP does not depend on which lower layer protocols is used, but this section gives an example of how packets could look like. - -</p><br /><hr class="insert" /> -<a name="transport_udp"></a> - -<p>Examples of SATP used with different lower layer and payload protocols -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - -Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - -Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - -Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - -Tunneling of IPv6 over IPv4 with RTP payload -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 4 </b></font><br /></td></tr></table><hr class="insert" /> - -<a name="anchor9"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.3"></a><h3>3. -Using SATP on top of IP</h3> - -<a name="anchor10"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.3.1"></a><h3>3.1. -Fragmentation</h3> - -<p> - The only way of fully supporting fragmentation would be to synchronise fragments between all anycast servers. This is considered to be too much overhead, so there are two non perfect solutions for these problems. Either fragmentation HAS TO be disabled or if not all fragments arrive at the same server the ip datagramm HAS TO be discarded. As routing changes are not expected to occure very frequently, the encapsulated protocol can do a retransmission and all fragments will arrive at the new server. - -</p> -<p>If the payload type is IP and the ip headers's Don't Fragment (DF) bit is set, than the DF bit of the outer IP header HAS TO be set as well. -</p> -<a name="anchor11"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.3.2"></a><h3>3.2. -ICMP messages</h3> - -<p>ICMP messages MUST be relayed according to <a class='info' href='#RFC2003'>rfc2003 section 4<span> (</span><span class='info'>Perkins, C., “IP Encapsulation within IP,” October 1996.</span><span>)</span></a> [3]. This is needed for path MTU detection. -</p> -<a name="anchor12"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4"></a><h3>4. -Protocol specification</h3> - -<a name="anchor13"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.1"></a><h3>4.1. -Header format</h3> -<br /><hr class="insert" /> -<a name="prot_header_table"></a> - -<p>Protocol Format -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | sender ID # | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ + | - | | .... payload ... | | - | |-------------------------------+-------------------------------+ | - | | padding (OPT) | pad count(OPT)| payload type | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 5 </b></font><br /></td></tr></table><hr class="insert" /> - -<p> -</p> -<a name="anchor14"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.2"></a><h3>4.2. -sender ID</h3> - -<p>The sender ID is a 16 bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address -</p> -<a name="anchor15"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.3"></a><h3>4.3. -sequence number</h3> - -<p>The sequence number is a 32 bit unsigned integer in network byte order. It starts with a random value and is increased by 1 for every sent packet. After the maximum value, it starts over from 0. This overrun causes the ROC to be increased. -</p> -<a name="anchor16"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.4"></a><h3>4.4. -payload</h3> - -<p>A packet of the type payload type (e.g. an IP packet). -</p> -<a name="anchor17"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.5"></a><h3>4.5. -padding (OPTIONAL)</h3> - -<p>Padding of max 255 octets. -None of the pre-defined encryption transforms uses any padding; for - these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding lenght. -</p> -<a name="anchor18"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.6"></a><h3>4.6. -padding count (OPTIONAL)</h3> - -<p>The number of octets of the padding field. This field is optional. It's presence is signaled by the key management and not by this protocol. If this field isn't present, the padding field MUST NOT be present as well. -</p> -<a name="anchor19"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.7"></a><h3>4.7. -payload type field</h3> - -<p>The payload type field defines the payload protocol. ETHER TYPE protocol numbers are used. <a href='http://www.iana.org/assignments/ethernet-numbers'>See IANA assigned ethernet numbers</a> . The values 0000-05DC are reserverd and MUST NOT be used. - <br /><hr class="insert" /> -<a name="prot_type_table"></a> - -<p>Some examples for protocol types -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> -HEX -0000 Reserved -.... Reserved -05DC Reserved -0800 Internet IP (IPv4) -6558 transparent ethernet bridging -86DD IPv6 -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 6 </b></font><br /></td></tr></table><hr class="insert" /> - - -<a name="anchor20"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.7.1"></a><h3>4.7.1. -MKI (OPTIONAL)</h3> - -<p>The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See <a class='info' href='#RFC3711'>SRTP Section 3.1<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1] for details -</p> - -<a name="anchor21"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.7.2"></a><h3>4.7.2. -authentication tag (RECOMMENDED)</h3> - -<p>The authentication tag is RECOMMENDED and of configurable length. It contains a cryptographic checksum of the sender ID, sequence number and the encrypted portion, but not of the MKI. On sender side encryption HAS TO be done before calculating the authentication tag. A receiver HAS TO calculate the authentication tag before decrypting the encrypted portion. -</p> - - -<a name="anchor22"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.4.8"></a><h3>4.8. -Encryption</h3> - -<p>Encryption is done in the same way as for <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1]. This section will only discuss some small changes that HAVE TO be made. Please read <a class='info' href='#RFC3711'>SRTP RFC3711 section 3-9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1] for details. -</p> -<p>The least significant bits of SSRC are replaced by the sender ID and the rest is filled with zeros. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC. -</p><br /><hr class="insert" /> -<a name="srtp_vs_satp"></a> - -<p>Difference between SRTP and SATP -</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 7 </b></font><br /></td></tr></table><hr class="insert" /> - -<a name="anchor23"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.5"></a><h3>5. -Security Considerations</h3> - -<p>As SATP uses the same encrytion technics as <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1], it shares the same security issues. This section will only discuss some small changes. Please read <a class='info' href='#RFC3711'>SRTP RFC3711 section 9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.</span><span>)</span></a> [1] for details. -</p> -<a name="anchor24"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.5.1"></a><h3>5.1. -Replay protection</h3> - -<p>Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SHOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast receiver. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack. -</p> -<a name="anchor25"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.6"></a><h3>6. -IANA Considerations</h3> - -<p>The protocol is intended to be used on top of IP or on top of UDP (to be compatible with NAT routers), so UDP and IP protocol numbers have to be assiged by IANA. -</p> -<a name="rfc.references"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<a name="rfc.section.7"></a><h3>7. -References</h3> - -<a name="rfc.references1"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>7.1. Normative References</h3> -<table width="99%" border="0"> -<tr><td class="author-text" valign="top"><a name="RFC3711">[1]</a></td> -<td class="author-text">Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “<a href="ftp://ftp.isi.edu/in-notes/rfc3711.txt">The Secure Real-time Transport Protocol (SRTP)</a>,” RFC 3711, March 2004.</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC2119">[2]</a></td> -<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC2003">[3]</a></td> -<td class="author-text"><a href="mailto:perk@watson.ibm.com">Perkins, C.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2003.txt">IP Encapsulation within IP</a>,” RFC 2003, October 1996 (<a href="ftp://ftp.isi.edu/in-notes/rfc2003.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2003.xml">XML</a>).</td></tr> -</table> - -<a name="rfc.references2"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>7.2. Informational References</h3> -<table width="99%" border="0"> -<tr><td class="author-text" valign="top"><a name="RFC2784">[4]</a></td> -<td class="author-text"><a href="mailto:dino@procket.com">Farinacci, D.</a>, <a href="mailto:tony1@home.net">Li, T.</a>, <a href="mailto:stan_hanks@enron.net">Hanks, S.</a>, <a href="mailto:dmm@cisco.com">Meyer, D.</a>, and <a href="mailto:pst@juniper.net">P. Traina</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2784.txt">Generic Routing Encapsulation (GRE)</a>,” RFC 2784, March 2000.</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC2401">[5]</a></td> -<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>,” RFC 2401, November 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2401.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2401.xml">XML</a>).</td></tr> -<tr><td class="author-text" valign="top"><a name="RFC1546">[6]</a></td> -<td class="author-text"><a href="mailto:craig@bbn.com">Partridge, C.</a>, <a href="mailto:tmendez@bbn.com">Mendez, T.</a>, and <a href="mailto:milliken@bbn.com">W. Milliken</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc1546.txt">Host Anycasting Service</a>,” RFC 1546, November 1993.</td></tr> -</table> - -<a name="rfc.authors"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>Author's Address</h3> -<table width="99%" border="0" cellpadding="0" cellspacing="0"> -<tr><td class="author-text"> </td> -<td class="author-text">Othmar Gsenger</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Puerstingerstr 32</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Saalfelden 5760</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">AT</td></tr> -<tr><td class="author" align="right">Phone: </td> -<td class="author-text"></td></tr> -<tr><td class="author" align="right">Email: </td> -<td class="author-text"><a href="mailto:satp@gsenger.com">satp@gsenger.com</a></td></tr> -<tr><td class="author" align="right">URI: </td> -<td class="author-text"><a href="http://www.gsenger.com/satp/">http://www.gsenger.com/satp/</a></td></tr> -</table> -<a name="rfc.copyright"></a><br /><hr /> -<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> -<h3>Full Copyright Statement</h3> -<p class='copyright'> -Copyright © The IETF Trust (2007).</p> -<p class='copyright'> -This document is subject to the rights, -licenses and restrictions contained in BCP 78, -and except as set forth therein, -the authors retain all their rights.</p> -<p class='copyright'> -This document and the information contained herein are provided -on an “AS IS” basis and THE CONTRIBUTOR, -THE ORGANIZATION HE/SHE REPRESENTS -OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST -AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, -EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT -THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY -IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR -PURPOSE.</p> -<h3>Intellectual Property</h3> -<p class='copyright'> -The IETF takes no position regarding the validity or scope of any -Intellectual Property Rights or other rights that might be claimed -to pertain to the implementation or use of the technology -described in this document or the extent to which any license -under such rights might or might not be available; nor does it -represent that it has made any independent effort to identify any -such rights. -Information on the procedures with respect to -rights in RFC documents can be found in BCP 78 and BCP 79.</p> -<p class='copyright'> -Copies of IPR disclosures made to the IETF Secretariat and any -assurances of licenses to be made available, -or the result of an attempt made to obtain a general license or -permission for the use of such proprietary rights by implementers or -users of this specification can be obtained from the IETF on-line IPR -repository at <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p> -<p class='copyright'> -The IETF invites any interested party to bring to its attention -any copyrights, -patents or patent applications, -or other -proprietary rights that may cover technology that may be required -to implement this standard. -Please address the information to the IETF at <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p> -<h3>Acknowledgment</h3> -<p class='copyright'> -Funding for the RFC Editor function is provided by -the IETF Administrative Support Activity (IASA).</p> -</body></html> diff --git a/internet-draft-satp.txt b/internet-draft-satp.txt deleted file mode 100644 index 330476c..0000000 --- a/internet-draft-satp.txt +++ /dev/null @@ -1,952 +0,0 @@ - - - -Network Working Group O. Gsenger -Internet-Draft June 21, 2007 -Expires: December 23, 2007 - - - secure anycast tunneling protocol (SATP) - draft-gsenger-secure-anycast-tunneling-protocol-00 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - 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." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on December 23, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 1] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -Abstract - - The secure anycast tunneling protocol (SATP) defines a protocol used - for communication between any combination of unicast and anycast - tunnel endpoints. It allows tunneling of every ETHER TYPE protocol - (ethernet, ip ...). SATP directly includes cryptography and message - authentication based on the methodes used by SRTP. It can be used as - an encrypted alternative to IP Encapsulation within IP [3] and - Generic Routing Encapsulation (GRE) [4]. It supports both anycast - receivers and senders. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 - 2. Motivation and usage scenarios . . . . . . . . . . . . . . . . 4 - 2.1. Usage scenarions . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.1. Tunneling from unicast hosts over anycast routers - to other unicast hosts . . . . . . . . . . . . . . . . 4 - 2.1.2. Tunneling from unicast hosts to anycast networks . . . 5 - 2.1.3. Redundant tunnel connection of 2 networks . . . . . . 5 - 2.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Using SATP on top of IP . . . . . . . . . . . . . . . . . . . 8 - 3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. ICMP messages . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Protocol specification . . . . . . . . . . . . . . . . . . . . 9 - 4.1. Header format . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2. sender ID . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.3. sequence number . . . . . . . . . . . . . . . . . . . . . 9 - 4.4. payload . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.5. padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 9 - 4.6. padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 10 - 4.7. payload type field . . . . . . . . . . . . . . . . . . . . 10 - 4.7.1. MKI (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10 - 4.7.2. authentication tag (RECOMMENDED) . . . . . . . . . . . 10 - 4.8. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 5.1. Replay protection . . . . . . . . . . . . . . . . . . . . 12 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 7.2. Informational References . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Intellectual Property and Copyright Statements . . . . . . . . . . 17 - - - - - - -Gsenger Expires December 23, 2007 [Page 2] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -1. Introduction - - SATP is a mixture of a generic encapsulation protocol like GRE [4] - and a secure tunneling protocol as IPsec [5] in tunnel mode. It can - be used to build redundant virtual private network (VPN) connections. - It supports peer to peer tunnels, where tunnel endpoints can be any - combination of unicast, multicast or anycast hosts, so it defines a - Host Anycast Service [6]. Encryption is done per packet, so the - protocol is robust against packet loss and routing changes. To save - some header overhead it uses the encryption techniques of SRTP [1]. - -1.1. Notational Conventions - - The keywords "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 [2]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 3] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -2. Motivation and usage scenarios - - This section gives an overview of possible usage scenarios. Please - note, that the protocols used in the figures are only examples and - that SATP itself does not care about either transport protocols or - encapsulated protocols. Routing is not done by SATP and each - implemetation MAY choose it's own way of doing this task (e.g. using - functions provided by the operating system). SATP is used only to - encapsulate and encrypt data. - -2.1. Usage scenarions - -2.1.1. Tunneling from unicast hosts over anycast routers to other - unicast hosts - - An example of SATP used to tunnel in a unicast client - anycast - server model - - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint - - Figure 1 - - In this scenario the payload gets encapsuleted into a SATP packet by - a unicast host and gets transmitted to one of the anycast routers. - It than gets decapsulated by the router. This router makes a routing - descision based on the underlying protocol and transmits a new SATP - package to one or more unicast hosts depending on the routing - descition. - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 4] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -2.1.2. Tunneling from unicast hosts to anycast networks - - An example of SATP used to encrypt data between a unicast host and - anycast networks - - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - - - Figure 2 - - When the unicast hosts wants to transmit data to one of the anycast - DNS servers, it encapsulates the data and sends a SATP packet to the - anycast address of the routers. The packet arrives at one of the - routers, gets decapsulated and routed to the DNS server. This method - can be used to tunnel between a clients and networks providing - anycast services. It can also be used the other way to virtually - locate a unicast service within anycasted networks. - -2.1.3. Redundant tunnel connection of 2 networks - - An example of SATP used to connect 2 networks - - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - - - - - -Gsenger Expires December 23, 2007 [Page 5] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - Figure 3 - - Network A has multiple routers, that act as gateway/tunnel endpoints - to another network B. This is done to build a redundant encrypted - tunnel connection between the two networks. All tunnel endpoints of - network A share the same anycast address and all tunnel endpoints of - network B share another anycast address. When a packet from network - A gets transmitted to network B, it first arrives on one of network - A's border routers. Which router is used is determined by network - A's internal routing. This router encapsulates the package and sends - it to the anycast address of the network B routers. The SATP packet - arrives at one of network B's routers and gets decapsulated and - routed to it's destination within network B. - -2.2. Encapsulation - - SATP does not depend on which lower layer protocols is used, but this - section gives an example of how packets could look like. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 6] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - Examples of SATP used with different lower layer and payload - protocols - - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - - Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - - Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - - Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - - Tunneling of IPv6 over IPv4 with RTP payload - - Figure 4 - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 7] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -3. Using SATP on top of IP - -3.1. Fragmentation - - The only way of fully supporting fragmentation would be to - synchronise fragments between all anycast servers. This is - considered to be too much overhead, so there are two non perfect - solutions for these problems. Either fragmentation HAS TO be - disabled or if not all fragments arrive at the same server the ip - datagramm HAS TO be discarded. As routing changes are not expected - to occure very frequently, the encapsulated protocol can do a - retransmission and all fragments will arrive at the new server. - - If the payload type is IP and the ip headers's Don't Fragment (DF) - bit is set, than the DF bit of the outer IP header HAS TO be set as - well. - -3.2. ICMP messages - - ICMP messages MUST be relayed according to rfc2003 section 4 [3]. - This is needed for path MTU detection. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 8] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -4. Protocol specification - -4.1. Header format - - Protocol Format - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | sender ID # | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ + | - | | .... payload ... | | - | |-------------------------------+-------------------------------+ | - | | padding (OPT) | pad count(OPT)| payload type | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ - - Figure 5 - -4.2. sender ID - - The sender ID is a 16 bit unsigned integer. It HAS TO be unique for - every sender sharing the same anycast address - -4.3. sequence number - - The sequence number is a 32 bit unsigned integer in network byte - order. It starts with a random value and is increased by 1 for every - sent packet. After the maximum value, it starts over from 0. This - overrun causes the ROC to be increased. - -4.4. payload - - A packet of the type payload type (e.g. an IP packet). - -4.5. padding (OPTIONAL) - - Padding of max 255 octets. None of the pre-defined encryption - transforms uses any padding; for these, the plaintext and encrypted - payload sizes match exactly. Transforms are based on transforms of - the SRTP protocol and these transforms might use the RTP padding - - - -Gsenger Expires December 23, 2007 [Page 9] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - format, so a RTP like padding is supported. If the padding count - field is present, than the padding count field MUST be set to the - padding lenght. - -4.6. padding count (OPTIONAL) - - The number of octets of the padding field. This field is optional. - It's presence is signaled by the key management and not by this - protocol. If this field isn't present, the padding field MUST NOT be - present as well. - -4.7. payload type field - - The payload type field defines the payload protocol. ETHER TYPE - protocol numbers are used. See IANA assigned ethernet numbers [7] . - The values 0000-05DC are reserverd and MUST NOT be used. - - Some examples for protocol types - - HEX - 0000 Reserved - .... Reserved - 05DC Reserved - 0800 Internet IP (IPv4) - 6558 transparent ethernet bridging - 86DD IPv6 - - Figure 6 - -4.7.1. MKI (OPTIONAL) - - The MKI (Master Key Identifier) is OPTIONAL and of configurable - length. See SRTP Section 3.1 [1] for details - -4.7.2. authentication tag (RECOMMENDED) - - The authentication tag is RECOMMENDED and of configurable length. It - contains a cryptographic checksum of the sender ID, sequence number - and the encrypted portion, but not of the MKI. On sender side - encryption HAS TO be done before calculating the authentication tag. - A receiver HAS TO calculate the authentication tag before decrypting - the encrypted portion. - -4.8. Encryption - - Encryption is done in the same way as for SRTP [1]. This section - will only discuss some small changes that HAVE TO be made. Please - read SRTP RFC3711 section 3-9 [1] for details. - - - -Gsenger Expires December 23, 2007 [Page 10] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - The least significant bits of SSRC are replaced by the sender ID and - the rest is filled with zeros. For the SRTP SEQ the 16 least - significant bits of the SATP sequence number are used and the 16 most - significant bits of the sequence number replace the 16 least - significant bits of the SRTP ROC. - - Difference between SRTP and SATP - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 7 - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 11] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -5. Security Considerations - - As SATP uses the same encrytion technics as SRTP [1], it shares the - same security issues. This section will only discuss some small - changes. Please read SRTP RFC3711 section 9 [1] for details. - -5.1. Replay protection - - Replay protection is done by a replay list. Every anycast receiver - has it's own replay list, which SHOULDN'T be syncronised, because of - massive overhead. This leads to an additional possible attack. A - attacker is able to replay a captured packet once to every anycast - receiver. This attack is considered of be very unlikely, because - multiple attack hosts in different loactions are needed to reach the - seperate anycast receivers and the number of replays is limited to - the count of receivers - 1. Such replays might also happen because - of routing problems, so a payload protocol HAS TO be robust against a - small number of duplicated packages. The window size and position - HAS TO be syncronised between multible anycast receivers to limit - this attack. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 12] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -6. IANA Considerations - - The protocol is intended to be used on top of IP or on top of UDP (to - be compatible with NAT routers), so UDP and IP protocol numbers have - to be assiged by IANA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 13] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -7. References - -7.1. Normative References - - [1] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, March 2004. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Perkins, C., "IP Encapsulation within IP", RFC 2003, - October 1996. - -7.2. Informational References - - [4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, - "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. - - [5] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [6] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 14] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -URIs - - [7] <http://www.iana.org/assignments/ethernet-numbers> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 15] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -Author's Address - - Othmar Gsenger - Puerstingerstr 32 - Saalfelden 5760 - AT - - Phone: - Email: satp@gsenger.com - URI: http://www.gsenger.com/satp/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 16] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Gsenger Expires December 23, 2007 [Page 17] - diff --git a/internet-draft-satp.xml b/internet-draft-satp.xml deleted file mode 100644 index cf1f91b..0000000 --- a/internet-draft-satp.xml +++ /dev/null @@ -1,294 +0,0 @@ -<?xml version='1.0'?> - <!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd' [ - - <!ENTITY rfc1546 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1546.xml'> - <!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'> - <!ENTITY rfc3068 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml'> - <!ENTITY rfc2784 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2784.xml'> - <!ENTITY rfc2401 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2401.xml'> - <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> - <!ENTITY rfc2003 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2003.xml'> -]> -<?rfc toc='yes'?> - <rfc ipr='full3978' docName='draft-gsenger-secure-anycast-tunneling-protocol-00'> - <front> - <title>secure anycast tunneling protocol (SATP)</title> - - <author initials='O.G.' surname='Gsenger' - fullname='Othmar Gsenger'> - <organization></organization> - - <address> - <postal> - <street>Puerstingerstr 32</street> - <city>Saalfelden</city> - <code>5760</code> - <country>AT</country> - </postal> - - <phone></phone> - <email>satp@gsenger.com</email> - <uri>http://www.gsenger.com/satp/</uri> - </address> - </author> - - <date month='June' year='2007' /> - - <area>General</area> - <workgroup></workgroup> - <keyword>satp</keyword> - <keyword>Internet-Draft</keyword> - <keyword>secure anycast tunneling protocol</keyword> - <keyword>anycast</keyword> - <keyword>tunnel</keyword> - <keyword>secure</keyword> - <keyword>protocol</keyword> - <abstract> - <t>The secure anycast tunneling protocol (SATP) defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It allows tunneling of every ETHER TYPE protocol (ethernet, ip ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It can be used as an encrypted alternative to <xref target="RFC2003">IP Encapsulation within IP</xref> and <xref target="RFC2784">Generic Routing Encapsulation (GRE)</xref>. It supports both anycast receivers and senders. - </t> - </abstract> - </front> - <middle> - <section title='Introduction'> - <t>SATP is a mixture of a generic encapsulation protocol like <xref target="RFC2784">GRE</xref> and a secure tunneling protocol as <xref target="RFC2401">IPsec</xref> in tunnel mode. It can be used to build redundant virtual private network (VPN) connections. It supports peer to peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines a <xref target="RFC1546">Host Anycast Service</xref>. Encryption is done per packet, so the protocol is robust against packet loss and routing changes. - To save some header overhead it uses the encryption techniques of <xref target="RFC3711">SRTP</xref>. - </t> - <section title='Notational Conventions'> - <t>The keywords "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">RFC2119</xref>.</t> - </section> - </section> - <section title="Motivation and usage scenarios"> - <t>This section gives an overview of possible usage scenarios. Please note, that the protocols used in the figures are only examples and that SATP itself does not care about either transport protocols or encapsulated protocols. Routing is not done by SATP and each implemetation MAY choose it's own way of doing this task (e.g. using functions provided by the operating system). SATP is used only to encapsulate and encrypt data.</t> - <section title="Usage scenarions"> - - <section title='Tunneling from unicast hosts over anycast routers to other unicast hosts'> - <figure anchor="tunnel_mode"> - <preamble>An example of SATP used to tunnel in a unicast client - anycast server model</preamble> - <artwork> - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint - </artwork> - </figure> - <t>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing descition.</t> - </section> - - <section title='Tunneling from unicast hosts to anycast networks'> - <figure anchor="open_tunnel_mode"> - <preamble>An example of SATP used to encrypt data between a unicast host and anycast networks</preamble> - <artwork> - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - - </artwork> - </figure> - <t>When the unicast hosts wants to transmit data to one of the anycast DNS servers, it encapsulates the data and sends a SATP packet to the anycast address of the routers. The packet arrives at one of the routers, gets decapsulated and routed to the DNS server. This method can be used to tunnel between a clients and networks providing anycast services. It can also be used the other way to virtually locate a unicast service within anycasted networks.</t> - </section> - <section title='Redundant tunnel connection of 2 networks'> - <figure anchor="connect_networks"> - <preamble>An example of SATP used to connect 2 networks</preamble> - <artwork> - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - - </artwork> - </figure> - - <t>Network A has multiple routers, that act as gateway/tunnel endpoints to another network B. This is done to build a redundant encrypted tunnel connection between the two networks. All tunnel endpoints of network A share the same anycast address and all tunnel endpoints of network B share another anycast address. When a packet from network A gets transmitted to network B, it first arrives on one of network A's border routers. Which router is used is determined by network A's internal routing. This router encapsulates the package and sends it to the anycast address of the network B routers. The SATP packet arrives at one of network B's routers and gets decapsulated and routed to it's destination within network B.</t> - </section> - </section> - <section title="Encapsulation"> - <t>SATP does not depend on which lower layer protocols is used, but this section gives an example of how packets could look like. - </t> - <figure anchor="transport_udp"> - <preamble>Examples of SATP used with different lower layer and payload protocols</preamble> - <artwork> - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - -Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - -Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - -Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - -Tunneling of IPv6 over IPv4 with RTP payload - </artwork> - </figure> - </section> - </section> - <section title="Using SATP on top of IP"> - <section title="Fragmentation"> - <t> - The only way of fully supporting fragmentation would be to synchronise fragments between all anycast servers. This is considered to be too much overhead, so there are two non perfect solutions for these problems. Either fragmentation HAS TO be disabled or if not all fragments arrive at the same server the ip datagramm HAS TO be discarded. As routing changes are not expected to occure very frequently, the encapsulated protocol can do a retransmission and all fragments will arrive at the new server. - </t><t>If the payload type is IP and the ip headers's Don't Fragment (DF) bit is set, than the DF bit of the outer IP header HAS TO be set as well.</t> - </section> - <section title="ICMP messages"> - <t>ICMP messages MUST be relayed according to <xref target="RFC2003">rfc2003 section 4</xref>. This is needed for path MTU detection.</t> - </section> - </section> - <section title="Protocol specification"> - <section title="Header format"> - <figure anchor="prot_header_table"> - <preamble>Protocol Format</preamble> - <artwork> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | sender ID # | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ + | - | | .... payload ... | | - | |-------------------------------+-------------------------------+ | - | | padding (OPT) | pad count(OPT)| payload type | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ -</artwork> -</figure> -<t></t> - </section> - <section title="sender ID"> - <t>The sender ID is a 16 bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address</t> - </section> - <section title="sequence number"> - <t>The sequence number is a 32 bit unsigned integer in network byte order. It starts with a random value and is increased by 1 for every sent packet. After the maximum value, it starts over from 0. This overrun causes the ROC to be increased.</t> - </section> - <section title="payload"> - <t>A packet of the type payload type (e.g. an IP packet).</t> - </section> - <section title="padding (OPTIONAL)"> - <t>Padding of max 255 octets. -None of the pre-defined encryption transforms uses any padding; for - these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding lenght.</t> - </section> - <section title="padding count (OPTIONAL)"> - <t>The number of octets of the padding field. This field is optional. It's presence is signaled by the key management and not by this protocol. If this field isn't present, the padding field MUST NOT be present as well.</t> - </section> - <section title="payload type field"> - <t>The payload type field defines the payload protocol. ETHER TYPE protocol numbers are used. <eref target="http://www.iana.org/assignments/ethernet-numbers">See IANA assigned ethernet numbers</eref> . The values 0000-05DC are reserverd and MUST NOT be used. - <figure anchor="prot_type_table"> - <preamble>Some examples for protocol types</preamble> - <artwork> -HEX -0000 Reserved -.... Reserved -05DC Reserved -0800 Internet IP (IPv4) -6558 transparent ethernet bridging -86DD IPv6 -</artwork> -</figure> - <section title="MKI (OPTIONAL)"> - <t>The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See <xref target="RFC3711">SRTP Section 3.1</xref> for details</t> - </section> - <section title="authentication tag (RECOMMENDED)"> - <t>The authentication tag is RECOMMENDED and of configurable length. It contains a cryptographic checksum of the sender ID, sequence number and the encrypted portion, but not of the MKI. On sender side encryption HAS TO be done before calculating the authentication tag. A receiver HAS TO calculate the authentication tag before decrypting the encrypted portion.</t> - </section> -</t> - </section> - <section title="Encryption"> - <t>Encryption is done in the same way as for <xref target="RFC3711">SRTP</xref>. This section will only discuss some small changes that HAVE TO be made. Please read <xref target="RFC3711">SRTP RFC3711 section 3-9</xref> for details. </t><t>The least significant bits of SSRC are replaced by the sender ID and the rest is filled with zeros. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC.</t> - <figure anchor="srtp_vs_satp"> - <preamble>Difference between SRTP and SATP</preamble> - <artwork> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - </artwork> - </figure> - </section> - </section> - <section title="Security Considerations"> - <t>As SATP uses the same encrytion technics as <xref target="RFC3711">SRTP</xref>, it shares the same security issues. This section will only discuss some small changes. Please read <xref target="RFC3711">SRTP RFC3711 section 9</xref> for details.</t> - <section title="Replay protection"> - <t>Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SHOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast receiver. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack.</t> - </section> - </section> - <section title="IANA Considerations"> - <t>The protocol is intended to be used on top of IP or on top of UDP (to be compatible with NAT routers), so UDP and IP protocol numbers have to be assiged by IANA.</t> - </section> - </middle> - <back> - <references title="Normative References"> - &rfc3711; - &rfc2119; - &rfc2003; - </references> - <references title="Informational References"> - &rfc2784; - &rfc2401; - &rfc1546; - </references> - </back> - </rfc> diff --git a/routingtable b/routingtable deleted file mode 100644 index e69de29..0000000 --- a/routingtable +++ /dev/null diff --git a/ssltools/build-all.sh b/ssltools/build-all.sh deleted file mode 100755 index c052739..0000000 --- a/ssltools/build-all.sh +++ /dev/null @@ -1,8 +0,0 @@ -#!/bin/sh -. ./vars -./easy-rsa/clean-all -./easy-rsa/build-ca -./easy-rsa/build-key server1 -./easy-rsa/build-key server2 -./easy-rsa/build-key server3 -./easy-rsa/build-key server4 diff --git a/ssltools/easy-rsa/.externals b/ssltools/easy-rsa/.externals deleted file mode 100644 index 3712eb8..0000000 --- a/ssltools/easy-rsa/.externals +++ /dev/null @@ -1 +0,0 @@ -./2.0 http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn/easy-rsa/2.0 diff --git a/ssltools/easy-rsa/2.0/Makefile b/ssltools/easy-rsa/2.0/Makefile deleted file mode 100644 index 902d78f..0000000 --- a/ssltools/easy-rsa/2.0/Makefile +++ /dev/null @@ -1,13 +0,0 @@ - -DESTDIR= -PREFIX= - -all: - echo "All done." - echo "Run make install DESTDIR=/usr/share/somewhere" - -install: - install -c --directory "${DESTDIR}/${PREFIX}" - install -c --mode=0755 build-* "${DESTDIR}/${PREFIX}" - install -c --mode=0755 clean-all list-crl inherit-inter pkitool revoke-full sign-req whichopensslcnf "${DESTDIR}/${PREFIX}" - install -c --mode=0644 openssl-0.9.6.cnf openssl.cnf README vars "${DESTDIR}/${PREFIX}" diff --git a/ssltools/easy-rsa/2.0/README.gz b/ssltools/easy-rsa/2.0/README.gz Binary files differdeleted file mode 100644 index 116d85b..0000000 --- a/ssltools/easy-rsa/2.0/README.gz +++ /dev/null diff --git a/ssltools/easy-rsa/2.0/build-ca b/ssltools/easy-rsa/2.0/build-ca deleted file mode 100755 index fb1e2ca..0000000 --- a/ssltools/easy-rsa/2.0/build-ca +++ /dev/null @@ -1,8 +0,0 @@ -#!/bin/bash - -# -# Build a root certificate -# - -export EASY_RSA="${EASY_RSA:-.}" -"$EASY_RSA/pkitool" --interact --initca $* diff --git a/ssltools/easy-rsa/2.0/build-dh b/ssltools/easy-rsa/2.0/build-dh deleted file mode 100755 index f019222..0000000 --- a/ssltools/easy-rsa/2.0/build-dh +++ /dev/null @@ -1,11 +0,0 @@ -#!/bin/bash - -# Build Diffie-Hellman parameters for the server side -# of an SSL/TLS connection. - -if [ -d $KEY_DIR ] && [ $KEY_SIZE ]; then - $OPENSSL dhparam -out ${KEY_DIR}/dh${KEY_SIZE}.pem ${KEY_SIZE} -else - echo 'Please source the vars script first (i.e. "source ./vars")' - echo 'Make sure you have edited it to reflect your configuration.' -fi diff --git a/ssltools/easy-rsa/2.0/build-inter b/ssltools/easy-rsa/2.0/build-inter deleted file mode 100755 index f831d6f..0000000 --- a/ssltools/easy-rsa/2.0/build-inter +++ /dev/null @@ -1,7 +0,0 @@ -#!/bin/bash - -# Make an intermediate CA certificate/private key pair using a locally generated -# root certificate. - -export EASY_RSA="${EASY_RSA:-.}" -"$EASY_RSA/pkitool" --interact --inter $* diff --git a/ssltools/easy-rsa/2.0/build-key b/ssltools/easy-rsa/2.0/build-key deleted file mode 100755 index 6196308..0000000 --- a/ssltools/easy-rsa/2.0/build-key +++ /dev/null @@ -1,7 +0,0 @@ -#!/bin/bash - -# Make a certificate/private key pair using a locally generated -# root certificate. - -export EASY_RSA="${EASY_RSA:-.}" -"$EASY_RSA/pkitool" --interact $* diff --git a/ssltools/easy-rsa/2.0/build-key-pass b/ssltools/easy-rsa/2.0/build-key-pass deleted file mode 100755 index 35543e0..0000000 --- a/ssltools/easy-rsa/2.0/build-key-pass +++ /dev/null @@ -1,7 +0,0 @@ -#!/bin/bash - -# Similar to build-key, but protect the private key -# with a password. - -export EASY_RSA="${EASY_RSA:-.}" -"$EASY_RSA/pkitool" --interact --pass $* diff --git a/ssltools/easy-rsa/2.0/build-key-pkcs12 b/ssltools/easy-rsa/2.0/build-key-pkcs12 deleted file mode 100755 index 5ef064f..0000000 --- a/ssltools/easy-rsa/2.0/build-key-pkcs12 +++ /dev/null @@ -1,8 +0,0 @@ -#!/bin/bash - -# Make a certificate/private key pair using a locally generated -# root certificate and convert it to a PKCS #12 file including the -# the CA certificate as well. - -export EASY_RSA="${EASY_RSA:-.}" -"$EASY_RSA/pkitool" --interact --pkcs12 $* diff --git a/ssltools/easy-rsa/2.0/build-key-server b/ssltools/easy-rsa/2.0/build-key-server deleted file mode 100755 index 5502675..0000000 --- a/ssltools/easy-rsa/2.0/build-key-server +++ /dev/null @@ -1,10 +0,0 @@ -#!/bin/bash - -# Make a certificate/private key pair using a locally generated -# root certificate. -# -# Explicitly set nsCertType to server using the "server" -# extension in the openssl.cnf file. - -export EASY_RSA="${EASY_RSA:-.}" -"$EASY_RSA/pkitool" --interact --server $* diff --git a/ssltools/easy-rsa/2.0/build-req b/ssltools/easy-rsa/2.0/build-req deleted file mode 100755 index 26587d1..0000000 --- a/ssltools/easy-rsa/2.0/build-req +++ /dev/null @@ -1,7 +0,0 @@ -#!/bin/bash - -# Build a certificate signing request and private key. Use this -# when your root certificate and key is not available locally. - -export EASY_RSA="${EASY_RSA:-.}" -"$EASY_RSA/pkitool" --interact --csr $* diff --git a/ssltools/easy-rsa/2.0/build-req-pass b/ssltools/easy-rsa/2.0/build-req-pass deleted file mode 100755 index 6e6c863..0000000 --- a/ssltools/easy-rsa/2.0/build-req-pass +++ /dev/null @@ -1,7 +0,0 @@ -#!/bin/bash - -# Like build-req, but protect your private key -# with a password. - -export EASY_RSA="${EASY_RSA:-.}" -"$EASY_RSA/pkitool" --interact --csr --pass $* diff --git a/ssltools/easy-rsa/2.0/clean-all b/ssltools/easy-rsa/2.0/clean-all deleted file mode 100755 index 0576db5..0000000 --- a/ssltools/easy-rsa/2.0/clean-all +++ /dev/null @@ -1,16 +0,0 @@ -#!/bin/bash - -# Initialize the $KEY_DIR directory. -# Note that this script does a -# rm -rf on $KEY_DIR so be careful! - -if [ "$KEY_DIR" ]; then - rm -rf "$KEY_DIR" - mkdir "$KEY_DIR" && \ - chmod go-rwx "$KEY_DIR" && \ - touch "$KEY_DIR/index.txt" && \ - echo 01 >"$KEY_DIR/serial" -else - echo 'Please source the vars script first (i.e. "source ./vars")' - echo 'Make sure you have edited it to reflect your configuration.' -fi diff --git a/ssltools/easy-rsa/2.0/inherit-inter b/ssltools/easy-rsa/2.0/inherit-inter deleted file mode 100755 index 2101951..0000000 --- a/ssltools/easy-rsa/2.0/inherit-inter +++ /dev/null @@ -1,39 +0,0 @@ -#!/bin/bash - -# Build a new PKI which is rooted on an intermediate certificate generated -# by ./build-inter or ./pkitool --inter from a parent PKI. The new PKI should -# have independent vars settings, and must use a different KEY_DIR directory -# from the parent. This tool can be used to generate arbitrary depth -# certificate chains. -# -# To build an intermediate CA, follow the same steps for a regular PKI but -# replace ./build-key or ./pkitool --initca with this script. - -# The EXPORT_CA file will contain the CA certificate chain and should be -# referenced by the OpenVPN "ca" directive in config files. The ca.crt file -# will only contain the local intermediate CA -- it's needed by the easy-rsa -# scripts but not by OpenVPN directly. -EXPORT_CA="export-ca.crt" - -if [ $# -ne 2 ]; then - echo "usage: $0 <parent-key-dir> <common-name>" - echo "parent-key-dir: the KEY_DIR directory of the parent PKI" - echo "common-name: the common name of the intermediate certificate in the parent PKI" - exit 1; -fi - -if [ "$KEY_DIR" ]; then - cp "$1/$2.crt" "$KEY_DIR/ca.crt" - cp "$1/$2.key" "$KEY_DIR/ca.key" - - if [ -e "$1/$EXPORT_CA" ]; then - PARENT_CA="$1/$EXPORT_CA" - else - PARENT_CA="$1/ca.crt" - fi - cp "$PARENT_CA" "$KEY_DIR/$EXPORT_CA" - cat "$KEY_DIR/ca.crt" >> "$KEY_DIR/$EXPORT_CA" -else - echo 'Please source the vars script first (i.e. "source ./vars")' - echo 'Make sure you have edited it to reflect your configuration.' -fi diff --git a/ssltools/easy-rsa/2.0/list-crl b/ssltools/easy-rsa/2.0/list-crl deleted file mode 100755 index afc0cd6..0000000 --- a/ssltools/easy-rsa/2.0/list-crl +++ /dev/null @@ -1,13 +0,0 @@ -#!/bin/bash - -# list revoked certificates - -CRL="${1:-crl.pem}" - -if [ "$KEY_DIR" ]; then - cd "$KEY_DIR" && \ - $OPENSSL crl -text -noout -in "$CRL" -else - echo 'Please source the vars script first (i.e. "source ./vars")' - echo 'Make sure you have edited it to reflect your configuration.' -fi diff --git a/ssltools/easy-rsa/2.0/openssl-0.9.6.cnf.gz b/ssltools/easy-rsa/2.0/openssl-0.9.6.cnf.gz Binary files differdeleted file mode 100644 index d2afde0..0000000 --- a/ssltools/easy-rsa/2.0/openssl-0.9.6.cnf.gz +++ /dev/null diff --git a/ssltools/easy-rsa/2.0/openssl.cnf b/ssltools/easy-rsa/2.0/openssl.cnf deleted file mode 100755 index a781dda..0000000 --- a/ssltools/easy-rsa/2.0/openssl.cnf +++ /dev/null @@ -1,285 +0,0 @@ -# For use with easy-rsa version 2.0 - -# -# OpenSSL example configuration file. -# This is mostly being used for generation of certificate requests. -# - -# This definition stops the following lines choking if HOME isn't -# defined. -HOME = . -RANDFILE = $ENV::HOME/.rnd -openssl_conf = openssl_init - -[ openssl_init ] -# Extra OBJECT IDENTIFIER info: -#oid_file = $ENV::HOME/.oid -oid_section = new_oids -engines = engine_section - -# To use this configuration file with the "-extfile" option of the -# "openssl x509" utility, name here the section containing the -# X.509v3 extensions to use: -# extensions = -# (Alternatively, use a configuration file that has only -# X.509v3 extensions in its main [= default] section.) - -[ new_oids ] - -# We can add new OIDs in here for use by 'ca' and 'req'. -# Add a simple OID like this: -# testoid1=1.2.3.4 -# Or use config file substitution like this: -# testoid2=${testoid1}.5.6 - -#################################################################### -[ ca ] -default_ca = CA_default # The default ca section - -#################################################################### -[ CA_default ] - -dir = $ENV::KEY_DIR # Where everything is kept -certs = $dir # Where the issued certs are kept -crl_dir = $dir # Where the issued crl are kept -database = $dir/index.txt # database index file. -new_certs_dir = $dir # default place for new certs. - -certificate = $dir/ca.crt # The CA certificate -serial = $dir/serial # The current serial number -crl = $dir/crl.pem # The current CRL -private_key = $dir/ca.key # The private key -RANDFILE = $dir/.rand # private random number file - -x509_extensions = usr_cert # The extentions to add to the cert - -# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs -# so this is commented out by default to leave a V1 CRL. -# crl_extensions = crl_ext - -default_days = 3650 # how long to certify for -default_crl_days= 30 # how long before next CRL -default_md = md5 # which md to use. -preserve = no # keep passed DN ordering - -# A few difference way of specifying how similar the request should look -# For type CA, the listed attributes must be the same, and the optional -# and supplied fields are just that :-) -policy = policy_anything - -# For the CA policy -[ policy_match ] -countryName = match -stateOrProvinceName = match -organizationName = match -organizationalUnitName = optional -commonName = supplied -emailAddress = optional - -# For the 'anything' policy -# At this point in time, you must list all acceptable 'object' -# types. -[ policy_anything ] -countryName = optional -stateOrProvinceName = optional -localityName = optional -organizationName = optional -organizationalUnitName = optional -commonName = supplied -emailAddress = optional - -#################################################################### -[ req ] -default_bits = $ENV::KEY_SIZE -default_keyfile = privkey.pem -distinguished_name = req_distinguished_name -attributes = req_attributes -x509_extensions = v3_ca # The extentions to add to the self signed cert - -# Passwords for private keys if not present they will be prompted for -# input_password = secret -# output_password = secret - -# This sets a mask for permitted string types. There are several options. -# default: PrintableString, T61String, BMPString. -# pkix : PrintableString, BMPString. -# utf8only: only UTF8Strings. -# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). -# MASK:XXXX a literal mask value. -# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings -# so use this option with caution! -string_mask = nombstr - -# req_extensions = v3_req # The extensions to add to a certificate request - -[ req_distinguished_name ] -countryName = Country Name (2 letter code) -countryName_default = $ENV::KEY_COUNTRY -countryName_min = 2 -countryName_max = 2 - -stateOrProvinceName = State or Province Name (full name) -stateOrProvinceName_default = $ENV::KEY_PROVINCE - -localityName = Locality Name (eg, city) -localityName_default = $ENV::KEY_CITY - -0.organizationName = Organization Name (eg, company) -0.organizationName_default = $ENV::KEY_ORG - -# we can do this but it is not needed normally :-) -#1.organizationName = Second Organization Name (eg, company) -#1.organizationName_default = World Wide Web Pty Ltd - -organizationalUnitName = Organizational Unit Name (eg, section) -#organizationalUnitName_default = - -commonName = Common Name (eg, your name or your server\'s hostname) -commonName_max = 64 - -emailAddress = Email Address -emailAddress_default = $ENV::KEY_EMAIL -emailAddress_max = 40 - -# JY -- added for batch mode -organizationalUnitName_default = $ENV::KEY_OU -commonName_default = $ENV::KEY_CN - -# SET-ex3 = SET extension number 3 - -[ req_attributes ] -challengePassword = A challenge password -challengePassword_min = 4 -challengePassword_max = 20 - -unstructuredName = An optional company name - -[ usr_cert ] - -# These extensions are added when 'ca' signs a request. - -# This goes against PKIX guidelines but some CAs do it and some software -# requires this to avoid interpreting an end user certificate as a CA. - -basicConstraints=CA:FALSE - -# Here are some examples of the usage of nsCertType. If it is omitted -# the certificate can be used for anything *except* object signing. - -# This is OK for an SSL server. -# nsCertType = server - -# For an object signing certificate this would be used. -# nsCertType = objsign - -# For normal client use this is typical -# nsCertType = client, email - -# and for everything including object signing: -# nsCertType = client, email, objsign - -# This is typical in keyUsage for a client certificate. -# keyUsage = nonRepudiation, digitalSignature, keyEncipherment - -# This will be displayed in Netscape's comment listbox. -nsComment = "Easy-RSA Generated Certificate" - -# PKIX recommendations harmless if included in all certificates. -subjectKeyIdentifier=hash -authorityKeyIdentifier=keyid,issuer:always -extendedKeyUsage=clientAuth -keyUsage = digitalSignature - -# This stuff is for subjectAltName and issuerAltname. -# Import the email address. -# subjectAltName=email:copy - -# Copy subject details -# issuerAltName=issuer:copy - -#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem -#nsBaseUrl -#nsRevocationUrl -#nsRenewalUrl -#nsCaPolicyUrl -#nsSslServerName - -[ server ] - -# JY ADDED -- Make a cert with nsCertType set to "server" -basicConstraints=CA:FALSE -nsCertType = server -nsComment = "Easy-RSA Generated Server Certificate" -subjectKeyIdentifier=hash -authorityKeyIdentifier=keyid,issuer:always -extendedKeyUsage=serverAuth -keyUsage = digitalSignature, keyEncipherment - -[ v3_req ] - -# Extensions to add to a certificate request - -basicConstraints = CA:FALSE -keyUsage = nonRepudiation, digitalSignature, keyEncipherment - -[ v3_ca ] - - -# Extensions for a typical CA - - -# PKIX recommendation. - -subjectKeyIdentifier=hash - -authorityKeyIdentifier=keyid:always,issuer:always - -# This is what PKIX recommends but some broken software chokes on critical -# extensions. -#basicConstraints = critical,CA:true -# So we do this instead. -basicConstraints = CA:true - -# Key usage: this is typical for a CA certificate. However since it will -# prevent it being used as an test self-signed certificate it is best -# left out by default. -# keyUsage = cRLSign, keyCertSign - -# Some might want this also -# nsCertType = sslCA, emailCA - -# Include email address in subject alt name: another PKIX recommendation -# subjectAltName=email:copy -# Copy issuer details -# issuerAltName=issuer:copy - -# DER hex encoding of an extension: beware experts only! -# obj=DER:02:03 -# Where 'obj' is a standard or added object -# You can even override a supported extension: -# basicConstraints= critical, DER:30:03:01:01:FF - -[ crl_ext ] - -# CRL extensions. -# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. - -# issuerAltName=issuer:copy -authorityKeyIdentifier=keyid:always,issuer:always - -[ engine_section ] -# -# If you are using PKCS#11 -# Install engine_pkcs11 of opensc (www.opensc.org) -# And uncomment the following -# verify that dynamic_path points to the correct location -# -#pkcs11 = pkcs11_section - -[ pkcs11_section ] -engine_id = pkcs11 -dynamic_path = /usr/lib/engines/engine_pkcs11.so -MODULE_PATH = $ENV::PKCS11_MODULE_PATH -PIN = $ENV::PKCS11_PIN -init = 0 - diff --git a/ssltools/easy-rsa/2.0/pkitool b/ssltools/easy-rsa/2.0/pkitool deleted file mode 100755 index 5f95162..0000000 --- a/ssltools/easy-rsa/2.0/pkitool +++ /dev/null @@ -1,353 +0,0 @@ -#!/bin/sh - -# OpenVPN -- An application to securely tunnel IP networks -# over a single TCP/UDP port, with support for SSL/TLS-based -# session authentication and key exchange, -# packet encryption, packet authentication, and -# packet compression. -# -# Copyright (C) 2002-2005 OpenVPN Solutions LLC <info@openvpn.net> -# -# This program is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License version 2 -# as published by the Free Software Foundation. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program (see the file COPYING included with this -# distribution); if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - -# pkitool is a front-end for the openssl tool. - -# Calling scripts can set the certificate organizational -# unit with the KEY_OU environmental variable. - -PROGNAME=pkitool -VERSION=2.0 -DEBUG=0 - -die() -{ - local m="$1" - - echo "$m" >&2 - exit 1 -} - -need_vars() -{ - echo ' Please edit the vars script to reflect your configuration,' - echo ' then source it with "source ./vars".' - echo ' Next, to start with a fresh PKI configuration and to delete any' - echo ' previous certificates and keys, run "./clean-all".' - echo " Finally, you can run this tool ($PROGNAME) to build certificates/keys." -} - -usage() -{ - echo "$PROGNAME $VERSION" - echo "Usage: $PROGNAME [options...] [common-name]" - echo "Options:" - echo " --batch : batch mode (default)" - echo " --keysize : Set keysize" - echo " size : size (default=1024)" - echo " --interact : interactive mode" - echo " --server : build server cert" - echo " --initca : build root CA" - echo " --inter : build intermediate CA" - echo " --pass : encrypt private key with password" - echo " --csr : only generate a CSR, do not sign" - echo " --sign : sign an existing CSR" - echo " --pkcs12 : generate a combined PKCS#12 file" - echo " --pkcs11 : generate certificate on PKCS#11 token" - echo " lib : PKCS#11 library" - echo " slot : PKCS#11 slot" - echo " id : PKCS#11 object id (hex string)" - echo " label : PKCS#11 object label" - echo "Standalone options:" - echo " --pkcs11-slots : list PKCS#11 slots" - echo " lib : PKCS#11 library" - echo " --pkcs11-objects : list PKCS#11 token objects" - echo " lib : PKCS#11 library" - echo " slot : PKCS#11 slot" - echo " --pkcs11-init : initialize PKCS#11 token DANGEROUS!!!" - echo " lib : PKCS#11 library" - echo " slot : PKCS#11 slot" - echo " label : PKCS#11 token label" - echo "Notes:" - need_vars - echo " In order to use PKCS#11 interface you must have opensc-0.10.0 or higher." - echo "Generated files and corresponding OpenVPN directives:" - echo '(Files will be placed in the $KEY_DIR directory, defined in ./vars)' - echo " ca.crt -> root certificate (--ca)" - echo " ca.key -> root key, keep secure (not directly used by OpenVPN)" - echo " .crt files -> client/server certificates (--cert)" - echo " .key files -> private keys, keep secure (--key)" - echo " .csr files -> certificate signing request (not directly used by OpenVPN)" - echo " dh1024.pem or dh2048.pem -> Diffie Hellman parameters (--dh)" - echo "Examples:" - echo " $PROGNAME --initca -> Build root certificate" - echo " $PROGNAME --initca --pass -> Build root certificate with password-protected key" - echo " $PROGNAME --server server1 -> Build \"server1\" certificate/key" - echo " $PROGNAME client1 -> Build \"client1\" certificate/key" - echo " $PROGNAME --pass client2 -> Build password-protected \"client2\" certificate/key" - echo " $PROGNAME --pkcs12 client3 -> Build \"client3\" certificate/key in PKCS#12 format" - echo " $PROGNAME --csr client4 -> Build \"client4\" CSR to be signed by another CA" - echo " $PROGNAME --sign client4 -> Sign \"client4\" CSR" - echo " $PROGNAME --inter interca -> Build an intermediate key-signing certificate/key" - echo " Also see ./inherit-inter script." - echo " $PROGNAME --pkcs11 /usr/lib/pkcs11/lib1 0 010203 \"client5 id\" client5" - echo " -> Build \"client5\" certificate/key in PKCS#11 token" - echo "Typical usage for initial PKI setup. Build myserver, client1, and client2 cert/keys." - echo "Protect client2 key with a password. Build DH parms. Generated files in ./keys :" - echo " [edit vars with your site-specific info]" - echo " source ./vars" - echo " ./clean-all" - echo " ./build-dh -> takes a long time, consider backgrounding" - echo " ./$PROGNAME --initca" - echo " ./$PROGNAME --server myserver" - echo " ./$PROGNAME client1" - echo " ./$PROGNAME --pass client2" - echo "Typical usage for adding client cert to existing PKI:" - echo " source ./vars" - echo " ./$PROGNAME client-new" -} - -# Set defaults -DO_REQ="1" -REQ_EXT="" -DO_CA="1" -CA_EXT="" -DO_P12="0" -DO_P11="0" -DO_ROOT="0" -NODES_REQ="-nodes" -NODES_P12="" -BATCH="-batch" -CA="ca" -# must be set or errors of openssl.cnf -PKCS11_MODULE_PATH="dummy" -PKCS11_PIN="dummy" - -# Process options -while [ $# -gt 0 ]; do - case "$1" in - --keysize ) KEY_SIZE=$2 - shift;; - --server ) REQ_EXT="$REQ_EXT -extensions server" - CA_EXT="$CA_EXT -extensions server" ;; - --batch ) BATCH="-batch" ;; - --interact ) BATCH="" ;; - --inter ) CA_EXT="$CA_EXT -extensions v3_ca" ;; - --initca ) DO_ROOT="1" ;; - --pass ) NODES_REQ="" ;; - --csr ) DO_CA="0" ;; - --sign ) DO_REQ="0" ;; - --pkcs12 ) DO_P12="1" ;; - --pkcs11 ) DO_P11="1" - PKCS11_MODULE_PATH="$2" - PKCS11_SLOT="$3" - PKCS11_ID="$4" - PKCS11_LABEL="$5" - shift 4;; - - # standalone - --pkcs11-init) - PKCS11_MODULE_PATH="$2" - PKCS11_SLOT="$3" - PKCS11_LABEL="$4" - if [ -z "$PKCS11_LABEL" ]; then - die "Please specify library name, slot and label" - fi - $PKCS11TOOL --module "$PKCS11_MODULE_PATH" --init-token --slot "$PKCS11_SLOT" \ - --label "$PKCS11_LABEL" && - $PKCS11TOOL --module "$PKCS11_MODULE_PATH" --init-pin --slot "$PKCS11_SLOT" - exit $?;; - --pkcs11-slots) - PKCS11_MODULE_PATH="$2" - if [ -z "$PKCS11_MODULE_PATH" ]; then - die "Please specify library name" - fi - $PKCS11TOOL --module "$PKCS11_MODULE_PATH" --list-slots - exit 0;; - --pkcs11-objects) - PKCS11_MODULE_PATH="$2" - PKCS11_SLOT="$3" - if [ -z "$PKCS11_SLOT" ]; then - die "Please specify library name and slot" - fi - $PKCS11TOOL --module "$PKCS11_MODULE_PATH" --list-objects --login --slot "$PKCS11_SLOT" - exit 0;; - - # errors - --* ) die "$PROGNAME: unknown option: $1" ;; - * ) break ;; - esac - shift -done - -if ! [ -z "$BATCH" ]; then - if $OPENSSL version | grep 0.9.6 > /dev/null; then - die "Batch mode is unsupported in openssl<0.9.7" - fi -fi - -if [ $DO_P12 -eq 1 -a $DO_P11 -eq 1 ]; then - die "PKCS#11 and PKCS#12 cannot be specified together" -fi - -if [ $DO_P11 -eq 1 ]; then - if ! grep "^pkcs11.*=" "$KEY_CONFIG" > /dev/null; then - die "Please edit $KEY_CONFIG and setup PKCS#11 engine" - fi -fi - -# If we are generating pkcs12, only encrypt the final step -if [ $DO_P12 -eq 1 ]; then - NODES_P12="$NODES_REQ" - NODES_REQ="-nodes" -fi - -if [ $DO_P11 -eq 1 ]; then - if [ -z "$PKCS11_LABEL" ]; then - die "PKCS#11 arguments incomplete" - fi -fi - -# If undefined, set default key expiration intervals -if [ -z "$KEY_EXPIRE" ]; then - KEY_EXPIRE=3650 -fi -if [ -z "$CA_EXPIRE" ]; then - CA_EXPIRE=3650 -fi - -# Set organizational unit to empty string if undefined -if [ -z "$KEY_OU" ]; then - KEY_OU="" -fi - -# Set KEY_CN -if [ $DO_ROOT -eq 1 ]; then - if [ -z "$KEY_CN" ]; then - if [ "$1" ]; then - KEY_CN="$1" - elif [ "$KEY_ORG" ]; then - KEY_CN="$KEY_ORG CA" - fi - fi - if [ $BATCH ] && [ "$KEY_CN" ]; then - echo "Using CA Common Name:" $KEY_CN - fi -elif [ $BATCH ] && [ "$KEY_CN" ] && [ $# -eq 0 ]; then - echo "Using Common Name:" $KEY_CN -else - if [ $# -ne 1 ]; then - usage - exit 1 - else - KEY_CN="$1" - fi -fi - -export CA_EXPIRE KEY_EXPIRE KEY_OU KEY_CN PKCS11_MODULE_PATH PKCS11_PIN - -# Show parameters (debugging) -if [ $DEBUG -eq 1 ]; then - echo DO_REQ $DO_REQ - echo REQ_EXT $REQ_EXT - echo DO_CA $DO_CA - echo CA_EXT $CA_EXT - echo NODES_REQ $NODES_REQ - echo NODES_P12 $NODES_P12 - echo DO_P12 $DO_P12 - echo KEY_CN $KEY_CN - echo BATCH $BATCH - echo DO_ROOT $DO_ROOT - echo KEY_EXPIRE $KEY_EXPIRE - echo CA_EXPIRE $CA_EXPIRE - echo KEY_OU $KEY_OU - echo DO_P11 $DO_P11 - echo PKCS11_MODULE_PATH $PKCS11_MODULE_PATH - echo PKCS11_SLOT $PKCS11_SLOT - echo PKCS11_ID $PKCS11_ID - echo PKCS11_LABEL $PKCS11_LABEL -fi - -# Make sure ./vars was sourced beforehand -if [ -d "$KEY_DIR" ] && [ "$KEY_CONFIG" ]; then - cd "$KEY_DIR" - - # Make sure $KEY_CONFIG points to the correct version - # of openssl.cnf - if $GREP -i 'easy-rsa version 2\.[0-9]' "$KEY_CONFIG" >/dev/null; then - : - else - echo "$PROGNAME: KEY_CONFIG (set by the ./vars script) is pointing to the wrong" - echo "version of openssl.cnf: $KEY_CONFIG" - echo "The correct version should have a comment that says: easy-rsa version 2.x"; - exit 1; - fi - - # Build root CA - if [ $DO_ROOT -eq 1 ]; then - $OPENSSL req $BATCH -days $CA_EXPIRE $NODES_REQ -new -newkey rsa:$KEY_SIZE -sha1 \ - -x509 -keyout "$CA.key" -out "$CA.crt" -config "$KEY_CONFIG" && \ - chmod 0600 "$CA.key" - else - # Make sure CA key/cert is available - if [ $DO_CA -eq 1 ] || [ $DO_P12 -eq 1 ]; then - if [ ! -r "$CA.crt" ] || [ ! -r "$CA.key" ]; then - echo "$PROGNAME: Need a readable $CA.crt and $CA.key in $KEY_DIR" - echo "Try $PROGNAME --initca to build a root certificate/key." - exit 1 - fi - fi - - # Generate key for PKCS#11 token - PKCS11_ARGS= - if [ $DO_P11 -eq 1 ]; then - stty -echo - echo -n "User PIN: " - read -r PKCS11_PIN - stty echo - export PKCS11_PIN - - echo "Generating key pair on PKCS#11 token..." - $PKCS11TOOL --module "$PKCS11_MODULE_PATH" --keypairgen \ - --login --pin "$PKCS11_PIN" \ - --key-type rsa:1024 \ - --slot "$PKCS11_SLOT" --id "$PKCS11_ID" --label "$PKCS11_LABEL" || exit 1 - PKCS11_ARGS="-engine pkcs11 -keyform engine -key $PKCS11_SLOT:$PKCS11_ID" - fi - - # Build cert/key - ( [ $DO_REQ -eq 0 ] || $OPENSSL req $BATCH -days $KEY_EXPIRE $NODES_REQ -new -newkey rsa:$KEY_SIZE \ - -keyout "$KEY_CN.key" -out "$KEY_CN.csr" $REQ_EXT -config "$KEY_CONFIG" $PKCS11_ARGS ) && \ - ( [ $DO_CA -eq 0 ] || $OPENSSL ca $BATCH -days $KEY_EXPIRE -out "$KEY_CN.crt" \ - -in "$KEY_CN.csr" $CA_EXT -md sha1 -config "$KEY_CONFIG" ) && \ - ( [ $DO_P12 -eq 0 ] || $OPENSSL pkcs12 -export -inkey "$KEY_CN.key" \ - -in "$KEY_CN.crt" -certfile "$CA.crt" -out "$KEY_CN.p12" $NODES_P12 ) && \ - ( [ $DO_CA -eq 0 -o $DO_P11 -eq 1 ] || chmod 0600 "$KEY_CN.key" ) && \ - ( [ $DO_P12 -eq 0 ] || chmod 0600 "$KEY_CN.p12" ) - - # Load certificate into PKCS#11 token - if [ $DO_P11 -eq 1 ]; then - $OPENSSL x509 -in "$KEY_CN.crt" -inform PEM -out "$KEY_CN.crt.der" -outform DER && \ - $PKCS11TOOL --module "$PKCS11_MODULE_PATH" --write-object "$KEY_CN.crt.der" --type cert \ - --login --pin "$PKCS11_PIN" \ - --slot "$PKCS11_SLOT" --id "$PKCS11_ID" --label "$PKCS11_LABEL" - [ -e "$KEY_CN.crt.der" ]; rm "$KEY_CN.crt.der" - fi - - fi - -# Need definitions -else - need_vars -fi diff --git a/ssltools/easy-rsa/2.0/revoke-full b/ssltools/easy-rsa/2.0/revoke-full deleted file mode 100755 index bf3e5fb..0000000 --- a/ssltools/easy-rsa/2.0/revoke-full +++ /dev/null @@ -1,39 +0,0 @@ -#!/bin/bash - -# revoke a certificate, regenerate CRL, -# and verify revocation - -CRL="crl.pem" -RT="revoke-test.pem" - -if [ $# -ne 1 ]; then - echo "usage: revoke-full <common-name>"; - exit 1 -fi - -if [ "$KEY_DIR" ]; then - cd "$KEY_DIR" - rm -f "$RT" - - # set defaults - export KEY_CN="" - export KEY_OU="" - - # revoke key and generate a new CRL - $OPENSSL ca -revoke "$1.crt" -config "$KEY_CONFIG" - - # generate a new CRL -- try to be compatible with - # intermediate PKIs - $OPENSSL ca -gencrl -out "$CRL" -config "$KEY_CONFIG" - if [ -e export-ca.crt ]; then - cat export-ca.crt "$CRL" >"$RT" - else - cat ca.crt "$CRL" >"$RT" - fi - - # verify the revocation - $OPENSSL verify -CAfile "$RT" -crl_check "$1.crt" -else - echo 'Please source the vars script first (i.e. "source ./vars")' - echo 'Make sure you have edited it to reflect your configuration.' -fi diff --git a/ssltools/easy-rsa/2.0/sign-req b/ssltools/easy-rsa/2.0/sign-req deleted file mode 100755 index 38655d3..0000000 --- a/ssltools/easy-rsa/2.0/sign-req +++ /dev/null @@ -1,7 +0,0 @@ -#!/bin/bash - -# Sign a certificate signing request (a .csr file) -# with a local root certificate and key. - -export EASY_RSA="${EASY_RSA:-.}" -"$EASY_RSA/pkitool" --interact --sign $* diff --git a/ssltools/easy-rsa/2.0/vars b/ssltools/easy-rsa/2.0/vars deleted file mode 100755 index a904547..0000000 --- a/ssltools/easy-rsa/2.0/vars +++ /dev/null @@ -1,64 +0,0 @@ -# easy-rsa parameter settings - -# NOTE: If you installed from an RPM, -# don't edit this file in place in -# /usr/share/openvpn/easy-rsa -- -# instead, you should copy the whole -# easy-rsa directory to another location -# (such as /etc/openvpn) so that your -# edits will not be wiped out by a future -# OpenVPN package upgrade. - -# This variable should point to -# the top level of the easy-rsa -# tree. -export EASY_RSA="`pwd`" - -# -# This variable should point to -# the requested executables -# -export OPENSSL="openssl" -export PKCS11TOOL="pkcs11-tool" -export GREP="grep" - - -# This variable should point to -# the openssl.cnf file included -# with easy-rsa. -export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA` - -# Edit this variable to point to -# your soon-to-be-created key -# directory. -# -# WARNING: clean-all will do -# a rm -rf on this directory -# so make sure you define -# it correctly! -export KEY_DIR="$EASY_RSA/keys" - -# Issue rm -rf warning -echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR - -# Increase this to 2048 if you -# are paranoid. This will slow -# down TLS negotiation performance -# as well as the one-time DH parms -# generation process. -export KEY_SIZE=1024 - -# In how many days should the root CA key expire? -export CA_EXPIRE=3650 - -# In how many days should certificates expire? -export KEY_EXPIRE=3650 - -# These are the default values for fields -# which will be placed in the certificate. -# Don't leave any of these fields blank. -export KEY_COUNTRY="US" -export KEY_PROVINCE="CA" -export KEY_CITY="SanFrancisco" -export KEY_ORG="Fort-Funston" -export KEY_EMAIL="me@myhost.mydomain" diff --git a/ssltools/easy-rsa/2.0/whichopensslcnf b/ssltools/easy-rsa/2.0/whichopensslcnf deleted file mode 100755 index 2260aa8..0000000 --- a/ssltools/easy-rsa/2.0/whichopensslcnf +++ /dev/null @@ -1,13 +0,0 @@ -#!/bin/sh - -if [ "$OPENSSL" ]; then - if $OPENSSL version | grep 0.9.6 > /dev/null; then - echo "$1/openssl-0.9.6.cnf" - else - echo "$1/openssl.cnf" - fi -else - echo "$1/openssl.cnf" -fi - -exit 0 diff --git a/ssltools/easy-rsa/README.gz b/ssltools/easy-rsa/README.gz Binary files differdeleted file mode 100644 index 70ce70f..0000000 --- a/ssltools/easy-rsa/README.gz +++ /dev/null diff --git a/ssltools/easy-rsa/build-ca b/ssltools/easy-rsa/build-ca deleted file mode 100755 index 5ad59cc..0000000 --- a/ssltools/easy-rsa/build-ca +++ /dev/null @@ -1,13 +0,0 @@ -#!/bin/sh - -# -# Build a root certificate -# - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl req -days 3650 -nodes -new -x509 -keyout ca.key -out ca.crt -config $KEY_CONFIG && \ - chmod 0600 ca.key -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/build-dh b/ssltools/easy-rsa/build-dh deleted file mode 100755 index 6de4baf..0000000 --- a/ssltools/easy-rsa/build-dh +++ /dev/null @@ -1,12 +0,0 @@ -#!/bin/sh - -# -# Build Diffie-Hellman parameters for the server side -# of an SSL/TLS connection. -# - -if test $KEY_DIR; then - openssl dhparam -out ${KEY_DIR}/dh${KEY_SIZE}.pem ${KEY_SIZE} -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/build-inter b/ssltools/easy-rsa/build-inter deleted file mode 100755 index 8b3a6b2..0000000 --- a/ssltools/easy-rsa/build-inter +++ /dev/null @@ -1,19 +0,0 @@ -#!/bin/sh - -# -# Make an intermediate CA certificate/private key pair using a locally generated -# root certificate. -# - -if test $# -ne 1; then - echo "usage: build-inter <name>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl req -days 3650 -nodes -new -keyout $1.key -out $1.csr -config $KEY_CONFIG && \ - openssl ca -extensions v3_ca -days 3650 -out $1.crt -in $1.csr -config $KEY_CONFIG -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/build-key b/ssltools/easy-rsa/build-key deleted file mode 100755 index 3159d2b..0000000 --- a/ssltools/easy-rsa/build-key +++ /dev/null @@ -1,20 +0,0 @@ -#!/bin/sh - -# -# Make a certificate/private key pair using a locally generated -# root certificate. -# - -if test $# -ne 1; then - echo "usage: build-key <name>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl req -days 3650 -nodes -new -keyout $1.key -out $1.csr -config $KEY_CONFIG && \ - openssl ca -days 3650 -out $1.crt -in $1.csr -config $KEY_CONFIG && \ - chmod 0600 $1.key -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/build-key-pass b/ssltools/easy-rsa/build-key-pass deleted file mode 100755 index 03ab304..0000000 --- a/ssltools/easy-rsa/build-key-pass +++ /dev/null @@ -1,20 +0,0 @@ -#!/bin/sh - -# -# Similar to build-key, but protect the private key -# with a password. -# - -if test $# -ne 1; then - echo "usage: build-key-pass <name>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl req -days 3650 -new -keyout $1.key -out $1.csr -config $KEY_CONFIG && \ - openssl ca -days 3650 -out $1.crt -in $1.csr -config $KEY_CONFIG && \ - chmod 0600 $1.key -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/build-key-pkcs12 b/ssltools/easy-rsa/build-key-pkcs12 deleted file mode 100755 index f8a057b..0000000 --- a/ssltools/easy-rsa/build-key-pkcs12 +++ /dev/null @@ -1,21 +0,0 @@ -#!/bin/sh - -# -# Make a certificate/private key pair using a locally generated -# root certificate and convert it to a PKCS #12 file including the -# the CA certificate as well. - -if test $# -ne 1; then - echo "usage: build-key-pkcs12 <name>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl req -days 3650 -nodes -new -keyout $1.key -out $1.csr -config $KEY_CONFIG && \ - openssl ca -days 3650 -out $1.crt -in $1.csr -config $KEY_CONFIG && \ - openssl pkcs12 -export -inkey $1.key -in $1.crt -certfile ca.crt -out $1.p12 && \ - chmod 0600 $1.key $1.p12 -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/build-key-server b/ssltools/easy-rsa/build-key-server deleted file mode 100755 index 30dc41e..0000000 --- a/ssltools/easy-rsa/build-key-server +++ /dev/null @@ -1,22 +0,0 @@ -#!/bin/sh - -# -# Make a certificate/private key pair using a locally generated -# root certificate. -# -# Explicitly set nsCertType to server using the "server" -# extension in the openssl.cnf file. - -if test $# -ne 1; then - echo "usage: build-key-server <name>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl req -days 3650 -nodes -new -keyout $1.key -out $1.csr -extensions server -config $KEY_CONFIG && \ - openssl ca -days 3650 -out $1.crt -in $1.csr -extensions server -config $KEY_CONFIG && \ - chmod 0600 $1.key -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/build-req b/ssltools/easy-rsa/build-req deleted file mode 100755 index 30f62f5..0000000 --- a/ssltools/easy-rsa/build-req +++ /dev/null @@ -1,18 +0,0 @@ -#!/bin/sh - -# -# Build a certificate signing request and private key. Use this -# when your root certificate and key is not available locally. -# - -if test $# -ne 1; then - echo "usage: build-req <name>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl req -days 3650 -nodes -new -keyout $1.key -out $1.csr -config $KEY_CONFIG -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/build-req-pass b/ssltools/easy-rsa/build-req-pass deleted file mode 100755 index 829b286..0000000 --- a/ssltools/easy-rsa/build-req-pass +++ /dev/null @@ -1,18 +0,0 @@ -#!/bin/sh - -# -# Like build-req, but protect your private key -# with a password. -# - -if test $# -ne 1; then - echo "usage: build-req-pass <name>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl req -days 3650 -new -keyout $1.key -out $1.csr -config $KEY_CONFIG -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/clean-all b/ssltools/easy-rsa/clean-all deleted file mode 100755 index d10aef5..0000000 --- a/ssltools/easy-rsa/clean-all +++ /dev/null @@ -1,19 +0,0 @@ -#!/bin/sh - -# -# Initialize the $KEY_DIR directory. -# Note that this script does a -# rm -rf on $KEY_DIR so be careful! -# - -d=$KEY_DIR - -if test $d; then - rm -rf $d - mkdir $d && \ - chmod go-rwx $d && \ - touch $d/index.txt && \ - echo 01 >$d/serial -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/list-crl b/ssltools/easy-rsa/list-crl deleted file mode 100644 index b214dbd..0000000 --- a/ssltools/easy-rsa/list-crl +++ /dev/null @@ -1,18 +0,0 @@ -#!/bin/sh - -# -# list revoked certificates -# -# - -if test $# -ne 1; then - echo "usage: list-crl <crlfile.pem>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl crl -text -noout -in $1 -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/make-crl b/ssltools/easy-rsa/make-crl deleted file mode 100644 index 62fe6c1..0000000 --- a/ssltools/easy-rsa/make-crl +++ /dev/null @@ -1,18 +0,0 @@ -#!/bin/sh - -# -# generate a CRL -# -# - -if test $# -ne 1; then - echo "usage: make-crl <crlfile.pem>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl ca -gencrl -out $1 -config $KEY_CONFIG -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/revoke-crt b/ssltools/easy-rsa/revoke-crt deleted file mode 100644 index 35b071a..0000000 --- a/ssltools/easy-rsa/revoke-crt +++ /dev/null @@ -1,18 +0,0 @@ -#!/bin/sh - -# -# revoke a certificate -# -# - -if test $# -ne 1; then - echo "usage: revoke-crt <file.crt>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl ca -revoke $1 -config $KEY_CONFIG -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/revoke-full b/ssltools/easy-rsa/revoke-full deleted file mode 100755 index 66ea03f..0000000 --- a/ssltools/easy-rsa/revoke-full +++ /dev/null @@ -1,29 +0,0 @@ -#!/bin/sh - -# revoke a certificate, regenerate CRL, -# and verify revocation - -CRL=crl.pem -RT=revoke-test.pem - -if test $# -ne 1; then - echo "usage: revoke-full <name>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR - rm -f $RT - - # revoke key and generate a new CRL - openssl ca -revoke $1.crt -config $KEY_CONFIG - - # generate a new CRL - openssl ca -gencrl -out $CRL -config $KEY_CONFIG - cat ca.crt $CRL >$RT - - # verify the revocation - openssl verify -CAfile $RT -crl_check $1.crt -else - echo you must define KEY_DIR -fi diff --git a/ssltools/easy-rsa/sign-req b/ssltools/easy-rsa/sign-req deleted file mode 100755 index 59edc42..0000000 --- a/ssltools/easy-rsa/sign-req +++ /dev/null @@ -1,18 +0,0 @@ -#!/bin/sh - -# -# Sign a certificate signing request (a .csr file) -# with a local root certificate and key. -# - -if test $# -ne 1; then - echo "usage: sign-req <name>"; - exit 1 -fi - -if test $KEY_DIR; then - cd $KEY_DIR && \ - openssl ca -days 3650 -out $1.crt -in $1.csr -config $KEY_CONFIG -else - echo you must define KEY_DIR -fi diff --git a/ssltools/keys/ca.crt b/ssltools/keys/ca.crt deleted file mode 100644 index c4dd94b..0000000 --- a/ssltools/keys/ca.crt +++ /dev/null @@ -1,24 +0,0 @@ ------BEGIN CERTIFICATE----- -MIIEGDCCAwCgAwIBAgIJAIKnIVmOHh/kMA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNV -BAYTAkFUMQswCQYDVQQIEwJOQTEQMA4GA1UEBxMHQklTSEtFSzEUMBIGA1UEChML -QU5ZVFVOLVRFU1QxITAfBgkqhkiG9w0BCQEWEm1lQG15aG9zdC5teWRvbWFpbjAe -Fw0wNzEyMDMwOTQwNTlaFw0xNzExMzAwOTQwNTlaMGUxCzAJBgNVBAYTAkFUMQsw -CQYDVQQIEwJOQTEQMA4GA1UEBxMHQklTSEtFSzEUMBIGA1UEChMLQU5ZVFVOLVRF -U1QxITAfBgkqhkiG9w0BCQEWEm1lQG15aG9zdC5teWRvbWFpbjCCASIwDQYJKoZI -hvcNAQEBBQADggEPADCCAQoCggEBANrdoDDCweNMNoPt0OHTSH04szK0cQdB84QB -2aFPITLOLK1jpp08I3pudz5FSwRHjsZPMJomoEXrruko/bA7q8O/xoORVNpwN3SG -lK3aqvwZfHm3Tbx7CBS/5JPlYOB5Q37femu0Gdak0oMrEBaqIxsA2Ne2D0GVnVYk -Ab2j1zuGR6eor+KhdTcdn63/zTVsARz1mcTweJxROtXRcmB3CkvO68gxs+iz4vVN -nebkW/VxbiUzNSAyQ193v177LYvxREpqSwgSscdwOTuNpDpF4Gr1YTOTlmm4tkG5 -DW8oSaT/sp8ugi5uUVGbSe9YKnVoPjZw4ARGDWQPiA7qYeHHPDsCAwEAAaOByjCB -xzAdBgNVHQ4EFgQUKIb1DfBeNiUyAA6AJgFMWoqVaZwwgZcGA1UdIwSBjzCBjIAU -KIb1DfBeNiUyAA6AJgFMWoqVaZyhaaRnMGUxCzAJBgNVBAYTAkFUMQswCQYDVQQI -EwJOQTEQMA4GA1UEBxMHQklTSEtFSzEUMBIGA1UEChMLQU5ZVFVOLVRFU1QxITAf -BgkqhkiG9w0BCQEWEm1lQG15aG9zdC5teWRvbWFpboIJAIKnIVmOHh/kMAwGA1Ud -EwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAKjvyWpVfauz7f12N3B/T8RClAq4 -NBL922F/OSx9eo7nVpdJ+ULG2ZPxU/umGGgUYP9kO1OTjCdfWSzzSer6eXBlOS4X -WgNI3Am3UhybSi0rRIPfhYPBIRudN8o/8fdzOyfIXNZRzVIK7H21/DrBC1G8JyLP -fVOO6HjiGBQMTCuYNbkWy1gV6HDz4+shyvEDamBIQZVKqEPI2QrvTwbGAtFmoajb -WSd+v8bNtXXNt3QPpp3JIcDUvWtjiaFCgAifYkv+tp/1lAY5/G01HlBsTEx+lDWw -oKeS8p0mB3sbKV8xS0VXiVAWojTzc3nL1oDv3Wt5bP0M1SF/puQB+FIidTc= ------END CERTIFICATE----- diff --git a/ssltools/keys/ca.key b/ssltools/keys/ca.key deleted file mode 100644 index dc2e523..0000000 --- a/ssltools/keys/ca.key +++ /dev/null @@ -1,27 +0,0 @@ ------BEGIN RSA PRIVATE KEY----- -MIIEpAIBAAKCAQEA2t2gMMLB40w2g+3Q4dNIfTizMrRxB0HzhAHZoU8hMs4srWOm -nTwjem53PkVLBEeOxk8wmiagReuu6Sj9sDurw7/Gg5FU2nA3dIaUrdqq/Bl8ebdN -vHsIFL/kk+Vg4HlDft96a7QZ1qTSgysQFqojGwDY17YPQZWdViQBvaPXO4ZHp6iv -4qF1Nx2frf/NNWwBHPWZxPB4nFE61dFyYHcKS87ryDGz6LPi9U2d5uRb9XFuJTM1 -IDJDX3e/Xvsti/FESmpLCBKxx3A5O42kOkXgavVhM5OWabi2QbkNbyhJpP+yny6C -Lm5RUZtJ71gqdWg+NnDgBEYNZA+IDuph4cc8OwIDAQABAoIBAQCutAP/iCauYhKO -AtIewMF3O0BHdCNY8LsKH1Px4DEW1d5x1T6U+gEz5GOIsFUuKFR+VY3tLnH2/idT -dGX0O91i1n0GXobGCpcpi5e4ovijXVCv87K4hdiwf3Bc4dcPt5w59PdKa6vIWy6y -hzhDbzGwh1+P6IKLDntV3E4La3INzyr/8nFeoybCf0tHyK15j0PVycGExU+q54Jr -/LM6y1mAY9CbE+k8C5QwvkO8H2fyQcfqiHIZlBT08y+bP7/zuUAvjcX1oaVk2Qtt -dX3N02kIw+C053oxxoQ+K9MSohF5KPdm9FFmalxvMbdWcFD+s6nNtPBGXbBvZy5/ -8c7nDx9xAoGBAPGsH0znvKWq0RNU8rho7SlMRZ2wY0LpMgjLcAMbKZ1xr16kdrHY -RZANVL0jm1hQi0pnJlEJ2B87zjXCOjytFqF5xoGKWjiHYc+yYVpzQTMXdzHxSmG6 -rPGqCCMi6z+QaC1RcFwVXD1po7UMx8c18sy4/ERIIHcQwy5VJVtJIiK5AoGBAOfX -XaGX8nZFQg/yXRI0O1Lk9rXv+37CqcL7dtkbhxSVCdfe3q0XcIUac9oy1uoK2B+Z -0PNne4mafky4B2r4DOEWWEBjsYAGhRTKYEHVYUecgtTL6IqnVwWe2aEDerkTQPbo -0/A5sVJimbvn7xtDO8E9Vezoqg25cdYK54RKIayTAoGAY013exFJqcUbrdbc+Ttc -H/kQLfBZiRfrEEQPnacenWwmRDxN7VvRkZR4ulMUNOC7q3HhA7GI1aSsYdiSN3Zj -8yvnjjj8Q3gVj9NbP2BWbRj6SFI+XxPmllJoj498nJzIwb5R7fR092Md+nnq6QdY -4hgsyB3fAS2pFbO06uKNHTkCgYBsngnP21BM+MWqkvHnxXDFtV+gfX5mNO0z3Hwh -2zO+ANVLva61iXW95lbAs3Dc1ZfLtlSetKy8GxVw/Ab9ppjiG4XdJNfUEznmM6pF -LaMV2c2xxJZ930h16aYsOWUVsF+PTiV9NopM/sTntBHhw+4K6qGHDLofE/KxRQqS -f+im4QKBgQDOTT16WHPzbq3JnY8Rt4ABE9GmkKih42+XdYBYh7a/AQDiriY2tfPX -EFEpc3dRFr/yhgRecaBVk4SYJy+qxKnl7Ekk4lQ8y0zH53E/D+BDOh6EpbsUtkvS -lUc6N0SKKoStE3bX8pOkniJfS9Vfpzf9KUnwVCp5T+2Lzt8vzCK08g== ------END RSA PRIVATE KEY----- diff --git a/ssltools/keys/index.txt b/ssltools/keys/index.txt deleted file mode 100644 index e69de29..0000000 --- a/ssltools/keys/index.txt +++ /dev/null diff --git a/ssltools/keys/serial b/ssltools/keys/serial deleted file mode 100644 index 8a0f05e..0000000 --- a/ssltools/keys/serial +++ /dev/null @@ -1 +0,0 @@ -01 diff --git a/ssltools/keys/server1.crt b/ssltools/keys/server1.crt deleted file mode 100644 index e69de29..0000000 --- a/ssltools/keys/server1.crt +++ /dev/null diff --git a/ssltools/keys/server1.csr b/ssltools/keys/server1.csr deleted file mode 100644 index 059c169..0000000 --- a/ssltools/keys/server1.csr +++ /dev/null @@ -1,17 +0,0 @@ ------BEGIN CERTIFICATE REQUEST----- -MIICqjCCAZICAQAwZTELMAkGA1UEBhMCQVQxCzAJBgNVBAgTAk5BMRAwDgYDVQQH -EwdCSVNIS0VLMRQwEgYDVQQKEwtBTllUVU4tVEVTVDEhMB8GCSqGSIb3DQEJARYS -bWVAbXlob3N0Lm15ZG9tYWluMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC -AQEAv88G8qUEqOiCvchwUeBSadUeGs0Md26ROUAMUw6G58OlzjRgT+tzbSiOzIdN -bxmSeHPCa8bYATYTTThnHmVg4CE7xP9U+tA+tJAIkpkBZZYotnV/OnJR0F4TtfKZ -K+O8+Yybaiblad1wSzXjrzX4QQ9ueh3Dg+7QEwSCq9GNP1x/2nyJi9c9Dpko2z71 -b2K1oPKhjTuVSbwL7gkp7E9TaaKfRhyj5w3eVOz+QcYR2HHClmL244VjJhQ/K99V -Rs+RrFbustiV76NNU57ibeBWMbQofIcaX0nuw0m7uZELEu0QZQuV7ARo+0Y5OIuU -XecaRwItaCJSscKE4UVeFABGHQIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBACF4 -pOn14suzMMpniCfSAUVNa6yhsQ5yik3N+5/UF8z08xests0huzXFU62Cv2QSXCQx -EwjAJSBgA4oS6Xr+QmI8P3UN1QeY4NqgxOmURZTdG5oWAPTcHE7SMulzjKP5ZxoZ -FyWmSNXolMNqGwcrbhrqF3xXkPVC+HkK2qX9C4p7IZm8lWGJ+g4Mbf5Sh924BoJ2 -RCNWZbtwtli88IvWUzQUqkJXjVVChigxbwOmwEk3JNWxXcyKt1SdjY0poIzf013V -+b8np6CIFxq0MyihMpI0gSkXy0Yhs36sjopiYAJ2nD+3Q17/pBhRKnnyAxWH3ZsD -Stga9FJHLzITwLF1ASo= ------END CERTIFICATE REQUEST----- diff --git a/ssltools/keys/server1.key b/ssltools/keys/server1.key deleted file mode 100644 index 7ad0455..0000000 --- a/ssltools/keys/server1.key +++ /dev/null @@ -1,27 +0,0 @@ ------BEGIN RSA PRIVATE KEY----- -MIIEowIBAAKCAQEAv88G8qUEqOiCvchwUeBSadUeGs0Md26ROUAMUw6G58OlzjRg -T+tzbSiOzIdNbxmSeHPCa8bYATYTTThnHmVg4CE7xP9U+tA+tJAIkpkBZZYotnV/ -OnJR0F4TtfKZK+O8+Yybaiblad1wSzXjrzX4QQ9ueh3Dg+7QEwSCq9GNP1x/2nyJ -i9c9Dpko2z71b2K1oPKhjTuVSbwL7gkp7E9TaaKfRhyj5w3eVOz+QcYR2HHClmL2 -44VjJhQ/K99VRs+RrFbustiV76NNU57ibeBWMbQofIcaX0nuw0m7uZELEu0QZQuV -7ARo+0Y5OIuUXecaRwItaCJSscKE4UVeFABGHQIDAQABAoIBAHRd1YlANCOFbExX -Xk1OGrG6ahk4bWfH3LMu+EsrdQ0G1YDUpdnWrqB7CqdrLr9IdGQ/VqSsbj/N3sfq -gCUgvDU99FT/0z6XOHOzLoBB82b+QpTvk9CRqrEPYkXweJz3/Z4of+FW17fycD4w -44FY7NQL2KqdhBB2wiXHhr9W0qqtFZWuJTOskVpG6pkGhI8wHSL8jz1vI+0KAa6c -FEUe65jVvnBHg2qMwizpqiHm0Yf2gv3D5Mgk3MDww79V3LdQ7UEqiclYOG3nBfzj -HWo/ptKK3vGhzN5v09rDGHIAbHCWg6YzGe5Dvj7GhkKqvtdJCPXje8mMfc7xXEfh -pUJkBgECgYEA81yXC7BD+fpHAc0MZSf+8i9C6ENm5ZaDt0wlg5UnGKlTk+9n66p6 -V/GXmur7HJaL72RVYeUvXxKkzDQ4j3i+qCrkgHMpc9hjkCZ+nZWjwSFZEnxjXcUh -yhHcvnrfRwgNGLqwsIoUSTVhptbZc932n8jpq6PNZYrEUNlsdkpgpYUCgYEAycUO -1bhvRr50Hf2AW5mRbJRxsUqqVk4Rz1/eevZMsXssy6J9K0to5YO1QKaFz4+FiRkU -DkV1nGb/v02cFY8jHe2rOeP8LeYChWsVl3tvrCA1rkio2ITAFI3W+WaBW3j7cizV -5hhLhg3Ez08lZP5lF+lB6M3b740W2vaoF9791bkCgYBAkketnUZcFJE0pCBu0q7t -uaaKFCBAOLCYOQcXI8Ms4vi/Ht23BRPTM9IjE8gvLK7ShQ+2muX31u2NFSoQv1vv -KPpaLrRH/ZllTSF5VJQPkXad1g1TexPdFuI4VEfcBAHdluN85BY/2n8fkpA+Ex32 -BYwis6KzF5/BR/9kX5XHNQKBgH7LNudXX5Y1WQL/qwnlF14Eau3e3eweY1LODCF5 -ZfiiTyQomD/8w453lg9qlew5ZNEi0VemjqIal9zACLYDnS3RjShz/KVbRXpSMN9g -0mx4UUOUpYZq5coE2HMh12iEPn8hbcmKuusi++rK8dTliOHd021Y8D05jINNPZTC -rQEBAoGBAO8Ozk9FK3r68vkYlLNmwu2Z5XPS7ZLDwgmfTVJRl+n6ikZCr7uo7+Xc -6rkPeueTV15MSMPQDqY12gbAlIrSpOhINEKt5T/inxUIpU6VItFy9bk1+OXwUfE0 -2gHRzohq1tFSd9E+A+9Z0rHDpYfsuXZIro+nBXqn9OxPap15mx+5 ------END RSA PRIVATE KEY----- diff --git a/ssltools/keys/server2.crt b/ssltools/keys/server2.crt deleted file mode 100644 index e69de29..0000000 --- a/ssltools/keys/server2.crt +++ /dev/null diff --git a/ssltools/keys/server2.csr b/ssltools/keys/server2.csr deleted file mode 100644 index 993c2e0..0000000 --- a/ssltools/keys/server2.csr +++ /dev/null @@ -1,17 +0,0 @@ ------BEGIN CERTIFICATE REQUEST----- -MIICqjCCAZICAQAwZTELMAkGA1UEBhMCQVQxCzAJBgNVBAgTAk5BMRAwDgYDVQQH -EwdCSVNIS0VLMRQwEgYDVQQKEwtBTllUVU4tVEVTVDEhMB8GCSqGSIb3DQEJARYS -bWVAbXlob3N0Lm15ZG9tYWluMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC -AQEAysIXEbv0kDcGX0XMWUVN5QrMgmshAo0CJswB1V771B81TJrat+9bxxzuGKWf -6tdBLGyT7S5BYKbCF/h6Z8oT7KRSQ3qmK4CtvNt05d8TW6sbZf6UWPXMLwii4ztA -193Otrk0Z6adyF1AJJtFkPUf1XmJHeAHFBRPzy4zV8oFrFX4Fc97gsxULPANs763 -9KBz8TuGxomzO6gRPJ+HTKpC/CG1tvJxM36T8pZfGlqi/jLlfR/2JUkvjzP2WW7S -/FGS3sAioSkSd09TbupSmf1R90kRBRdlt/BhgvCvSFDndWXGNuoDXPDgkYZJ3BUN -7C2lPCqorvNxsY/iCW8m+66hSwIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBAGwp -QT5j8ZPEnMh3T3krCE94pheM9nsbTxpn4/NyQsijZVJ0PoL5iqo8IXjFymC4IzfN -PwqxanPeDBlDpJtgUucDAmhNSo4XAj8IldO5ZpGostta2BKbw8kZHe6lA95v7Myu -tVlnbXp15XQJWlAoVkdZGkqOlmNbBveqCL9IcGrDrxusZNhPRKeBZcyIzDKQYXJ8 -F0t55aGbMl0rZUbobvsGgHImfhZ1E3uuD1ePlSxGbHPv7KWelf5fVj58KuGOfTYC -RX5S/N7ERaH2627oXYekJJRrtCh/Nn5ZAr2p3ThmoWr7tzwKm4BctMA9PWjLsuJV -yMTFavGRp6g8YvZ2NGA= ------END CERTIFICATE REQUEST----- diff --git a/ssltools/keys/server2.key b/ssltools/keys/server2.key deleted file mode 100644 index ae183a9..0000000 --- a/ssltools/keys/server2.key +++ /dev/null @@ -1,27 +0,0 @@ ------BEGIN RSA PRIVATE KEY----- -MIIEowIBAAKCAQEAysIXEbv0kDcGX0XMWUVN5QrMgmshAo0CJswB1V771B81TJra -t+9bxxzuGKWf6tdBLGyT7S5BYKbCF/h6Z8oT7KRSQ3qmK4CtvNt05d8TW6sbZf6U -WPXMLwii4ztA193Otrk0Z6adyF1AJJtFkPUf1XmJHeAHFBRPzy4zV8oFrFX4Fc97 -gsxULPANs7639KBz8TuGxomzO6gRPJ+HTKpC/CG1tvJxM36T8pZfGlqi/jLlfR/2 -JUkvjzP2WW7S/FGS3sAioSkSd09TbupSmf1R90kRBRdlt/BhgvCvSFDndWXGNuoD -XPDgkYZJ3BUN7C2lPCqorvNxsY/iCW8m+66hSwIDAQABAoIBAHmylXYnglstK73z -fvv2BRL8sFN3SZDmYew3dsJDCJQBR1R7fdv45vVT//T7NEkYeh3X7dHmeYcxkD4i -/hVdzSe0WUv3SdXCnoVEk52Fj3Dt+rv1WcUrgyqX3GzXG8x1baVu9G1iLEIe9mkC -aXbgKgNPt2UfGiCLMHwCFv8SWuVcgZg2ZjM15c8zadEC0y/fAlk8O620cVuVnBFf -bIoiGJFcV4ZPOzrx6D1VFsOI06AGyNQR5c5dOl9qeacguSQdZ9+G+ujIPp0qm+Em -YE02AFyzxXVHa3DDyhzObAzkfv6jOTYtwLxpSBMiP5CCg4VqyCXi8pbtlvOykE7H -wGbNJoECgYEA+org3sbvpFipKF/UWuCKpZ485U4S8a1p+IAcUloM152PIMFPIcyb -ECtjZu1N/jXSYjyCOeTCXM33xMaoUCNzJibrVEe/u2BLrcYgadm4VLRWjwzDEBON -Avg9/QJr+RsithRryslkeF0sD9GL8OQkCXH919+kD8hkL2+10gMPSwkCgYEAzyy/ -c80EP8D0ALyjeg+Kklg11sWR/eXfmiy9iErfa1jQRbNQ7zmch8rBwUvScPklQgyj -Ze2ENxrBDgDFknysKB4Kd+yTnsybQF6vw3MfDNz6gvPR9f+2we24haHjZVniEXqy -WCpQPl4/wrEgssTIE1MwJQme81Fku+lHG7W8WrMCgYBh3tiDDhFVEPFbfTvWGDrx -AYRmSv5pfEWWNm1Z2iWEIN9lez4vRN8aDOjyrya1dE7v4xU4Cl3GpQrxymy7iW2U -7MUnEjQavT4y7t+AmfVA2YWqseCNKiX+j/yfFlAZank/yXBmMg/WWQc6UrAo9OYC -7o2rw4gyRiSkxy2ukVVrCQKBgQCyat8WY2FdZla8q7g9zlSQY9c59zwbZHSE2jL/ -xTtTv1DeNedlnj/n0f268glxsZ8cmrW9eid7LVdFL/T2itfYVMa/MMaQ47RwYxsL -P4FmGojDbidLq8VAjfFzZE/pYNcIJpqgwxAIJjLTAKggTMfhnKrBut9gvJ/8FJJg -ksp7cQKBgGOSnCskEs05TSLhKN+kdq/IDInQGPw8MI+dFCek4KpuK4IOjToLtG5D -Fz24+KcU/11EBMLQp3JAMwF9DFNNQQ0hzBo1ILDVJuk9QOT1FaYMIfZFjQgtGHyU -FSlG7RfVjV6pk3ayYqAlkEL31g3bXlYJC+yAGEDypF5ScgiX+d1d ------END RSA PRIVATE KEY----- diff --git a/ssltools/keys/server3.crt b/ssltools/keys/server3.crt deleted file mode 100644 index e69de29..0000000 --- a/ssltools/keys/server3.crt +++ /dev/null diff --git a/ssltools/keys/server3.csr b/ssltools/keys/server3.csr deleted file mode 100644 index e0a6ac3..0000000 --- a/ssltools/keys/server3.csr +++ /dev/null @@ -1,17 +0,0 @@ ------BEGIN CERTIFICATE REQUEST----- -MIICqjCCAZICAQAwZTELMAkGA1UEBhMCQVQxCzAJBgNVBAgTAk5BMRAwDgYDVQQH -EwdCSVNIS0VLMRQwEgYDVQQKEwtBTllUVU4tVEVTVDEhMB8GCSqGSIb3DQEJARYS -bWVAbXlob3N0Lm15ZG9tYWluMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC -AQEAyiyj24Xp9w3trMbzGyR0gQpGDMhIdJHU1AwW8EskMtNs1eCw5CYZZM20mm7k -vkWXMFdgwjFqKJjjnZuO/HUcYcJcmfJI91srEepThTGrNYiYTKnfJopWTALSRW5E -8F7P4pDby261jzQNCAlaOfWdXUagAOd8Tx7Dk5CNxY7M0Z4kuWt5x3AI1gFG0tb/ -heZrS1NSQ2RS4+BH/z9WY+f9l2QgchkieKZ+RFf5wsrvbkfaJy5kGirPP2+OxwDf -8zMIiee1SDaHRr8cb1b2xM7hbZyvWVDECfrHjf7lXWXMP0V6lxk3Z5Hi7Piaog7F -BJ0AB6Sg33jayt2Ett4p+2VsoQIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBABwd -OecA3Qodoa2xNm1JTJwRLhi841VRX9tKhrMhm0DbqX5Ifema5ALR1jigcldTh0VA -bfOolXS+kOlw33d9kHGGj/eQfOk5TJuc28jycMYFBAy9bpCSckrz9o7XTGA6h8LZ -sbA5oXdRU9IYPX6Q/fBdST6BdPZfllLYsNIaSxkg2waWuBIuH8gidtUNe1uUuA1X -OzleKi4PPy30bdGfcgjRUQyiTyas5KaCb5QpGjp3q0MfOVUq71BwLFmdSv60d+Rk -I0IbxzWcfrHuPjT29OYBZ8osQeyTLnDc4hEAePe3LxGp+KNqe4BZbMyoWg3TTKK7 -O7v3I7o+/06zLJPwG48= ------END CERTIFICATE REQUEST----- diff --git a/ssltools/keys/server3.key b/ssltools/keys/server3.key deleted file mode 100644 index 7a95892..0000000 --- a/ssltools/keys/server3.key +++ /dev/null @@ -1,27 +0,0 @@ ------BEGIN RSA PRIVATE KEY----- -MIIEpAIBAAKCAQEAyiyj24Xp9w3trMbzGyR0gQpGDMhIdJHU1AwW8EskMtNs1eCw -5CYZZM20mm7kvkWXMFdgwjFqKJjjnZuO/HUcYcJcmfJI91srEepThTGrNYiYTKnf -JopWTALSRW5E8F7P4pDby261jzQNCAlaOfWdXUagAOd8Tx7Dk5CNxY7M0Z4kuWt5 -x3AI1gFG0tb/heZrS1NSQ2RS4+BH/z9WY+f9l2QgchkieKZ+RFf5wsrvbkfaJy5k -GirPP2+OxwDf8zMIiee1SDaHRr8cb1b2xM7hbZyvWVDECfrHjf7lXWXMP0V6lxk3 -Z5Hi7Piaog7FBJ0AB6Sg33jayt2Ett4p+2VsoQIDAQABAoIBAQDFXwcojHd4hNR/ -VEqJOPGz+D+iwvRZOPU5fgP22qSgKd+afRyz3q3zxw6FpbUSPAX5X5RKgMtOjtPH -TdItjHcEySZ19B5fvVUyzDx1T6QBQzTLwxrjGTJeSnLU7W3H7Aeu/BRXaeE9yGbg -baDz7GCQax5RQ6wL4dC1Au4k69/w0mJpcKxTPlyF+7/PZIPGLV4uS0G88t6EjOQq -xoGYRtT5VwuVO2AGZaCjanbF/b6c3Vr2uuSmd/cItuclbltcVxs4OU7L4vY732XR -VK5X7/0Jy2/7OgHFHx4DnTrzG/QUQyOZ/SkeWv5rr/RVgjSE9y0AEdOmMw4lsRdv -b3pZG6xxAoGBAOfAyL/gTqgv6rlPG7SLtGatgPRbUyeho15bk0v1Zp3tfD7mqeH2 -IMwXblENag7uZ5mDwQoOk5mSWwHMtJbTsYio1YuTAsmK57mveCS6T5QuDO6GE2Aw -K4Vpi7Hx0LCUvxSklBMxDpaYIogqBYmLCgV6FgsmwzjQ1iVfo0VjvwJbAoGBAN9T -oLPWWKz9wyzxnuMoei7jFex+hxR4TiGUAimEq6t+pOmT/ERcJtJ8QMwoY2dATeMv -UccQ3q6XVnW4m4HZmiYkTkwxnjKrxAuA2USeS0wvUIa/k+Sha6F1DeECVoQIq2b/ -yQGYl1E79HcuuRZQid0v0gPaEbEtrhN1e925UQWzAoGAED3pk9DzkkPxblVF+sxD -s2J7hCSWWlOwsF84nn0vWOgY6gueYlCukb8eox2OjkdVCWQ7din5XCzupdyj12I0 -sgArHyIJcviCLvhGMkTAaQElNN4+o2Ic2re/65On7YgvMBIssn+gpxs4aFSRmMce -x617uAJacjPonivqtGU+MLsCgYEAvaHERpCO0a3U6jftA9ReE6wt9Jfn2aDiLy7/ -uwN1xfSO0ewf/GgHaxmo5/KvnYAD4xJOLWuMutG0z9dG7La6ZwLTHW3QeBRULrRl -SRfktjdC+Hh6e1v6Capcc6DJl+nIqXgu1VUdwBPZ3M3myiTvO8scWLr15O31734G -BNsUCnMCgYB9qQP0CrvA2EnNzu7KrC9a73dzpTF61faqycdc0fpVJ0a/HYUMY0nj -RCcykFFyUc/SKiBszSQ4/qjmN/3QEd60iamVVyqRlhUKwVq7i4PTnU/TQ6AErSwr -uisU8Gtw8F3FtiwJ6ww6flNvPu/oLWRtzWeRZjLK5pfybY74qqknvQ== ------END RSA PRIVATE KEY----- diff --git a/ssltools/keys/server4.crt b/ssltools/keys/server4.crt deleted file mode 100644 index e69de29..0000000 --- a/ssltools/keys/server4.crt +++ /dev/null diff --git a/ssltools/keys/server4.csr b/ssltools/keys/server4.csr deleted file mode 100644 index 6ec80ed..0000000 --- a/ssltools/keys/server4.csr +++ /dev/null @@ -1,17 +0,0 @@ ------BEGIN CERTIFICATE REQUEST----- -MIICqjCCAZICAQAwZTELMAkGA1UEBhMCQVQxCzAJBgNVBAgTAk5BMRAwDgYDVQQH -EwdCSVNIS0VLMRQwEgYDVQQKEwtBTllUVU4tVEVTVDEhMB8GCSqGSIb3DQEJARYS -bWVAbXlob3N0Lm15ZG9tYWluMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC -AQEAqmTK2Os0JYsNKnmbgtXOSDqIrcJa15UrJ4lWS/5k+Ub5jkzbYD6NX1DwmKXc -4w50/HOklL+jex+drLvUlPEStpcDy+MIKhOpY+v2jSidGEApStZUEZLpRHgE0s95 -gx4R9FhR/8vbjJfnjC58F/ZmWJN9XYEsImggMnLVL328SSlseTHcvh5lrtbFX/w1 -kWtcUjjLOq4UdEsTxiu0/MCU44xcLy9818u1iC2VlTKSUTUaMNS3tFitNnN8qkbG -gLB5YjmNm4X7jqIWrFqFGDxJquatRCECTuaWW314eZA6rap85S2Wp0yMO80DgheD -X9mR3S5Bzj2lHMFdpxcpuEdTzQIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBAAkK -42VWAAHM3lEqqOJUlx5sfHh3t1H+1lE6cVyFcoSu5hdazb9w+0tstlCsvYPQ8aIw -5T88DO5UyIvZuptM883sQFUONRjr45x5+xW+fGPuLS0nBfSnWEF02OBYq9C7n5+Y -l/aPLT9ft7O+Z89Lv9yDPTcx/cxpALFrHRtUAw9tqfMiuAr+NGu7dTeA421aFcB9 -b6aagWAZBx6TN+b0snxfJmPNun+HhoR2vT6yoxE8tEAeRdYTASaZpR7HBUgquYrJ -EyFlfRRynGYKGOO300FqT8Jzxu7OJcqKQVdKLIyVDyn4F2NHiOuRVElZQVkVf5CN -a+mNb4V8Z9WDCb6ueeI= ------END CERTIFICATE REQUEST----- diff --git a/ssltools/keys/server4.key b/ssltools/keys/server4.key deleted file mode 100644 index 8f5e2bc..0000000 --- a/ssltools/keys/server4.key +++ /dev/null @@ -1,27 +0,0 @@ ------BEGIN RSA PRIVATE KEY----- -MIIEpAIBAAKCAQEAqmTK2Os0JYsNKnmbgtXOSDqIrcJa15UrJ4lWS/5k+Ub5jkzb -YD6NX1DwmKXc4w50/HOklL+jex+drLvUlPEStpcDy+MIKhOpY+v2jSidGEApStZU -EZLpRHgE0s95gx4R9FhR/8vbjJfnjC58F/ZmWJN9XYEsImggMnLVL328SSlseTHc -vh5lrtbFX/w1kWtcUjjLOq4UdEsTxiu0/MCU44xcLy9818u1iC2VlTKSUTUaMNS3 -tFitNnN8qkbGgLB5YjmNm4X7jqIWrFqFGDxJquatRCECTuaWW314eZA6rap85S2W -p0yMO80DgheDX9mR3S5Bzj2lHMFdpxcpuEdTzQIDAQABAoIBAAkJl4ix0O481dHu -6USjOnGySRWOPWs5yjQqoJ0fPRPLo+jcQrZ0GuN3U4uFIJYaajIJoC0TjQQ2xRIo -VDoiHy/4CoeB3yj8KfvWxBjwkoR6wrXpcEQOWrj69KaJwpQlwCYJmS/MDDUEyY8x -1/sdYohIKloPQ9v/UdXbKVt/e8EVjzd++Lls+2Cn5/dH61BcJsIHgzhA9cXSr8i3 -K8gD9T2drO5EOjf59g5HHIX5glotSLJoT+KLCUX3VhH/lz/OqBT1xVwz8t1eNT1G -0pEHPHAbGbTbbHdjB7B3DsOmHJLUWu+RapyJluCmd+2WJGJ2Ohe6FuTD72TNYPOs -6vicjgECgYEA0d9BO6vZ7Ch0/xjbD+VzYtWoLwMkCzeK5apRCk5qPGE+prLcLBAz -3TuK2E/gaqeKHuanLhvSsIk45i1drAf8XLFrFHKZrNJF8hAYuhryJOf8ZbaPkx91 -YJxQfbKvoZpzxdGz1jf3QCEo9ITaplbV6T6s6SbBEpXl/6YtcljHoiECgYEAz9g7 -cG87k+rj8CtyQ2eprZ2vvrOMicTRcVHXY76PHAB38Uq/sIHDAA02av/xNdOG1G0o -8yTUETlo1gV6iip/GAFjXZ4S97v8gNsAHE7COpwQJfkCwSta45fK7/jktLKE8kts -CjvDz+qF97ZiIaFrm87OCqv94uVdJyHE/fZdVC0CgYEAwqKlEdz3tr9yeZ4okx59 -mzyAxFDKXai+JO6GR+OfPK4G93xLGoZQQy1UP/YcL21/d9b7VpSxGc25Oib6h2/E -iIZ1wzng8Vj1S1/IPth8luOavQ3JK21yYw20zE4p+dqO4ffwK4wtvojCPbr0OG2x -5qWcoIGzbzQbYLNR1IknY2ECgYEAoDt3N2rJZ3OCXjlgUY6tROd4AXCyO9O8E7yg -bIkQEupZjW+u8AhZqMSG216NOo3kOAgftbMCunSj2btHiRTR/lOzowymWs5WD5DG -OQyOuFhwKpYaBYnC/AqdrPsYdiXaUGDM3ebNQpDuztWQOZUUPH3mYlvN0wo4El76 -Wz9/G9ECgYA/kXdXp5M3OjtKxg3fYx7fKVbfmYv+jfLURVwwiM1bwRufCEIqz91P -+lPb7QKSZufOYKl/TaUhbpmEq2m+//hoDaARTebUGe6lHnovSvkDryUG4wl+b5p0 -teGRlNahYUzTsiWTQCDo4FZPvpcaVANJJZZXzIONfDPdT5oj05c5Qg== ------END RSA PRIVATE KEY----- diff --git a/ssltools/openssl.cnf b/ssltools/openssl.cnf deleted file mode 100644 index 270b069..0000000 --- a/ssltools/openssl.cnf +++ /dev/null @@ -1,255 +0,0 @@ -# -# OpenSSL example configuration file. -# This is mostly being used for generation of certificate requests. -# - -# This definition stops the following lines choking if HOME isn't -# defined. -HOME = . -RANDFILE = $ENV::HOME/.rnd - -# Extra OBJECT IDENTIFIER info: -#oid_file = $ENV::HOME/.oid -oid_section = new_oids - -# To use this configuration file with the "-extfile" option of the -# "openssl x509" utility, name here the section containing the -# X.509v3 extensions to use: -# extensions = -# (Alternatively, use a configuration file that has only -# X.509v3 extensions in its main [= default] section.) - -[ new_oids ] - -# We can add new OIDs in here for use by 'ca' and 'req'. -# Add a simple OID like this: -# testoid1=1.2.3.4 -# Or use config file substitution like this: -# testoid2=${testoid1}.5.6 - -#################################################################### -[ ca ] -default_ca = CA_default # The default ca section - -#################################################################### -[ CA_default ] - -dir = $ENV::KEY_DIR # Where everything is kept -certs = $dir # Where the issued certs are kept -crl_dir = $dir # Where the issued crl are kept -database = $dir/index.txt # database index file. -new_certs_dir = $dir # default place for new certs. - -certificate = $dir/ca.crt # The CA certificate -serial = $dir/serial # The current serial number -crl = $dir/crl.pem # The current CRL -private_key = $dir/ca.key # The private key -RANDFILE = $dir/.rand # private random number file - -x509_extensions = usr_cert # The extentions to add to the cert - -# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs -# so this is commented out by default to leave a V1 CRL. -# crl_extensions = crl_ext - -default_days = 3650 # how long to certify for -default_crl_days= 30 # how long before next CRL -default_md = md5 # which md to use. -preserve = no # keep passed DN ordering - -# A few difference way of specifying how similar the request should look -# For type CA, the listed attributes must be the same, and the optional -# and supplied fields are just that :-) -policy = policy_match - -# For the CA policy -[ policy_match ] -countryName = match -stateOrProvinceName = match -organizationName = match -organizationalUnitName = optional -commonName = supplied -emailAddress = optional - -# For the 'anything' policy -# At this point in time, you must list all acceptable 'object' -# types. -[ policy_anything ] -countryName = optional -stateOrProvinceName = optional -localityName = optional -organizationName = optional -organizationalUnitName = optional -commonName = supplied -emailAddress = optional - -#################################################################### -[ req ] -default_bits = $ENV::KEY_SIZE -default_keyfile = privkey.pem -distinguished_name = req_distinguished_name -attributes = req_attributes -x509_extensions = v3_ca # The extentions to add to the self signed cert - -# Passwords for private keys if not present they will be prompted for -# input_password = secret -# output_password = secret - -# This sets a mask for permitted string types. There are several options. -# default: PrintableString, T61String, BMPString. -# pkix : PrintableString, BMPString. -# utf8only: only UTF8Strings. -# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). -# MASK:XXXX a literal mask value. -# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings -# so use this option with caution! -string_mask = nombstr - -# req_extensions = v3_req # The extensions to add to a certificate request - -[ req_distinguished_name ] -countryName = Country Name (2 letter code) -countryName_default = $ENV::KEY_COUNTRY -countryName_min = 2 -countryName_max = 2 - -stateOrProvinceName = State or Province Name (full name) -stateOrProvinceName_default = $ENV::KEY_PROVINCE - -localityName = Locality Name (eg, city) -localityName_default = $ENV::KEY_CITY - -0.organizationName = Organization Name (eg, company) -0.organizationName_default = $ENV::KEY_ORG - -# we can do this but it is not needed normally :-) -#1.organizationName = Second Organization Name (eg, company) -#1.organizationName_default = World Wide Web Pty Ltd - -organizationalUnitName = Organizational Unit Name (eg, section) -#organizationalUnitName_default = - -commonName = Common Name (eg, your name or your server\'s hostname) -commonName_max = 64 - -emailAddress = Email Address -emailAddress_default = $ENV::KEY_EMAIL -emailAddress_max = 40 - -# SET-ex3 = SET extension number 3 - -[ req_attributes ] -challengePassword = A challenge password -challengePassword_min = 4 -challengePassword_max = 20 - -unstructuredName = An optional company name - -[ usr_cert ] - -# These extensions are added when 'ca' signs a request. - -# This goes against PKIX guidelines but some CAs do it and some software -# requires this to avoid interpreting an end user certificate as a CA. - -basicConstraints=CA:FALSE - -# Here are some examples of the usage of nsCertType. If it is omitted -# the certificate can be used for anything *except* object signing. - -# This is OK for an SSL server. -# nsCertType = server - -# For an object signing certificate this would be used. -# nsCertType = objsign - -# For normal client use this is typical -# nsCertType = client, email - -# and for everything including object signing: -# nsCertType = client, email, objsign - -# This is typical in keyUsage for a client certificate. -# keyUsage = nonRepudiation, digitalSignature, keyEncipherment - -# This will be displayed in Netscape's comment listbox. -nsComment = "OpenSSL Generated Certificate" - -# PKIX recommendations harmless if included in all certificates. -subjectKeyIdentifier=hash -authorityKeyIdentifier=keyid,issuer:always - -# This stuff is for subjectAltName and issuerAltname. -# Import the email address. -# subjectAltName=email:copy - -# Copy subject details -# issuerAltName=issuer:copy - -#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem -#nsBaseUrl -#nsRevocationUrl -#nsRenewalUrl -#nsCaPolicyUrl -#nsSslServerName - -[ server ] - -# JY ADDED -- Make a cert with nsCertType set to "server" -basicConstraints=CA:FALSE -nsCertType = server -nsComment = "OpenSSL Generated Server Certificate" -subjectKeyIdentifier=hash -authorityKeyIdentifier=keyid,issuer:always - -[ v3_req ] - -# Extensions to add to a certificate request - -basicConstraints = CA:FALSE -keyUsage = nonRepudiation, digitalSignature, keyEncipherment - -[ v3_ca ] - - -# Extensions for a typical CA - - -# PKIX recommendation. - -subjectKeyIdentifier=hash - -authorityKeyIdentifier=keyid:always,issuer:always - -# This is what PKIX recommends but some broken software chokes on critical -# extensions. -#basicConstraints = critical,CA:true -# So we do this instead. -basicConstraints = CA:true - -# Key usage: this is typical for a CA certificate. However since it will -# prevent it being used as an test self-signed certificate it is best -# left out by default. -# keyUsage = cRLSign, keyCertSign - -# Some might want this also -# nsCertType = sslCA, emailCA - -# Include email address in subject alt name: another PKIX recommendation -# subjectAltName=email:copy -# Copy issuer details -# issuerAltName=issuer:copy - -# DER hex encoding of an extension: beware experts only! -# obj=DER:02:03 -# Where 'obj' is a standard or added object -# You can even override a supported extension: -# basicConstraints= critical, DER:30:03:01:01:FF - -[ crl_ext ] - -# CRL extensions. -# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. - -# issuerAltName=issuer:copy -authorityKeyIdentifier=keyid:always,issuer:always diff --git a/ssltools/vars b/ssltools/vars deleted file mode 100755 index ed16f9d..0000000 --- a/ssltools/vars +++ /dev/null @@ -1,49 +0,0 @@ -# easy-rsa parameter settings - -# NOTE: If you installed from an RPM, -# don't edit this file in place in -# /usr/share/openvpn/easy-rsa -- -# instead, you should copy the whole -# easy-rsa directory to another location -# (such as /etc/openvpn) so that your -# edits will not be wiped out by a future -# OpenVPN package upgrade. - -# This variable should point to -# the top level of the easy-rsa -# tree. -export D=`pwd` - -# This variable should point to -# the openssl.cnf file included -# with easy-rsa. -export KEY_CONFIG=$D/openssl.cnf - -# Edit this variable to point to -# your soon-to-be-created key -# directory. -# -# WARNING: clean-all will do -# a rm -rf on this directory -# so make sure you define -# it correctly! -export KEY_DIR=$D/keys - -# Issue rm -rf warning -echo NOTE: when you run ./clean-all, I will be doing a rm -rf on $KEY_DIR - -# Increase this to 2048 if you -# are paranoid. This will slow -# down TLS negotiation performance -# as well as the one-time DH parms -# generation process. -export KEY_SIZE=2048 - -# These are the default values for fields -# which will be placed in the certificate. -# Don't leave any of these fields blank. -export KEY_COUNTRY=AT -export KEY_PROVINCE=NA -export KEY_CITY=BISHKEK -export KEY_ORG="ANYTUN-TEST" -export KEY_EMAIL="me@myhost.mydomain" diff --git a/test-scripts/bin/anytun-svn b/test-scripts/bin/anytun-svn deleted file mode 100755 index 29931cb..0000000 --- a/test-scripts/bin/anytun-svn +++ /dev/null @@ -1,4 +0,0 @@ -#!/bin/bash -cd /home/otti/anytun -svn up | grep -v Revision && make -exit 0 diff --git a/test-scripts/bin/anytun-svn-run b/test-scripts/bin/anytun-svn-run deleted file mode 100755 index 077936b..0000000 --- a/test-scripts/bin/anytun-svn-run +++ /dev/null @@ -1,12 +0,0 @@ -#!/bin/bash -cd /home/otti/anytun -killall anytun -sleep 5 -./anytun -i 77.87.240.1 -n 77.87.244.1 255.255.252.0 & -./anytun -i 77.87.240.1 -p 4445 -d anytun0 -t tun -n 77.87.240.2 77.87.240.3 -r 89.106.215.29 -o 4445 -w 0 & -sleep 5 -ip route add 77.87.241.0/24 via 77.87.240.3 dev anytun0 -ip link set anytun0 mtu 1400 -sleep 3 -/etc/init.d/snmpd restart -exit 0 diff --git a/test-scripts/bin/anytun-svn-scripts b/test-scripts/bin/anytun-svn-scripts deleted file mode 100755 index ac2c94f..0000000 --- a/test-scripts/bin/anytun-svn-scripts +++ /dev/null @@ -1,3 +0,0 @@ -#!/bin/sh -cp -v /home/otti/anytun/test-scripts/bin/* /bin -cp -v /home/otti/anytun/test-scripts/cron/* /etc/cron.d diff --git a/test-scripts/cron/anytun b/test-scripts/cron/anytun deleted file mode 100644 index dbd8a04..0000000 --- a/test-scripts/cron/anytun +++ /dev/null @@ -1 +0,0 @@ -10 1 * * * otti /bin/anytun-svn diff --git a/test-scripts/cron/anytun-run b/test-scripts/cron/anytun-run deleted file mode 100644 index 9fbe022..0000000 --- a/test-scripts/cron/anytun-run +++ /dev/null @@ -1 +0,0 @@ -15 1 * * * root /bin/anytun-svn-run diff --git a/test-scripts/cron/anytun-scripts b/test-scripts/cron/anytun-scripts deleted file mode 100644 index 1a830e0..0000000 --- a/test-scripts/cron/anytun-scripts +++ /dev/null @@ -1 +0,0 @@ -13 1 * * * root /bin/anytun-svn-scripts |