draft-gsenger-secure-anycast-tunneling-protocol-01.txt

   1
   2
   3
   4 Network Working Group                                         O. Gsenger
   5 Internet-Draft                                          January 23, 2008
   6 Expires: July 26, 2008
   7
   8
   9                 secure anycast tunneling protocol (SATP)
  10            draft-gsenger-secure-anycast-tunneling-protocol-01
  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 July 26, 2008.
  36
  37 Copyright Notice
  38
  39    Copyright (C) The IETF Trust (2008).
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55 Gsenger                   Expires July 26, 2008                 [Page 1]
  56 \f
  57 Internet-Draft  secure anycast tunneling protocol (SATP)    January 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 methodes used by SRTP.  It can be used as
  67    an encrypted alternative to IP Encapsulation within IP [3] and
  68    Generic Routing Encapsulation (GRE) [4].  It supports both anycast
  69    receivers and senders.
  70
  71
  72 Table of Contents
  73
  74    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  75      1.1.  Notational Conventions . . . . . . . . . . . . . . . . . .  3
  76    2.  Motivation and usage scenarios . . . . . . . . . . . . . . . .  4
  77      2.1.  Usage scenarions . . . . . . . . . . . . . . . . . . . . .  4
  78        2.1.1.  Tunneling from unicast hosts over anycast routers
  79                to other unicast hosts . . . . . . . . . . . . . . . .  4
  80        2.1.2.  Tunneling from unicast hosts to anycast networks . . .  5
  81        2.1.3.  Redundant tunnel connection of 2 networks  . . . . . .  5
  82      2.2.  Encapsulation  . . . . . . . . . . . . . . . . . . . . . .  6
  83    3.  Using SATP on top of IP  . . . . . . . . . . . . . . . . . . .  8
  84      3.1.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . .  8
  85      3.2.  ICMP messages  . . . . . . . . . . . . . . . . . . . . . .  8
  86    4.  Protocol specification . . . . . . . . . . . . . . . . . . . .  9
  87      4.1.  Header format  . . . . . . . . . . . . . . . . . . . . . .  9
  88      4.2.  sequence number  . . . . . . . . . . . . . . . . . . . . .  9
  89      4.3.  sender ID  . . . . . . . . . . . . . . . . . . . . . . . .  9
  90      4.4.  MUX  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  91      4.5.  payload type field . . . . . . . . . . . . . . . . . . . . 10
  92      4.6.  payload  . . . . . . . . . . . . . . . . . . . . . . . . . 10
  93      4.7.  padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10
  94      4.8.  padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 10
  95      4.9.  MKI (OPTIONAL) . . . . . . . . . . . . . . . . . . . . . . 10
  96      4.10. authentication tag (RECOMMENDED) . . . . . . . . . . . . . 10
  97      4.11. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 11
  98    5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
  99      5.1.  Replay protection  . . . . . . . . . . . . . . . . . . . . 12
 100    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
 101    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
 102      7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
 103      7.2.  Informational References . . . . . . . . . . . . . . . . . 14
 104    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
 105    Intellectual Property and Copyright Statements . . . . . . . . . . 17
 106
 107
 108
 109
 110
 111 Gsenger                   Expires July 26, 2008                 [Page 2]
 112 \f
 113 Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
 114
 115
 116 1.  Introduction
 117
 118    SATP is a mixture of a generic encapsulation protocol like GRE [4]
 119    and a secure tunneling protocol as IPsec [5] in tunnel mode.  It can
 120    be used to build redundant virtual private network (VPN) connections.
 121    It supports peer to peer tunnels, where tunnel endpoints can be any
 122    combination of unicast, multicast or anycast hosts, so it defines a
 123    Host Anycast Service [6].  Encryption is done per packet, so the
 124    protocol is robust against packet loss and routing changes.  To save
 125    some header overhead it uses the encryption techniques of SRTP [1].
 126
 127 1.1.  Notational Conventions
 128
 129    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 130    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 131    document are to be interpreted as described in RFC2119 [2].
 132
 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 July 26, 2008                 [Page 3]
 168 \f
 169 Internet-Draft  secure anycast tunneling protocol (SATP)    January 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 gets encapsuleted into a SATP packet by
 203    a unicast host and gets transmitted to one of the anycast routers.
 204    It than gets decapsulated by the router.  This router makes a routing
 205    descision based on the underlying protocol and transmits a new SATP
 206    package to one or more unicast hosts depending on the routing
 207    descition.
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223 Gsenger                   Expires July 26, 2008                 [Page 4]
 224 \f
 225 Internet-Draft  secure anycast tunneling protocol (SATP)    January 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 routed to the DNS server.  This method
 256    can be used to tunnel between a clients and networks providing
 257    anycast services.  It can also be used the other way to virtually
 258    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 July 26, 2008                 [Page 5]
 280 \f
 281 Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
 282
 283
 284                                  Figure 3
 285
 286    Network A has multiple routers, that act as gateway/tunnel endpoints
 287    to another network B. This is done to build a redundant encrypted
 288    tunnel connection between the two networks.  All tunnel endpoints of
 289    network A share the same anycast address and all tunnel endpoints of
 290    network B share another anycast address.  When a packet from network
 291    A gets transmitted to network B, it first arrives on one of network
 292    A's border routers.  Which router is used is determined by network
 293    A's internal routing.  This router encapsulates the package and sends
 294    it to the anycast address of the network B routers.  The SATP packet
 295    arrives at one of network B's routers and gets decapsulated and
 296    routed to it's destination within network B.
 297
 298 2.2.  Encapsulation
 299
 300    SATP does not depend on which lower layer protocols is used, but this
 301    section 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 July 26, 2008                 [Page 6]
 336 \f
 337 Internet-Draft  secure anycast tunneling protocol (SATP)    January 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 July 26, 2008                 [Page 7]
 392 \f
 393 Internet-Draft  secure anycast tunneling protocol (SATP)    January 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 occure 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's Don't Fragment (DF)
 410    bit is set, than the DF bit of the outer IP header HAS TO be set as
 411    well.
 412
 413 3.2.  ICMP messages
 414
 415    ICMP messages MUST be relayed according to rfc2003 section 4 [3].
 416    This is needed for path MTU detection.
 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 July 26, 2008                 [Page 8]
 448 \f
 449 Internet-Draft  secure anycast tunneling protocol (SATP)    January 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 destinguish multible tunnel connections.
 496
 497
 498
 499
 500
 501
 502
 503 Gsenger                   Expires July 26, 2008                 [Page 9]
 504 \f
 505 Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
 506
 507
 508 4.5.  payload type field
 509
 510    The payload type field defines the payload protocol.  ETHER TYPE
 511    protocol numbers are used.  See IANA assigned ethernet numbers [7] .
 512    The values 0000-05DC are reserverd and MUST NOT be used.
 513
 514    Some examples for protocol types
 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 the 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 these transforms might use the RTP padding
 536    format, so a RTP like padding is supported.  If the padding count
 537    field is present, than the padding count field MUST be set to the
 538    padding lenght.
 539
 540 4.8.  padding count (OPTIONAL)
 541
 542    The number of octets of the padding field.  This field is optional.
 543    It's presence is signaled by the key management and not by this
 544    protocol.  If this field isn't present, the padding field MUST NOT be
 545    present as well.
 546
 547 4.9.  MKI (OPTIONAL)
 548
 549    The MKI (Master Key Identifier) is OPTIONAL and of configurable
 550    length.  See SRTP Section 3.1 [1] for details
 551
 552 4.10.  authentication tag (RECOMMENDED)
 553
 554    The authentication tag is RECOMMENDED and of configurable length.  It
 555    contains a cryptographic checksum of the sender ID, sequence number
 556
 557
 558
 559 Gsenger                   Expires July 26, 2008                [Page 10]
 560 \f
 561 Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
 562
 563
 564    and the encrypted portion, but not of the MKI.  On sender side
 565    encryption HAS TO be done before calculating the authentication tag.
 566    A receiver HAS TO calculate the authentication tag before decrypting
 567    the encrypted portion.
 568
 569 4.11.  Encryption
 570
 571    Encryption is done in the same way as for SRTP [1].  This section
 572    will only discuss some small changes that HAVE TO be made.  Please
 573    read SRTP RFC3711 section 3-9 [1] for details.
 574
 575    The least significant bits of SSRC are replaced by the sender ID and
 576    the rest is filled with zeros.  For the SRTP SEQ the 16 least
 577    significant bits of the SATP sequence number are used and the 16 most
 578    significant bits of the sequence number replace the 16 least
 579    significant bits of the SRTP ROC.
 580
 581    Difference between SRTP and SATP
 582
 583           0                   1                   2                   3
 584         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
 585        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 586        |                     SATP    sequence number                   |
 587        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 588                                       =
 589        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 590        | SRTP ROC least significant   |         SRTP SEQ               |
 591        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 592
 593
 594           0                   1                   2                   3
 595         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
 596        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 597        |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|       SATP sender ID          |
 598        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 599                                       =
 600        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 601        |                           SRTP SSRC                           |
 602        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 603
 604                                  Figure 7
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615 Gsenger                   Expires July 26, 2008                [Page 11]
 616 \f
 617 Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
 618
 619
 620 5.  Security Considerations
 621
 622    As SATP uses the same encrytion technics as SRTP [1], it shares the
 623    same security issues.  This section will only discuss some small
 624    changes.  Please read SRTP RFC3711 section 9 [1] for details.
 625
 626 5.1.  Replay protection
 627
 628    Replay protection is done by a replay list.  Every anycast receiver
 629    has it's own replay list, which SHOULDN'T be syncronised, because of
 630    massive overhead.  This leads to an additional possible attack.  A
 631    attacker is able to replay a captured packet once to every anycast
 632    receiver.  This attack is considered of be very unlikely, because
 633    multiple attack hosts in different loactions are needed to reach the
 634    seperate anycast receivers and the number of replays is limited to
 635    the count of receivers - 1.  Such replays might also happen because
 636    of routing problems, so a payload protocol HAS TO be robust against a
 637    small number of duplicated packages.  The window size and position
 638    HAS TO be syncronised between multible anycast receivers to limit
 639    this attack.
 640
 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 July 26, 2008                [Page 12]
 672 \f
 673 Internet-Draft  secure anycast tunneling protocol (SATP)    January 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 July 26, 2008                [Page 13]
 728 \f
 729 Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
 730
 731
 732 7.  References
 733
 734 7.1.  Normative References
 735
 736    [1]  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    [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 741         Levels", BCP 14, RFC 2119, March 1997.
 742
 743    [3]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
 744         October 1996.
 745
 746 7.2.  Informational References
 747
 748    [4]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
 749         "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
 750
 751    [5]  Kent, S. and R. Atkinson, "Security Architecture for the
 752         Internet Protocol", RFC 2401, November 1998.
 753
 754    [6]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
 755         Service", RFC 1546, November 1993.
 756
 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 July 26, 2008                [Page 14]
 784 \f
 785 Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
 786
 787
 788 URIs
 789
 790    [7]  <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 July 26, 2008                [Page 15]
 840 \f
 841 Internet-Draft  secure anycast tunneling protocol (SATP)    January 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 July 26, 2008                [Page 16]
 896 \f
 897 Internet-Draft  secure anycast tunneling protocol (SATP)    January 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 Acknowledgment
 943
 944    Funding for the RFC Editor function is provided by the IETF
 945    Administrative Support Activity (IASA).
 946
 947
 948
 949
 950
 951 Gsenger                   Expires July 26, 2008                [Page 17]
 952 \f