internet-draft-satp.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
   2 <html lang="en"><head><title>secure anycast tunneling protocol (satp)</title>
   3 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   4 <meta name="description" content="secure anycast tunneling protocol (satp)">
   5 <meta name="keywords" content="satp, Internet-Draft, secure anycast tunneling protocol, anycast, tunnel, secure, protocol">
   6 <meta name="generator" content="xml2rfc v1.32 (http://xml.resource.org/)">
   7 <style type='text/css'><!--
   8         body {
   9                 font-family: verdana, charcoal, helvetica, arial, sans-serif;
  10                 font-size: small; color: #000; background-color: #FFF;
  11                 margin: 2em;
  12         }
  13         h1, h2, h3, h4, h5, h6 {
  14                 font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
  15                 font-weight: bold; font-style: normal;
  16         }
  17         h1 { color: #900; background-color: transparent; text-align: right; }
  18         h3 { color: #333; background-color: transparent; }
  19
  20         td.RFCbug {
  21                 font-size: x-small; text-decoration: none;
  22                 width: 30px; height: 30px; padding-top: 2px;
  23                 text-align: justify; vertical-align: middle;
  24                 background-color: #000;
  25         }
  26         td.RFCbug span.RFC {
  27                 font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
  28                 font-weight: bold; color: #666;
  29         }
  30         td.RFCbug span.hotText {
  31                 font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
  32                 font-weight: normal; text-align: center; color: #FFF;
  33         }
  34
  35         table.TOCbug { width: 30px; height: 15px; }
  36         td.TOCbug {
  37                 text-align: center; width: 30px; height: 15px;
  38                 color: #FFF; background-color: #900;
  39         }
  40         td.TOCbug a {
  41                 font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
  42                 font-weight: bold; font-size: x-small; text-decoration: none;
  43                 color: #FFF; background-color: transparent;
  44         }
  45
  46         td.header {
  47                 font-family: arial, helvetica, sans-serif; font-size: x-small;
  48                 vertical-align: top; width: 33%;
  49                 color: #FFF; background-color: #666;
  50         }
  51         td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
  52         td.author-text { font-size: x-small; }
  53
  54         /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
  55         a.info {
  56                 /* This is the key. */
  57                 position: relative;
  58                 z-index: 24;
  59                 text-decoration: none;
  60         }
  61         a.info:hover {
  62                 z-index: 25;
  63                 color: #FFF; background-color: #900;
  64         }
  65         a.info span { display: none; }
  66         a.info:hover span.info {
  67                 /* The span will display just on :hover state. */
  68                 display: block;
  69                 position: absolute;
  70                 font-size: smaller;
  71                 top: 2em; left: -5em; width: 15em;
  72                 padding: 2px; border: 1px solid #333;
  73                 color: #900; background-color: #EEE;
  74                 text-align: left;
  75         }
  76
  77         a { font-weight: bold; }
  78         a:link    { color: #900; background-color: transparent; }
  79         a:visited { color: #633; background-color: transparent; }
  80         a:active  { color: #633; background-color: transparent; }
  81
  82         p { margin-left: 2em; margin-right: 2em; }
  83         p.copyright { font-size: x-small; }
  84         p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
  85         table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
  86         td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
  87
  88         ol.text { margin-left: 2em; margin-right: 2em; }
  89         ul.text { margin-left: 2em; margin-right: 2em; }
  90         li      { margin-left: 3em; }
  91
  92         /* RFC-2629 <spanx>s and <artwork>s. */
  93         em     { font-style: italic; }
  94         strong { font-weight: bold; }
  95         dfn    { font-weight: bold; font-style: normal; }
  96         cite   { font-weight: normal; font-style: normal; }
  97         tt     { color: #036; }
  98         tt, pre, pre dfn, pre em, pre cite, pre span {
  99                 font-family: "Courier New", Courier, monospace; font-size: small;
 100         }
 101         pre {
 102                 text-align: left; padding: 4px;
 103                 color: #000; background-color: #CCC;
 104         }
 105         pre dfn  { color: #900; }
 106         pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
 107         pre .key { color: #33C; font-weight: bold; }
 108         pre .id  { color: #900; }
 109         pre .str { color: #000; background-color: #CFF; }
 110         pre .val { color: #066; }
 111         pre .rep { color: #909; }
 112         pre .oth { color: #000; background-color: #FCF; }
 113         pre .err { background-color: #FCC; }
 114
 115         /* RFC-2629 <texttable>s. */
 116         table.all, table.full, table.headers, table.none {
 117                 font-size: small; text-align: center; border-width: 2px;
 118                 vertical-align: top; border-collapse: collapse;
 119         }
 120         table.all, table.full { border-style: solid; border-color: black; }
 121         table.headers, table.none { border-style: none; }
 122         th {
 123                 font-weight: bold; border-color: black;
 124                 border-width: 2px 2px 3px 2px;
 125         }
 126         table.all th, table.full th { border-style: solid; }
 127         table.headers th { border-style: none none solid none; }
 128         table.none th { border-style: none; }
 129         table.all td {
 130                 border-style: solid; border-color: #333;
 131                 border-width: 1px 2px;
 132         }
 133         table.full td, table.headers td, table.none td { border-style: none; }
 134
 135         hr { height: 1px; }
 136         hr.insert {
 137                 width: 80%; border-style: none; border-width: 0;
 138                 color: #CCC; background-color: #CCC;
 139         }
 140 --></style>
 141 </head>
 142 <body>
 143 <table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
 144 <tr><td class="header">Network Working Group</td><td class="header">O. Gsenger</td></tr>
 145 <tr><td class="header">Internet-Draft</td><td class="header">March 2007</td></tr>
 146 <tr><td class="header">Expires: September 2, 2007</td><td class="header">&nbsp;</td></tr>
 147 </table></td></tr></table>
 148 <h1><br />secure anycast tunneling protocol (satp)<br />draft-gsenger-secure-anycast-tunneling-protocol-00</h1>
 149
 150 <h3>Status of this Memo</h3>
 151 <p>
 152 By submitting this Internet-Draft,
 153 each author represents that any applicable patent or other IPR claims of which
 154 he or she is aware have been or will be disclosed,
 155 and any of which he or she becomes aware will be disclosed,
 156 in accordance with Section&nbsp;6 of BCP&nbsp;79.</p>
 157 <p>
 158 Internet-Drafts are working documents of the Internet Engineering
 159 Task Force (IETF), its areas, and its working groups.
 160 Note that other groups may also distribute working documents as
 161 Internet-Drafts.</p>
 162 <p>
 163 Internet-Drafts are draft documents valid for a maximum of six months
 164 and may be updated, replaced, or obsoleted by other documents at any time.
 165 It is inappropriate to use Internet-Drafts as reference material or to cite
 166 them other than as &ldquo;work in progress.&rdquo;</p>
 167 <p>
 168 The list of current Internet-Drafts can be accessed at
 169 <a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
 170 <p>
 171 The list of Internet-Draft Shadow Directories can be accessed at
 172 <a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
 173 <p>
 174 This Internet-Draft will expire on September 2, 2007.</p>
 175
 176 <h3>Copyright Notice</h3>
 177 <p>
 178 Copyright &copy; The IETF Trust (2007).</p>
 179
 180 <h3>Abstract</h3>
 181
 182 <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.
 183
 184 </p>
 185 <a name="anchor1"></a><br /><hr />
 186 <a name="rfc.section.1"></a><h3>1.&nbsp;
 187 Introduction</h3>
 188
 189 <p>SATP is somehow a mixture of an generic encapsulation protocol as <a class='info' href='#RFC2784'>GRE<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, &ldquo;Generic Routing Encapsulation (GRE),&rdquo; March&nbsp;2000.</span><span>)</span></a> [1] and a secure tunneling protocol as <a class='info' href='#RFC2401'>IPsec<span> (</span><span class='info'>Kent, S. and R. Atkinson, &ldquo;Security Architecture for the Internet Protocol,&rdquo; November&nbsp;1998.</span><span>)</span></a> [2] in tunnel mode. To save some header overhead it uses the encryption technices of <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [3]. 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, &ldquo;Host Anycasting Service,&rdquo; November&nbsp;1993.</span><span>)</span></a> [4]
 190 </p>
 191 <a name="anchor2"></a><br /><hr />
 192 <a name="rfc.section.2"></a><h3>2.&nbsp;
 193 Motivation and usage scenarios</h3>
 194
 195 <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.
 196 </p>
 197 <a name="anchor3"></a><br /><hr />
 198 <a name="rfc.section.2.1"></a><h3>2.1.&nbsp;
 199 Usage scenarions</h3>
 200
 201 <a name="anchor4"></a><br /><hr />
 202 <a name="rfc.section.2.1.1"></a><h3>2.1.1.&nbsp;
 203 tunneling from unicast hosts over anycast routers to other unicast hosts</h3>
 204 <br /><hr class="insert" />
 205 <a name="tunnel_mode"></a>
 206
 207 <p>An example of SATP used to tunnel in a unicast client - anycast server model
 208 </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
 209                     --------- router -----------
 210                    /                            \
 211     unicast ------+---------- router ------------+------ unicast
 212     host           \                            /        host
 213                     --------- router -----------
 214
 215   unicast  | encrypted     |  anycast  | encrypted     |  unicast
 216   tunnel   | communication |  tunnel   | communication |  tunnel
 217   endpoint | using SATP    |  endpoint | using SATP    |  endpoint
 218 </pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Figure&nbsp;1&nbsp;</b></font><br /></td></tr></table><hr class="insert" />
 219
 220 <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.
 221 </p>
 222 <a name="anchor5"></a><br /><hr />
 223 <a name="rfc.section.2.1.2"></a><h3>2.1.2.&nbsp;
 224 tunneling from unicast hosts to anycast networks</h3>
 225 <br /><hr class="insert" />
 226 <a name="open_tunnel_mode"></a>
 227
 228 <p>An example of SATP used to encrypt data between a unicast host and anycast networks
 229 </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
 230                        -------Router -+---- DNS Server
 231                       /                \
 232                      /                  --- 6to4 Router
 233                     /
 234     unicast -------+----------Router --+--- DNS Server
 235     host            \                   \
 236                      \                   --- 6to4 Router
 237                       \
 238                        -------Router -+---- DNS Server
 239                                        \
 240                                         --- 6to4 Router
 241
 242   unicast  | encrypted     |  anycast  | plaintext
 243   tunnel   | communication |  tunnel   | anycast
 244   endpoint | using SATP    |  endpoint | services
 245
 246 </pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Figure&nbsp;2&nbsp;</b></font><br /></td></tr></table><hr class="insert" />
 247
 248 <a name="anchor6"></a><br /><hr />
 249 <a name="rfc.section.2.1.3"></a><h3>2.1.3.&nbsp;
 250 redundant tunnel connection of 2 networks</h3>
 251 <br /><hr class="insert" />
 252 <a name="connect_networks"></a>
 253
 254 <p>An example of SATP used to connect 2 networks
 255 </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
 256               Router -----------   ---------------Router
 257             /                   \ /                     \
 258     Network - Router ------------x                       Network
 259        A    \                   / \                     /   B
 260               Router -----------   ---------------Router
 261
 262             | packets       |  packets  |  packets      |
 263  plaintext  | get           |  take a   |  get          | plaintext
 264  packets    | de/encrypted  |  random   |  de/encrypted | packets
 265             |de/encapsulated|   path    |de/encapsulated|
 266
 267 </pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Figure&nbsp;3&nbsp;</b></font><br /></td></tr></table><hr class="insert" />
 268
 269 <p>Network A has multible routers, that act as gateway/tunnel endpoint to another network B. This is done to build a redundant encrpted 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 networks A 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.
 270 </p>
 271 <a name="anchor7"></a><br /><hr />
 272 <a name="rfc.section.2.2"></a><h3>2.2.&nbsp;
 273 Encapsulation</h3>
 274
 275 <p>SATP does not depend an which lower layer protocols is used, but it's most likely used on top of ip or udp. This section should only discuss some issues on ip and udp in combination with anycasting and tunnels.
 276
 277 </p><br /><hr class="insert" />
 278 <a name="transtort_udp"></a>
 279
 280 <p>Examples of SATP used with different lower layer and payload protocols
 281 </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
 282     +------+-----+-------------------------------+
 283     |      |     |      + ---------------+------ |
 284     | IPv6 | UDP | SATP | Ethernet 802.3 | ... | |
 285     |      |     |      +----------------+-----+ |
 286     +------+-----+-------------------------------+
 287
 288 Tunnelung of Ethernet over UDP/IPv6
 289
 290     +------+-----+---------------------------+
 291     |      |     |      +------+-----+-----+ |
 292     | IPv4 | UDP | SATP | IPv6 | UDP | RTP | |
 293     |      |     |      +------+-----+-----+ |
 294     +------+-----+---------------------------+
 295
 296 Tunneling of IPv6 over UDP/IPv4 with RTP payload
 297
 298     +------+-------------------------------+
 299     |      |      + ---------------+------ |
 300     | IPv6 | SATP | Ethernet 802.3 | ... | |
 301     |      |      +----------------+-----+ |
 302     +------+-------------------------------+
 303
 304 Tunnelung of Ethernet over IPv6
 305
 306     +------+---------------------------+
 307     |      |      +------+-----+-----+ |
 308     | IPv4 | SATP | IPv6 | UDP | RTP | |
 309     |      |      +------+-----+-----+ |
 310     +------+---------------------------+
 311
 312 Tunneling of IPv6 over IPv4 with RTP payload
 313 </pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Figure&nbsp;4&nbsp;</b></font><br /></td></tr></table><hr class="insert" />
 314
 315 <p>When using UDP no flow controll or retransmission is done, neigther by UDP nor anytun. The encapsulated protocol HAS TO take care of this tasks if needed. UDP however has a checksum of the complete udp datagram, so a packet gets discarded if there is a biterror in the payload
 316 </p>
 317 <a name="anchor8"></a><br /><hr />
 318 <a name="rfc.section.2.3"></a><h3>2.3.&nbsp;
 319 Fragmentation</h3>
 320
 321 <p>
 322            The only way of fully supporting fragmentation would be to syncronise fragments between all anycast servers. This is considered to be to much overhead, so there are two non perfect solutions for this 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.
 323
 324 </p>
 325 <a name="anchor9"></a><br /><hr />
 326 <a name="rfc.section.3"></a><h3>3.&nbsp;
 327 Protocol specification</h3>
 328
 329 <a name="anchor10"></a><br /><hr />
 330 <a name="rfc.section.3.1"></a><h3>3.1.&nbsp;
 331 Header format</h3>
 332 <br /><hr class="insert" />
 333 <a name="prot_header_table"></a>
 334
 335 <p>Protocol Format
 336 </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
 337         0                   1                   2                   3
 338       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
 339      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 340      |           sender ID           |         sequence number       | |
 341      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 342    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 343    | |              ....        payload        ...                   | |
 344    | |-------------------------------+-------------------------------+ |
 345    | | padding (OPT) | pad count(OPT)|         payload type          | |
 346    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 347    | ~                          MKI (OPTIONAL)                       ~ |
 348    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 349    | :                 authentication tag (RECOMMENDED)              : |
 350    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 351    |                                                                   |
 352    +- Encrypted Portion*                      Authenticated Portion ---+
 353 </pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Figure&nbsp;5&nbsp;</b></font><br /></td></tr></table><hr class="insert" />
 354
 355 <p>
 356 </p>
 357 <a name="anchor11"></a><br /><hr />
 358 <a name="rfc.section.3.2"></a><h3>3.2.&nbsp;
 359 sender ID</h3>
 360
 361 <p>The sender ID is a 8bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address
 362 </p>
 363 <a name="anchor12"></a><br /><hr />
 364 <a name="rfc.section.3.3"></a><h3>3.3.&nbsp;
 365 sequence number</h3>
 366
 367 <p>The sequenze number is a 24 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.
 368 </p>
 369 <a name="anchor13"></a><br /><hr />
 370 <a name="rfc.section.3.4"></a><h3>3.4.&nbsp;
 371 payload</h3>
 372
 373 <p>A packet of the type payload type (e.g. an IP packet).
 374 </p>
 375 <a name="anchor14"></a><br /><hr />
 376 <a name="rfc.section.3.5"></a><h3>3.5.&nbsp;
 377 padding (OPTINAL)</h3>
 378
 379 <p>Padding of max 255 ocitets.
 380 None of the pre-defined encryption transforms uses any padding; for
 381    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 padding field is present, than the padding count field MUST be set to the padding lenght.
 382 </p>
 383 <a name="anchor15"></a><br /><hr />
 384 <a name="rfc.section.3.6"></a><h3>3.6.&nbsp;
 385 padding count</h3>
 386
 387 <p>The number of octets of the padding field. This field is optional. It's presents 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.
 388 </p>
 389 <a name="anchor16"></a><br /><hr />
 390 <a name="rfc.section.3.7"></a><h3>3.7.&nbsp;
 391 payload type field</h3>
 392
 393 <p>The payload type field defines the payload protocol. ETHER TYPE protocol numerbers 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.
 394             <br /><hr class="insert" />
 395 <a name="prot_type_table"></a>
 396
 397 <p>Some examples for protocol types
 398 </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
 399 HEX
 400 0000 Reserved
 401 .... Reserved
 402 05DC Reserved
 403 0800 Internet IP (IPv4)
 404 6558 transparent ethernet bridging
 405 86DD IPv6
 406 </pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Figure&nbsp;6&nbsp;</b></font><br /></td></tr></table><hr class="insert" />
 407
 408
 409
 410 <a name="anchor17"></a><br /><hr />
 411 <a name="rfc.section.3.8"></a><h3>3.8.&nbsp;
 412 Encryption</h3>
 413
 414 <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, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [3]. This section will only discuss some small changes that HAVE TO be made.
 415 </p>
 416 <a name="anchor18"></a><br /><hr />
 417 <a name="rfc.section.A"></a><h3>Appendix A.&nbsp;
 418 The appan</h3>
 419
 420 <a name="rfc.references1"></a><br /><hr />
 421 <h3>4.&nbsp;References</h3>
 422 <table width="99%" border="0">
 423 <tr><td class="author-text" valign="top"><a name="RFC2784">[1]</a></td>
 424 <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>, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc2784.txt">Generic Routing Encapsulation (GRE)</a>,&rdquo; RFC&nbsp;2784, March&nbsp;2000.</td></tr>
 425 <tr><td class="author-text" valign="top"><a name="RFC2401">[2]</a></td>
 426 <td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>,&rdquo; RFC&nbsp;2401, November&nbsp;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>
 427 <tr><td class="author-text" valign="top"><a name="RFC3711">[3]</a></td>
 428 <td class="author-text">Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc3711.txt">The Secure Real-time Transport Protocol (SRTP)</a>,&rdquo; RFC&nbsp;3711, March&nbsp;2004.</td></tr>
 429 <tr><td class="author-text" valign="top"><a name="RFC1546">[4]</a></td>
 430 <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>, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc1546.txt">Host Anycasting Service</a>,&rdquo; RFC&nbsp;1546, November&nbsp;1993.</td></tr>
 431 </table>
 432
 433 <a name="rfc.authors"></a><br /><hr />
 434 <h3>Author's Address</h3>
 435 <table width="99%" border="0" cellpadding="0" cellspacing="0">
 436 <tr><td class="author-text">&nbsp;</td>
 437 <td class="author-text">Othmar Gsenger</td></tr>
 438 <tr><td class="author-text">&nbsp;</td>
 439 <td class="author-text">Puerstingerstr 32/7</td></tr>
 440 <tr><td class="author-text">&nbsp;</td>
 441 <td class="author-text">Saalfelden  5760</td></tr>
 442 <tr><td class="author-text">&nbsp;</td>
 443 <td class="author-text">AT</td></tr>
 444 <tr><td class="author" align="right">Phone:&nbsp;</td>
 445 <td class="author-text"></td></tr>
 446 <tr><td class="author" align="right">Email:&nbsp;</td>
 447 <td class="author-text"><a href="mailto:satp@gsenger.com">satp@gsenger.com</a></td></tr>
 448 <tr><td class="author" align="right">URI:&nbsp;</td>
 449 <td class="author-text"><a href="http://www.gsenger.com/satp/">http://www.gsenger.com/satp/</a></td></tr>
 450 </table>
 451 <a name="rfc.copyright"></a><br /><hr />
 452 <h3>Full Copyright Statement</h3>
 453 <p class='copyright'>
 454 Copyright &copy; The IETF Trust (2007).</p>
 455 <p class='copyright'>
 456 This document is subject to the rights,
 457 licenses and restrictions contained in BCP&nbsp;78,
 458 and except as set forth therein,
 459 the authors retain all their rights.</p>
 460 <p class='copyright'>
 461 This document and the information contained herein are provided
 462 on an &ldquo;AS IS&rdquo; basis and THE CONTRIBUTOR,
 463 THE ORGANIZATION HE/SHE REPRESENTS
 464 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
 465 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
 466 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
 467 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
 468 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
 469 PURPOSE.</p>
 470 <h3>Intellectual Property</h3>
 471 <p class='copyright'>
 472 The IETF takes no position regarding the validity or scope of any
 473 Intellectual Property Rights or other rights that might be claimed
 474 to pertain to the implementation or use of the technology
 475 described in this document or the extent to which any license
 476 under such rights might or might not be available; nor does it
 477 represent that it has made any independent effort to identify any
 478 such rights.
 479 Information on the procedures with respect to
 480 rights in RFC documents can be found in BCP&nbsp;78 and BCP&nbsp;79.</p>
 481 <p class='copyright'>
 482 Copies of IPR disclosures made to the IETF Secretariat and any
 483 assurances of licenses to be made available,
 484 or the result of an attempt made to obtain a general license or
 485 permission for the use of such proprietary rights by implementers or
 486 users of this specification can be obtained from the IETF on-line IPR
 487 repository at <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p>
 488 <p class='copyright'>
 489 The IETF invites any interested party to bring to its attention
 490 any copyrights,
 491 patents or patent applications,
 492 or other
 493 proprietary rights that may cover technology that may be required
 494 to implement this standard.
 495 Please address the information to the IETF at <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
 496 <h3>Acknowledgment</h3>
 497 <p class='copyright'>
 498 Funding for the RFC Editor function is provided by
 499 the IETF Administrative Support Activity (IASA).</p>
 500 </body></html>