diff options
| author | Michael Gebetsroither <gebi@mgeb.org> | 2008-11-24 16:45:10 +0000 |
|---|---|---|
| committer | Michael Gebetsroither <gebi@mgeb.org> | 2008-11-24 16:45:10 +0000 |
| commit | bfd4996074678bcb65efa94f53a1476e6cec8329 (patch) | |
| tree | 2eccf22170d26b8cd8a276f16b9fa65d096adec0 /papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html | |
| parent | fixed builddep in readme (diff) | |
fixed typo
Signed-off-by: Michael Gebetsroither <gebi@sbox.tugraz.at>
Diffstat (limited to 'papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html')
| -rw-r--r-- | papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html | 56 |
1 files changed, 24 insertions, 32 deletions
diff --git a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html index 2374bb6..9be33dd 100644 --- a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html +++ b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html @@ -3,7 +3,7 @@ <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/)"> +<meta name="generator" content="xml2rfc v1.33 (http://xml.resource.org/)"> <style type='text/css'><!-- body { font-family: verdana, charcoal, helvetica, arial, sans-serif; @@ -143,8 +143,8 @@ <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">May 6, 2008</td></tr> -<tr><td class="header">Expires: November 7, 2008</td><td class="header"> </td></tr> +<tr><td class="header">Internet-Draft</td><td class="header">May 2008</td></tr> +<tr><td class="header">Expires: November 2, 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-02</h1> @@ -172,15 +172,11 @@ The list of current Internet-Drafts can be accessed at 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 November 7, 2008.</p> - -<h3>Copyright Notice</h3> -<p> -Copyright © The IETF Trust (2008).</p> +This Internet-Draft will expire on November 2, 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 methods used by the <a class='info' href='#RFC3711'>Secure Real-time Transport Protocol(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 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]. Both anycast receivers and senders are supported. +<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 methods used by the <a class='info' href='#RFC3711'>Secure Real-time Transport Protocol(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> [RFC3711]. 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> [RFC2003] 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> [RFC2784]. Both anycast receivers and senders are supported. </p><a name="toc"></a><br /><hr /> <h3>Table of Contents</h3> @@ -255,8 +251,8 @@ Intellectual Property and Copyright Statements<br /> <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 reduce header overhead ncryption 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] are being used. +<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> [RFC2784] 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> [RFC2401] 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> [RFC1546]. Encryption is done per packet, so the protocol is robust against packet loss and routing changes. + To reduce header overhead, 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> [RFC3711] are being used. </p> <a name="anchor2"></a><br /><hr /> @@ -264,7 +260,7 @@ Introduction</h3> <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>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> [RFC2119]. </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> @@ -419,7 +415,7 @@ Fragmentation</h3> <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>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> [RFC2003]. 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> @@ -529,7 +525,7 @@ padding count (OPTIONAL)</h3> <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>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> [RFC3711] 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> @@ -543,7 +539,7 @@ authentication tag (RECOMMENDED)</h3> <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>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> [RFC3711]. 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> [RFC3711] for details. </p> <p>The least significant bits of SSRC are replaced by the sender ID and the most significant bits are replaced by the MUX. 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" /> @@ -578,7 +574,7 @@ Encryption</h3> <a name="rfc.section.5"></a><h3>5. Security Considerations</h3> -<p>As SATP uses the same encryption techniques 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 encryption techniques 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> [RFC3711], 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> [RFC3711] 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> @@ -603,24 +599,24 @@ References</h3> <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> +<tr><td class="author-text" valign="top"><a name="RFC3711">[RFC3711]</a></td> +<td class="author-text">Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “<a href="http://tools.ietf.org/html/rfc3711">The Secure Real-time Transport Protocol (SRTP)</a>,” RFC 3711, March 2004 (<a href="ftp://ftp.isi.edu/in-notes/rfc3711.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td> +<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">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">[RFC2003]</a></td> +<td class="author-text"><a href="mailto:perk@watson.ibm.com">Perkins, C.</a>, “<a href="http://tools.ietf.org/html/rfc2003">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/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> +<tr><td class="author-text" valign="top"><a name="RFC2784">[RFC2784]</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="http://tools.ietf.org/html/rfc2784">Generic Routing Encapsulation (GRE)</a>,” RFC 2784, March 2000 (<a href="ftp://ftp.isi.edu/in-notes/rfc2784.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2401">[RFC2401]</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="http://tools.ietf.org/html/rfc2401">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">[RFC1546]</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="http://tools.ietf.org/html/rfc1546">Host Anycasting Service</a>,” RFC 1546, November 1993 (<a href="ftp://ftp.isi.edu/in-notes/rfc1546.txt">TXT</a>).</td></tr> </table> <a name="rfc.authors"></a><br /><hr /> @@ -688,8 +684,4 @@ 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> |