diff options
| author | Othmar Gsenger <otti@anytun.org> | 2007-04-27 16:29:10 +0000 |
|---|---|---|
| committer | Othmar Gsenger <otti@anytun.org> | 2007-04-27 16:29:10 +0000 |
| commit | 4a059df9c351a97e1ba175e81fb2601deca79a05 (patch) | |
| tree | 357cae6a17b8c96283b3e8b47f1b05e2a74eb650 | |
| parent | IANA (diff) | |
auth
| -rw-r--r-- | internet-draft-satp.html | 50 | ||||
| -rw-r--r-- | internet-draft-satp.txt | 84 | ||||
| -rw-r--r-- | internet-draft-satp.xml | 16 |
3 files changed, 88 insertions, 62 deletions
diff --git a/internet-draft-satp.html b/internet-draft-satp.html index 82236da..1833a35 100644 --- a/internet-draft-satp.html +++ b/internet-draft-satp.html @@ -1,7 +1,7 @@ <!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> +<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="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'><!-- @@ -146,7 +146,7 @@ <tr><td class="header">Internet-Draft</td><td class="header">March 2007</td></tr> <tr><td class="header">Expires: September 2, 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> +<h1><br />secure anycast tunneling protocol (SATP)<br />draft-gsenger-secure-anycast-tunneling-protocol-00</h1> <h3>Status of this Memo</h3> <p> @@ -180,7 +180,7 @@ 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 (e.g. ethernet, ip, arp ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It is intended to deliver a generic, scaleable and secure solution for tunneling and relaying of packets of any protocol. +<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 (e.g. ethernet, ip, arp ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It is intended to deliver a generic, scaleable and secure solution for tunneling and relaying of packets of any protocol. </p><a name="toc"></a><br /><hr /> <h3>Table of Contents</h3> @@ -223,13 +223,17 @@ padding (OPTIONAL)<br /> padding count<br /> <a href="#anchor19">4.7.</a> payload type field<br /> - <a href="#anchor20">4.8.</a> + <a href="#anchor20">4.7.1.</a> +MKI<br /> + <a href="#anchor21">4.7.2.</a> +authentication tag<br /> + <a href="#anchor22">4.8.</a> Encryption<br /> -<a href="#anchor21">5.</a> +<a href="#anchor23">5.</a> Security Considerations<br /> - <a href="#anchor22">5.1.</a> + <a href="#anchor24">5.1.</a> Replay protection<br /> -<a href="#anchor23">6.</a> +<a href="#anchor25">6.</a> IANA Considerations<br /> <a href="#rfc.references1">7.</a> References<br /> @@ -443,7 +447,7 @@ Header format</h3> | : authentication tag (RECOMMENDED) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | - +- Encrypted Portion* Authenticated Portion ---+ + +- 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> @@ -491,7 +495,7 @@ padding count</h3> 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" /> + <br /><hr class="insert" /> <a name="prot_type_table"></a> <p>Some examples for protocol types @@ -505,9 +509,25 @@ HEX 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</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</h3> -<a name="anchor20"></a><br /><hr /> +<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 ofthe MKI. On sender side encryption HAS TO be done before calculating the authentication tag. A receiver HAS TO first calculate the authentication tag and than decrypt 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> @@ -542,21 +562,21 @@ Encryption</h3> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </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="anchor21"></a><br /><hr /> +<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>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="anchor22"></a><br /><hr /> +<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 SOULDN'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 reciever. 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="anchor23"></a><br /><hr /> +<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> diff --git a/internet-draft-satp.txt b/internet-draft-satp.txt index 4af2869..4359efa 100644 --- a/internet-draft-satp.txt +++ b/internet-draft-satp.txt @@ -6,7 +6,7 @@ Internet-Draft March 2007 Expires: September 2, 2007 - secure anycast tunneling protocol (satp) + secure anycast tunneling protocol (SATP) draft-gsenger-secure-anycast-tunneling-protocol-00 Status of this Memo @@ -54,12 +54,12 @@ Copyright Notice Gsenger Expires September 2, 2007 [Page 1] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 Abstract - The secure anycast tunneling protocol (satp) defines a protocol used + 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 (e.g. ethernet, ip, arp ...). SATP directly includes cryptography @@ -90,6 +90,8 @@ Table of Contents 4.5. padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 9 4.6. padding count . . . . . . . . . . . . . . . . . . . . . . 10 4.7. payload type field . . . . . . . . . . . . . . . . . . . . 10 + 4.7.1. MKI . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.7.2. authentication tag . . . . . . . . . . . . . . . . . . 10 4.8. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.1. Replay protection . . . . . . . . . . . . . . . . . . . . 12 @@ -106,11 +108,9 @@ Table of Contents - - Gsenger Expires September 2, 2007 [Page 2] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 1. Introduction @@ -166,7 +166,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 3] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 2. Motivation and usage scenarios @@ -222,7 +222,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 4] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 2.1.2. tunneling from unicast hosts to anycast networks @@ -278,7 +278,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 5] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 Figure 3 @@ -334,7 +334,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 6] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 Examples of SATP used with different lower layer and payload @@ -390,7 +390,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 7] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 3. Using SATP on top of IP @@ -446,7 +446,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 8] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 4. Protocol specification @@ -471,7 +471,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 | : authentication tag (RECOMMENDED) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | - +- Encrypted Portion* Authenticated Portion ---+ + +- Encrypted Portion Authenticated Portion ---+ Figure 5 @@ -502,7 +502,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 9] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 format, so a RTP like padding is supported. If padding field is @@ -534,33 +534,39 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Figure 6 -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. - - 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. - - - +4.7.1. MKI + The MKI (Master Key Identifier) is OPTIONAL and of configurable + length. See SRTP Section 3.1 [1] for details +4.7.2. authentication tag + 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 ofthe MKI. On sender side + encryption HAS TO be done before calculating the authentication tag. + A receiver HAS TO first calculate the authentication tag and than + decrypt 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 September 2, 2007 [Page 10] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 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 @@ -606,20 +612,14 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 - - - - - - Gsenger Expires September 2, 2007 [Page 11] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 5. Security Considerations - As satp uses the same encrytion technics as SRTP [1], it shares the + 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. @@ -670,7 +670,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 12] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 6. IANA Considerations @@ -726,7 +726,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 13] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 7. References @@ -782,7 +782,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Gsenger Expires September 2, 2007 [Page 14] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 URIs @@ -838,7 +838,7 @@ URIs Gsenger Expires September 2, 2007 [Page 15] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 Author's Address @@ -894,7 +894,7 @@ Author's Address Gsenger Expires September 2, 2007 [Page 16] -Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Internet-Draft secure anycast tunneling protocol (SATP) March 2007 Full Copyright Statement diff --git a/internet-draft-satp.xml b/internet-draft-satp.xml index c48dfa9..895f197 100644 --- a/internet-draft-satp.xml +++ b/internet-draft-satp.xml @@ -12,7 +12,7 @@ <?rfc toc='yes'?> <rfc ipr='full3978' docName='draft-gsenger-secure-anycast-tunneling-protocol-00'> <front> - <title>secure anycast tunneling protocol (satp)</title> + <title>secure anycast tunneling protocol (SATP)</title> <author initials='O.G.' surname='Gsenger' fullname='Othmar Gsenger'> @@ -44,7 +44,7 @@ <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 (e.g. ethernet, ip, arp ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It is intended to deliver a generic, scaleable and secure solution for tunneling and relaying of packets of any protocol. + <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 (e.g. ethernet, ip, arp ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It is intended to deliver a generic, scaleable and secure solution for tunneling and relaying of packets of any protocol. </t> </abstract> </front> @@ -194,7 +194,7 @@ Tunneling of IPv6 over IPv4 with RTP payload | : authentication tag (RECOMMENDED) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | - +- Encrypted Portion* Authenticated Portion ---+ + +- Encrypted Portion Authenticated Portion ---+ </artwork> </figure> <t></t> @@ -218,7 +218,7 @@ None of the pre-defined encryption transforms uses any padding; for </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"> + <figure anchor="prot_type_table"> <preamble>Some examples for protocol types</preamble> <artwork> HEX @@ -230,6 +230,12 @@ HEX 86DD IPv6 </artwork> </figure> + <section title="MKI"> + <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"> + <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 ofthe MKI. On sender side encryption HAS TO be done before calculating the authentication tag. A receiver HAS TO first calculate the authentication tag and than decrypt the encrypted portion.</t> + </section> </t> </section> <section title="Encryption"> @@ -262,7 +268,7 @@ HEX </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> + <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 SOULDN'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 reciever. 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> |