diff options
Diffstat (limited to 'papers')
3 files changed, 90 insertions, 98 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> diff --git a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt index e0169de..b0fb6bf 100644 --- a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt +++ b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt @@ -2,8 +2,8 @@ Network Working Group O. Gsenger -Internet-Draft May 6, 2008 -Expires: November 7, 2008 +Internet-Draft May 2008 +Expires: November 2, 2008 secure anycast tunneling protocol (SATP) @@ -32,11 +32,10 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 7, 2008. + This Internet-Draft will expire on November 2, 2008. + -Copyright Notice - Copyright (C) The IETF Trust (2008). @@ -52,7 +51,8 @@ Copyright Notice -Gsenger Expires November 7, 2008 [Page 1] + +Gsenger Expires November 2, 2008 [Page 1] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -64,10 +64,10 @@ Abstract 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 Secure Real-time - Transport Protocol(SRTP) [1]. It can be used as an encrypted - alternative to IP Encapsulation within IP [3] and Generic Routing - Encapsulation (GRE) [4]. Both anycast receivers and senders are - supported. + Transport Protocol(SRTP) [RFC3711]. It can be used as an encrypted + alternative to IP Encapsulation within IP [RFC2003] and Generic + Routing Encapsulation (GRE) [RFC2784]. Both anycast receivers and + senders are supported. Table of Contents @@ -108,28 +108,28 @@ Table of Contents -Gsenger Expires November 7, 2008 [Page 2] +Gsenger Expires November 2, 2008 [Page 2] Internet-Draft secure anycast tunneling protocol (SATP) May 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 - reduce header overhead ncryption techniques of SRTP [1] are being - used. + SATP is a mixture of a generic encapsulation protocol like GRE + [RFC2784] and a secure tunneling protocol as IPsec [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 Host Anycast Service [RFC1546]. + Encryption is done per packet, so the protocol is robust against + packet loss and routing changes. To reduce header overhead, + encryption techniques of SRTP [RFC3711] are being used. 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]. + document are to be interpreted as described in RFC2119 [RFC2119]. @@ -164,7 +164,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 3] +Gsenger Expires November 2, 2008 [Page 3] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -220,7 +220,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 4] +Gsenger Expires November 2, 2008 [Page 4] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -276,7 +276,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 5] +Gsenger Expires November 2, 2008 [Page 5] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -332,7 +332,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 6] +Gsenger Expires November 2, 2008 [Page 6] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -388,7 +388,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 7] +Gsenger Expires November 2, 2008 [Page 7] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -411,8 +411,8 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 3.2. ICMP messages - ICMP messages MUST be relayed according to rfc2003 section 4 [3]. - This is needed for path MTU detection. + ICMP messages MUST be relayed according to rfc2003 section 4 + [RFC2003]. This is needed for path MTU detection. @@ -444,7 +444,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 8] +Gsenger Expires November 2, 2008 [Page 8] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -500,7 +500,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 9] +Gsenger Expires November 2, 2008 [Page 9] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -508,7 +508,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 4.5. payload type The payload type field defines the payload protocol. ETHER TYPE - protocol numbers are used. See IANA assigned ethernet numbers [7] . + protocol numbers are used. See IANA assigned ethernet numbers [1] . The values 0000-05DC are reserverd and MUST NOT be used. Some examples for protocol numbers @@ -546,7 +546,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 4.9. MKI (OPTIONAL) The MKI (Master Key Identifier) is OPTIONAL and of configurable - length. See SRTP Section 3.1 [1] for details. + length. See SRTP Section 3.1 [RFC3711] for details. 4.10. authentication tag (RECOMMENDED) @@ -556,7 +556,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 10] +Gsenger Expires November 2, 2008 [Page 10] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -567,9 +567,9 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 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. + Encryption is done in the same way as for SRTP [RFC3711]. This + section will only discuss some small changes that HAVE TO be made. + Please read SRTP RFC3711 section 3-9 [RFC3711] for details. 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 @@ -612,16 +612,17 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 11] +Gsenger Expires November 2, 2008 [Page 11] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 5. Security Considerations - As SATP uses the same encryption techniques 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. + As SATP uses the same encryption techniques as SRTP [RFC3711], it + shares the same security issues. This section will only discuss some + small changes. Please read SRTP RFC3711 section 9 [RFC3711] for + details. 5.1. Replay protection @@ -667,8 +668,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - -Gsenger Expires November 7, 2008 [Page 12] +Gsenger Expires November 2, 2008 [Page 12] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -724,7 +724,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 -Gsenger Expires November 7, 2008 [Page 13] +Gsenger Expires November 2, 2008 [Page 13] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -733,26 +733,27 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 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. + [RFC3711] 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. + [RFC2119] 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. + [RFC2003] 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. + [RFC2784] 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. + [RFC2401] 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. + [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host + Anycasting Service", RFC 1546, November 1993. @@ -779,15 +780,14 @@ Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - -Gsenger Expires November 7, 2008 [Page 14] +Gsenger Expires November 2, 2008 [Page 14] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 URIs - [7] <http://www.iana.org/assignments/ethernet-numbers> + [1] <http://www.iana.org/assignments/ethernet-numbers> @@ -836,7 +836,7 @@ URIs -Gsenger Expires November 7, 2008 [Page 15] +Gsenger Expires November 2, 2008 [Page 15] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -892,7 +892,7 @@ Author's Address -Gsenger Expires November 7, 2008 [Page 16] +Gsenger Expires November 2, 2008 [Page 16] Internet-Draft secure anycast tunneling protocol (SATP) May 2008 @@ -939,14 +939,14 @@ Intellectual Property ietf-ipr@ietf.org. -Acknowledgment - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). -Gsenger Expires November 7, 2008 [Page 17] + + + +Gsenger Expires November 2, 2008 [Page 17] diff --git a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.xml b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.xml index b34df1e..f74eea1 100644 --- a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.xml +++ b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.xml @@ -51,7 +51,7 @@ <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 reduce header overhead ncryption techniques of <xref target="RFC3711">SRTP</xref> are being used. + To reduce header overhead, encryption techniques of <xref target="RFC3711">SRTP</xref> are being used. </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> |