papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt

   1
   2
   3
   4 Network Working Group                                         O. Gsenger
   5 Internet-Draft                                                  May 2008
   6 Expires: November 2, 2008
   7
   8
   9                 secure anycast tunneling protocol (SATP)
  10            draft-gsenger-secure-anycast-tunneling-protocol-02
  11
  12 Status of this Memo
  13
  14    By submitting this Internet-Draft, each author represents that any
  15    applicable patent or other IPR claims of which he or she is aware
  16    have been or will be disclosed, and any of which he or she becomes
  17    aware will be disclosed, in accordance with Section 6 of BCP 79.
  18
  19    Internet-Drafts are working documents of the Internet Engineering
  20    Task Force (IETF), its areas, and its working groups.  Note that
  21    other groups may also distribute working documents as Internet-
  22    Drafts.
  23
  24    Internet-Drafts are draft documents valid for a maximum of six months
  25    and may be updated, replaced, or obsoleted by other documents at any
  26    time.  It is inappropriate to use Internet-Drafts as reference
  27    material or to cite them other than as "work in progress."
  28
  29    The list of current Internet-Drafts can be accessed at
  30    http://www.ietf.org/ietf/1id-abstracts.txt.
  31
  32    The list of Internet-Draft Shadow Directories can be accessed at
  33    http://www.ietf.org/shadow.html.
  34
  35    This Internet-Draft will expire on November 2, 2008.
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55 Gsenger                 Expires November 2, 2008                [Page 1]
  56 \f
  57 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
  58
  59
  60 Abstract
  61
  62    The secure anycast tunneling protocol (SATP) defines a protocol used
  63    for communication between any combination of unicast and anycast
  64    tunnel endpoints.  It allows tunneling of every ETHER TYPE protocol
  65    (ethernet, ip ...).  SATP directly includes cryptography and message
  66    authentication based on the methods used by the Secure Real-time
  67    Transport Protocol(SRTP) [RFC3711].  It can be used as an encrypted
  68    alternative to IP Encapsulation within IP [RFC2003] and Generic
  69    Routing Encapsulation (GRE) [RFC2784].  Both anycast receivers and
  70    senders are supported.
  71
  72
  73 Table of Contents
  74
  75    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  76      1.1.  Notational Conventions . . . . . . . . . . . . . . . . . .  3
  77    2.  Motivation and usage scenarios . . . . . . . . . . . . . . . .  4
  78      2.1.  Usage scenarions . . . . . . . . . . . . . . . . . . . . .  4
  79        2.1.1.  Tunneling from unicast hosts over anycast routers
  80                to other unicast hosts . . . . . . . . . . . . . . . .  4
  81        2.1.2.  Tunneling from unicast hosts to anycast networks . . .  5
  82        2.1.3.  Redundant tunnel connection of 2 networks  . . . . . .  5
  83      2.2.  Encapsulation  . . . . . . . . . . . . . . . . . . . . . .  6
  84    3.  Using SATP on top of IP  . . . . . . . . . . . . . . . . . . .  8
  85      3.1.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . .  8
  86      3.2.  ICMP messages  . . . . . . . . . . . . . . . . . . . . . .  8
  87    4.  Protocol specification . . . . . . . . . . . . . . . . . . . .  9
  88      4.1.  Header format  . . . . . . . . . . . . . . . . . . . . . .  9
  89      4.2.  sequence number  . . . . . . . . . . . . . . . . . . . . .  9
  90      4.3.  sender ID  . . . . . . . . . . . . . . . . . . . . . . . .  9
  91      4.4.  MUX  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  92      4.5.  payload type . . . . . . . . . . . . . . . . . . . . . . . 10
  93      4.6.  payload  . . . . . . . . . . . . . . . . . . . . . . . . . 10
  94      4.7.  padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10
  95      4.8.  padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 10
  96      4.9.  MKI (OPTIONAL) . . . . . . . . . . . . . . . . . . . . . . 10
  97      4.10. authentication tag (RECOMMENDED) . . . . . . . . . . . . . 10
  98      4.11. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 11
  99    5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
 100      5.1.  Replay protection  . . . . . . . . . . . . . . . . . . . . 12
 101    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
 102    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
 103      7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
 104      7.2.  Informational References . . . . . . . . . . . . . . . . . 14
 105    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
 106    Intellectual Property and Copyright Statements . . . . . . . . . . 17
 107
 108
 109
 110
 111 Gsenger                 Expires November 2, 2008                [Page 2]
 112 \f
 113 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 114
 115
 116 1.  Introduction
 117
 118    SATP is a mixture of a generic encapsulation protocol like GRE
 119    [RFC2784] and a secure tunneling protocol as IPsec [RFC2401] in
 120    tunnel mode.  It can be used to build redundant virtual private
 121    network (VPN) connections.  It supports peer-to-peer tunnels, where
 122    tunnel endpoints can be any combination of unicast, multicast or
 123    anycast hosts, so it defines a Host Anycast Service [RFC1546].
 124    Encryption is done per packet, so the protocol is robust against
 125    packet loss and routing changes.  To reduce header overhead,
 126    encryption techniques of SRTP [RFC3711] are being used.
 127
 128 1.1.  Notational Conventions
 129
 130    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 131    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 132    document are to be interpreted as described in RFC2119 [RFC2119].
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Gsenger                 Expires November 2, 2008                [Page 3]
 168 \f
 169 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 170
 171
 172 2.  Motivation and usage scenarios
 173
 174    This section gives an overview of possible usage scenarios.  Please
 175    note that the protocols used in the figures are only examples and
 176    that SATP itself does not care about either transport protocols or
 177    encapsulated protocols.  Routing is not done by SATP and each
 178    implemetation MAY choose it's own way of doing this task (e.g. using
 179    functions provided by the operating system).  SATP is used only to
 180    encapsulate and encrypt data.
 181
 182 2.1.  Usage scenarions
 183
 184 2.1.1.  Tunneling from unicast hosts over anycast routers to other
 185         unicast hosts
 186
 187    An example of SATP used to tunnel in a unicast client - anycast
 188    server model
 189
 190                        --------- router -----------
 191                       /                            \
 192        unicast ------+---------- router ------------+------ unicast
 193        host           \                            /        host
 194                        --------- router -----------
 195
 196      unicast  | encrypted     |  anycast  | encrypted     |  unicast
 197      tunnel   | communication |  tunnel   | communication |  tunnel
 198      endpoint | using SATP    |  endpoint | using SATP    |  endpoint
 199
 200                                  Figure 1
 201
 202    In this scenario the payload is encapsuleted into a SATP packet by a
 203    unicast host and gets transmitted to one of the anycast routers.
 204    After transmisson the packet gets decapsulated by the router.  This
 205    router makes a routing descision based on the underlying protocol and
 206    transmits a new SATP package to one or more unicast hosts depending
 207    on this decision.
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223 Gsenger                 Expires November 2, 2008                [Page 4]
 224 \f
 225 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 226
 227
 228 2.1.2.  Tunneling from unicast hosts to anycast networks
 229
 230    An example of SATP used to encrypt data between a unicast host and
 231    anycast networks
 232
 233                           -------Router -+---- DNS Server
 234                          /                \
 235                         /                  --- 6to4 Router
 236                        /
 237        unicast -------+----------Router --+--- DNS Server
 238        host            \                   \
 239                         \                   --- 6to4 Router
 240                          \
 241                           -------Router -+---- DNS Server
 242                                           \
 243                                            --- 6to4 Router
 244
 245      unicast  | encrypted     |  anycast  | plaintext
 246      tunnel   | communication |  tunnel   | anycast
 247      endpoint | using SATP    |  endpoint | services
 248
 249
 250                                  Figure 2
 251
 252    When the unicast hosts wants to transmit data to one of the anycast
 253    DNS servers, it encapsulates the data and sends a SATP packet to the
 254    anycast address of the routers.  The packet arrives at one of the
 255    routers, gets decapsulated and is then forwarded to the DNS server.
 256    This method can be used to tunnel between clients and networks
 257    providing anycast services.  It can also be used the other way to
 258    virtually locate a unicast service within anycasted networks.
 259
 260 2.1.3.  Redundant tunnel connection of 2 networks
 261
 262    An example of SATP used to connect 2 networks
 263
 264                  Router -----------   ---------------Router
 265                /                   \ /                     \
 266        Network - Router ------------x                       Network
 267           A    \                   / \                     /   B
 268                  Router -----------   ---------------Router
 269
 270                | packets       |  packets  |  packets      |
 271     plaintext  | get           |  take a   |  get          | plaintext
 272     packets    | de/encrypted  |  random   |  de/encrypted | packets
 273                |de/encapsulated|   path    |de/encapsulated|
 274
 275
 276
 277
 278
 279 Gsenger                 Expires November 2, 2008                [Page 5]
 280 \f
 281 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 282
 283
 284                                  Figure 3
 285
 286    Network A has multiple routers which act as gateway/tunnel endpoints
 287    to another network B. This way a redundant encrypted tunnel
 288    connection between the two networks is built up.  All tunnel
 289    endpoints of network A share the same anycast address and all tunnel
 290    endpoints of network B share another anycast address.  When a packet
 291    from network A is transmitted to network B, it first arrives on one
 292    of network A's border routers.  Which router is used is determined by
 293    network A's internal routing.  This router encapsulates the package
 294    and sends it to the anycast address of network B's routers.  After
 295    arrival the SATP packet gets decapsulated and routed to its
 296    destination within network B.
 297
 298 2.2.  Encapsulation
 299
 300    SATP does not depend on the lower layer protocol.  This section only
 301    gives an example of how packets could look like.
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335 Gsenger                 Expires November 2, 2008                [Page 6]
 336 \f
 337 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 338
 339
 340    Examples of SATP used with different lower layer and payload
 341    protocols
 342
 343        +------+-----+-------------------------------+
 344        |      |     |      +----------------+-----+ |
 345        | IPv6 | UDP | SATP | Ethernet 802.3 | ... | |
 346        |      |     |      +----------------+-----+ |
 347        +------+-----+-------------------------------+
 348
 349    Tunneling of Ethernet over UDP/IPv6
 350
 351        +------+-----+---------------------------+
 352        |      |     |      +------+-----+-----+ |
 353        | IPv4 | UDP | SATP | IPv6 | UDP | RTP | |
 354        |      |     |      +------+-----+-----+ |
 355        +------+-----+---------------------------+
 356
 357    Tunneling of IPv6 over UDP/IPv4 with RTP payload
 358
 359        +------+-------------------------------+
 360        |      |      +----------------+-----+ |
 361        | IPv6 | SATP | Ethernet 802.3 | ... | |
 362        |      |      +----------------+-----+ |
 363        +------+-------------------------------+
 364
 365    Tunneling of Ethernet over IPv6
 366
 367        +------+---------------------------+
 368        |      |      +------+-----+-----+ |
 369        | IPv4 | SATP | IPv6 | UDP | RTP | |
 370        |      |      +------+-----+-----+ |
 371        +------+---------------------------+
 372
 373    Tunneling of IPv6 over IPv4 with RTP payload
 374
 375                                  Figure 4
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391 Gsenger                 Expires November 2, 2008                [Page 7]
 392 \f
 393 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 394
 395
 396 3.  Using SATP on top of IP
 397
 398 3.1.  Fragmentation
 399
 400    The only way of fully supporting fragmentation would be to
 401    synchronise fragments between all anycast servers.  This is
 402    considered to be too much overhead, so there are two non-perfect
 403    solutions for these problems.  Either fragmentation HAS TO be
 404    disabled or if not all fragments arrive at the same server the IP
 405    datagramm HAS TO be discarded.  As routing changes are not expected
 406    to occur very frequently, the encapsulated protocol can do a
 407    retransmission and all fragments will arrive at the new server.
 408
 409    If the payload type is IP and the IP headers' Don't Fragment (DF) bit
 410    is set, then the DF bit of the outer IP header HAS TO be set as well.
 411
 412 3.2.  ICMP messages
 413
 414    ICMP messages MUST be relayed according to rfc2003 section 4
 415    [RFC2003].  This is needed for path MTU detection.
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Gsenger                 Expires November 2, 2008                [Page 8]
 448 \f
 449 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 450
 451
 452 4.  Protocol specification
 453
 454 4.1.  Header format
 455
 456    Protocol Format
 457
 458       0                   1                   2                   3
 459       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
 460      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 461      |                         sequence number                       | |
 462      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 463      |           sender ID           |              MUX              | |
 464    +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ |
 465    | |         payload type          |                               | |
 466    | +-------------------------------+                               | |
 467    | |              ....        payload        ...                   | |
 468    | |                               +-------------------------------+ |
 469    | |                               | padding (OPT) | pad count(OPT)| |
 470    +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+
 471    | ~                          MKI (OPTIONAL)                       ~ |
 472    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 473    | :                 authentication tag (RECOMMENDED)              : |
 474    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 475    |                                                                   |
 476    +- Encrypted Portion                       Authenticated Portion ---+
 477
 478                                  Figure 5
 479
 480 4.2.  sequence number
 481
 482    The sequence number is a 32 bit unsigned integer in network byte
 483    order.  It starts with a random value and is increased by 1 for every
 484    sent packet.  After the maximum value it starts over from 0.  This
 485    overrun causes the ROC to be increased.
 486
 487 4.3.  sender ID
 488
 489    The sender ID is a 16 bit unsigned integer.  It HAS TO be unique for
 490    every sender sharing the same anycast address.
 491
 492 4.4.  MUX
 493
 494    The MUX (multiplex) field is a 16 bit unsigned integer.  It is used
 495    to distinguish multiple tunnel connections.
 496
 497
 498
 499
 500
 501
 502
 503 Gsenger                 Expires November 2, 2008                [Page 9]
 504 \f
 505 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 506
 507
 508 4.5.  payload type
 509
 510    The payload type field defines the payload protocol.  ETHER TYPE
 511    protocol numbers are used.  See IANA assigned ethernet numbers [1] .
 512    The values 0000-05DC are reserverd and MUST NOT be used.
 513
 514    Some examples for protocol numbers
 515
 516    HEX
 517    0000 Reserved
 518    .... Reserved
 519    05DC Reserved
 520    0800 Internet IP (IPv4)
 521    6558 transparent ethernet bridging
 522    86DD IPv6
 523
 524                                  Figure 6
 525
 526 4.6.  payload
 527
 528    A packet of type payload type (e.g. an IP packet).
 529
 530 4.7.  padding (OPTIONAL)
 531
 532    Padding of max 255 octets.  None of the pre-defined encryption
 533    transforms uses any padding; for these, the plaintext and encrypted
 534    payload sizes match exactly.  Transforms are based on transforms of
 535    the SRTP protocol and therefore might use the RTP padding format, so
 536    a RTP-like padding is supported.  If the padding count field is
 537    present, the padding count field MUST be set to the padding length.
 538
 539 4.8.  padding count (OPTIONAL)
 540
 541    The number of octets of the padding field.  This field is optional.
 542    Its presence is signaled by the key management and not by this
 543    protocol.  If this field isn't present, the padding field MUST NOT be
 544    present as well.
 545
 546 4.9.  MKI (OPTIONAL)
 547
 548    The MKI (Master Key Identifier) is OPTIONAL and of configurable
 549    length.  See SRTP Section 3.1 [RFC3711] for details.
 550
 551 4.10.  authentication tag (RECOMMENDED)
 552
 553    The authentication tag is RECOMMENDED and of configurable length.  It
 554    contains a cryptographic checksum of the sender ID, sequence number
 555    and the encrypted portion, but not of the MKI.  On transmitter side
 556
 557
 558
 559 Gsenger                 Expires November 2, 2008               [Page 10]
 560 \f
 561 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 562
 563
 564    encryption HAS TO be done before calculating the authentication tag.
 565    A receiver HAS TO calculate the authentication tag before decrypting
 566    the encrypted portion.
 567
 568 4.11.  Encryption
 569
 570    Encryption is done in the same way as for SRTP [RFC3711].  This
 571    section will only discuss some small changes that HAVE TO be made.
 572    Please read SRTP RFC3711 section 3-9 [RFC3711] for details.
 573
 574    The least significant bits of SSRC are replaced by the sender ID and
 575    the most significant bits are replaced by the MUX.  For the SRTP SEQ
 576    the 16 least significant bits of the SATP sequence number are used
 577    and the 16 most significant bits of the sequence number replace the
 578    16 least significant bits of the SRTP ROC.
 579
 580    Difference between SRTP and SATP
 581
 582         0                   1                   2                   3
 583         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
 584        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 585        |                     SATP    sequence number                   |
 586        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 587                                        =
 588        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 589        |  SRTP ROC least significant   |           SRTP SEQ            |
 590        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 591
 592
 593         0                   1                   2                   3
 594         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
 595        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 596        |           SATP  MUX           |       SATP sender ID          |
 597        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 598                                        =
 599        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 600        |                           SRTP SSRC                           |
 601        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 602
 603                                  Figure 7
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615 Gsenger                 Expires November 2, 2008               [Page 11]
 616 \f
 617 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 618
 619
 620 5.  Security Considerations
 621
 622    As SATP uses the same encryption techniques as SRTP [RFC3711], it
 623    shares the same security issues.  This section will only discuss some
 624    small changes.  Please read SRTP RFC3711 section 9 [RFC3711] for
 625    details.
 626
 627 5.1.  Replay protection
 628
 629    Replay protection is done by a replay list.  Every anycast receiver
 630    has its own replay list, which SHOULDN'T be syncronised because of
 631    massive overhead.  This leads to an additional possible attack.  An
 632    attacker is able to replay a captured packet once to every anycast
 633    receiver.  This attack is considered be very unlikely because
 634    multiple attack hosts in different locations are needed to reach
 635    seperate anycast receivers and the number of replays is limited to
 636    count of receivers - 1.  Such replays might also happen because of
 637    routing problems, so a payload protocol HAS TO be robust against a
 638    small number of duplicated packages.  The window size and position
 639    HAS TO be syncronised between multiple anycast receivers to limit
 640    this attack.
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671 Gsenger                 Expires November 2, 2008               [Page 12]
 672 \f
 673 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 674
 675
 676 6.  IANA Considerations
 677
 678    The protocol is intended to be used on top of IP or on top of UDP (to
 679    be compatible with NAT routers), so UDP and IP protocol numbers have
 680    to be assiged by IANA.
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727 Gsenger                 Expires November 2, 2008               [Page 13]
 728 \f
 729 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 730
 731
 732 7.  References
 733
 734 7.1.  Normative References
 735
 736    [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
 737               Norrman, "The Secure Real-time Transport Protocol (SRTP)",
 738               RFC 3711, March 2004.
 739
 740    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 741               Requirement Levels", BCP 14, RFC 2119, March 1997.
 742
 743    [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
 744               October 1996.
 745
 746 7.2.  Informational References
 747
 748    [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
 749               Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
 750               March 2000.
 751
 752    [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
 753               Internet Protocol", RFC 2401, November 1998.
 754
 755    [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
 756               Anycasting Service", RFC 1546, November 1993.
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783 Gsenger                 Expires November 2, 2008               [Page 14]
 784 \f
 785 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 786
 787
 788 URIs
 789
 790    [1]  <http://www.iana.org/assignments/ethernet-numbers>
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839 Gsenger                 Expires November 2, 2008               [Page 15]
 840 \f
 841 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 842
 843
 844 Author's Address
 845
 846    Othmar Gsenger
 847    Puerstingerstr 32
 848    Saalfelden  5760
 849    AT
 850
 851    Phone:
 852    Email: satp@gsenger.com
 853    URI:   http://www.gsenger.com/satp/
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895 Gsenger                 Expires November 2, 2008               [Page 16]
 896 \f
 897 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 898
 899
 900 Full Copyright Statement
 901
 902    Copyright (C) The IETF Trust (2008).
 903
 904    This document is subject to the rights, licenses and restrictions
 905    contained in BCP 78, and except as set forth therein, the authors
 906    retain all their rights.
 907
 908    This document and the information contained herein are provided on an
 909    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 910    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 911    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 912    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 913    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 914    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 915
 916
 917 Intellectual Property
 918
 919    The IETF takes no position regarding the validity or scope of any
 920    Intellectual Property Rights or other rights that might be claimed to
 921    pertain to the implementation or use of the technology described in
 922    this document or the extent to which any license under such rights
 923    might or might not be available; nor does it represent that it has
 924    made any independent effort to identify any such rights.  Information
 925    on the procedures with respect to rights in RFC documents can be
 926    found in BCP 78 and BCP 79.
 927
 928    Copies of IPR disclosures made to the IETF Secretariat and any
 929    assurances of licenses to be made available, or the result of an
 930    attempt made to obtain a general license or permission for the use of
 931    such proprietary rights by implementers or users of this
 932    specification can be obtained from the IETF on-line IPR repository at
 933    http://www.ietf.org/ipr.
 934
 935    The IETF invites any interested party to bring to its attention any
 936    copyrights, patents or patent applications, or other proprietary
 937    rights that may cover technology that may be required to implement
 938    this standard.  Please address the information to the IETF at
 939    ietf-ipr@ietf.org.
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951 Gsenger                 Expires November 2, 2008               [Page 17]
 952 \f