





Internet Engineering Task Force                            Jeroen Massar
Internet Draft                                               Unfix/SixXS
Expiration Date: Mar 2004
                                                          September 2003


                          Heartbeat Protocol

               draft-massar-v6ops-heartbeat-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   This document proposes a heartbeat protocol for controlling 
   tunnel availability and allowing dynamic non-24/7 endnodes
   to use tunnels.















Massar, Jeroen            [Expires Mar 2004]                    [Page 1]

Internet Draft    draft-massar-v6ops-heartbeat-00.txt    September 2003

Table of Contents

   1.  Introduction  ...............................................   2
   2.  Heartbeat protocol ..........................................   3
     2.1. Heartbeat command ........................................   4
     2.2. Disable command ..........................................   4
   3.  Acknowledgements ............................................   5
   4.  Security Considerations .....................................   5
   5.  References ..................................................   6
   Author's Address ................................................   6

1. Introduction

   When operating a Tunnel Broker [RFC3053] or any other form of
   tunneling across the internet one doesn't want to send packets out
   to unsuspecting endpoints. Unsuspecting endpoints are hosts which
   don't expect traffic from the TB This is a common scenario when a
   non-static endpoint is used. The user enables the tunnel
   to the current endpoint, uses it and then disconnects from the
   internet or gets assigned another IP, due to dhcp policies or
   related reasons. The endpoint of the tunnel changes but there
   currently is no way of automatically changing that endpoint or
   notifying the POP that it has changed.

   Then another host get to use the IP and suddenly it receives our
   tunneled packets. Many hosts emply so called firewall or logging
   facilities that will start complaining about packets being sent
   from the Tunnel Broker which they perceive as malicious.

   The user of this firewall will in turn start complaining about abuse
   and hack attempts which takes up time from the persons running the
   Tunnel Broker staff and not even mentioning all the entites that
   will be notified by these type of messages.

   This protocol resolves this problem by specifying a heartbeat
   protocol. As long as the tunnel endpoint is able to send an
   authenticated heartbeat packet the tunnel is kept configured
   allowing two-way traffic to be sent. This heartbeat protocol also
   allows for automatic tunnel reconfiguration so that in the event
   of an IP change at the client side the tunnel will be reconfigured
   allowing continued service without notable interruption. If the
   Tunnel Broker's POP doesn't receive a heartbeat for a certain amount
   of time it can deem the endpoint as down and turn the tunnel down
   too. Taking these two into consideration will stop the sending of
   tunneled packets and will thus avoid the complaints which could
   have been brought up before.

   The implementation of this protocol will allow SixXS [SIXXS]
   users to request tunnels to dynamic endpoints that don't have to be
   reachable 24/7. This was before this protocol was implement one
   of the few requirements of obtaining a tunnel even when the project
   only consisted of one POP and was called IPng [IPNG].

   This protocol covers all tunneling protocols which use at least one
   set of inner and one set of outer addresses. Note that some of these
   protocols already have a heartbeat mechanism in the protocol.
   In those cases it is of course advisable to use that mechanism.









Massar, Jeroen            [Expires Mar 2004]                    [Page 2]

Internet Draft    draft-massar-v6ops-heartbeat-00.txt    September 2003

2. Heartbeat Protocol

   The heartbeat packet is a UDP [UDP] packet to port {IANA} of the
   tunnel's underlying endpoint. Schematically this will look like the 
   following diagram for a IPv6 in IPv4 (proto-41) tunnel [6IN4],
   which currently is widely used on the 6bone [6BONE]. Note that
   this protocol is not limited to 6in4 but can also be used together
   with for example GRE [GRE], IPXIP [IPXIP] and PPTP [PPTP].
   This setup is also used for the other examples in this document.

   +--------+                               +--------+
   | Client | <--- IPv6 in IPv4 Tunnel ---> | Server |
   +--------+                               +--------+

   Server's Outer IPv4: 172.16.1.2
   Server's Inner IPv6: 2001:db8::1/64
   Client's Outer IPv4: 10.100.13.42
   Client's Inner IPv6: 2001:db8::2/64

   A tunnel has both 'outer' IP's, the public addresses over which 
   the tunneled packets are sent and 'inner' IP's, the addresses 
   assigned to the tunnel endpoints. The Server will be referred
   to as POP (Point of presence) in the rest of this document.

   The heartbeat packet consists out of one single string separated
   by spaces and ending in a NULL. The first string is a 'command', 
   allowing extension of this protocol if needed.
   The basic heartbeat packet looks like:

    <packet> ::= <command> <SP> <signature> <NULL>

    <signature> ::= <cleartext-password> | <md5-signature>

    <md5-signature> ::= <string>

    <string> ::= <char> | <char> <string>

    <SP> ::= <whitespace>

    <NULL> ::= the NULL character (ASCII code 0)

   The packet must be constructed first with the signature containing
   the password for the tunnel. After construction the md5-signature
   should be calculated and then replace the cleartext-password.
   The packet can then be sent onto the network.











Massar, Jeroen            [Expires Mar 2004]                    [Page 3]

Internet Draft    draft-massar-v6ops-heartbeat-00.txt    September 2003

   The currently defined commands HEARTBEAT and DISABLE both use the
   following common options to identify the tunnel for which this
   heartbeat is meant:

    <common-options> ::= (HOST <host-options> | 
                          TUNNEL <tunnel-options>) <SP> <epochtime>

    <host-options> ::= <endpoint>

    <tunnel-options> ::= <outer endpoint> <SP> <inner endpoint>

    <outer endpoint> ::= <endpoint>

    <inner endpoint> ::= <endpoint>

    <endpoint> ::= <ipv4-address> | <ipv6-address> | <...>

2.1. Heartbeat Command

   This command is the main reason for this protocol to exist.
   It tells the POP that the current endpoint specified by both
   the UDP's source address and the common-option's outer endpoint
   is still accepting tunneled packets.

   Specification:
      <command> ::= HEARTBEAT <SP> <common-options>

   Example's:
      C: HEARTBEAT HOST 10.100.13.42 1525322
      C: HEARTBEAT TUNNEL 2001:db8::2 10.100.13.42 121313

2.2. Disable Command

   The disable command explicitly sets a tunnel 'down' on the POP
   allowing a gracious and prompt shutdown of the tunnel on the POP.
   One could even employ this command to stop huge traffic flows to
   the local endpoint which maybe could not cope with the traffic
   passed over it through the tunnel.

   Specification:
      <command> ::= DISABLE <SP> <common-options>

   Example:
      C: DISABLE 10.100.13.42 2001:db8::2/64 2003-02-17 01:04












Massar, Jeroen            [Expires Mar 2004]                    [Page 4]

Internet Draft    draft-massar-v6ops-heartbeat-00.txt    September 2003

3. Acknowledgements

   The protocol presented has formed during the existence of
   IPng [IPNG] and SixXS [SIXXS] to allow the users of these tunnel
   broker systems to have a dynamic non-static IPv4 endpoint.
   Thus I would like to thank the numberous users requesting the
   support for dynamic non-static tunnels.

4. Security Considerations

   The password used for creating the MD5 signature should never
   be made publicly available to 3rd parties otherwise that 3rd
   party could sign a packet and automatically reconfigure the tunnel
   endpoint. This could lead into the 3rd party sending traffic
   in both directions and thus posing as the actual user.

   The inclusion of the timestamp along with the verification on the
   POP side should guard against any replay attack. The POP must
   limit that the local clock compared to the timestamp from the
   packet should never differ for more than 2 minutes, this allows
   for at some latency and time-desync.

   Any packet that is not well formed or contains a invalid
   signature should be silently dropped.

   A side effect of this protocol is that whenever the local host
   cannot send a heartbeat in time to the POP that the POP will
   shutdown the tunnel. Envision a Denial of Service over the
   tunnel to the local endpoint. The local host's heartbeat cannot
   reach the POP which in turn will automatically disable the tunnel,
   allowing the host to catch some breath again and thus effectively
   implementing a poor mans rate limiting.


















Massar, Jeroen            [Expires Mar 2004]                    [Page 5]

Internet Draft    draft-massar-v6ops-heartbeat-00.txt    September 2003

5. Scenarios

5.1 Host heartbeat

5.2 IPv6 in IPv4 tunnel heartbeat

   This scenario handles the case where a IPv6 in IPv4 tunnel [6IN4] is
   setup between two hosts. This is the normal case for a Tunnel Broker
   system with which a IPv4 only host is given acces to a IPv6 network.
   A tunnel like this can easily be setup using the Tunnel Setup 
   Protocol [TSP] or similar protocols. A diagram of such a setup:

   +--------+                               +--------+
   | Client | <--- IPv6 in IPv4 Tunnel ---> | Server |
   +--------+                               +--------+

   Server's Outer IPv4: 172.16.1.2
   Server's Inner IPv6: 2001:db8::1/64
   Client's Outer IPv4: 10.100.13.42
   Client's Inner IPv6: 2001:db8::2/64
   Password           : hartslag

   The command would be:
   HEARTBEAT TUNNEL 2001:db8::2 10.100.13.42 1063665852 hartslag

   The data to be transmitted is:
   HEARTBEAT TUNNEL 2001:db8::2 10.100.13.42 1063665852 da46fdc28f568bb62d29661f73758095

   Note ofcourse that RFC1918 addresses will never reach a POP.

Massar, Jeroen            [Expires Mar 2004]                    [Page 6]

Internet Draft    draft-massar-v6ops-heartbeat-00.txt    September 2003

6. References

   [6BONE]     6Bone, "testbed for deployment of IPv6",
               http://www.6bone.net/

   [6IN4]      R. Gilligan, E. Nordmark,
               "Transition Mechanisms for IPv6 Hosts and Routers",
               August 2000, RFC2893

   [GRE]       D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina,
               "Generic Routing Encapsulation",
               March 2000, RFC2784

   [IPNG]      Pim van Pelt and Jeroen Massar,
               IPng, "IPv6 Enduser Deployment",
               http://www.ipng.nl

   [IPXIP]     Provan, D.,
               "Tunneling IPX Traffic through IP Networks",
               June 1991, RFC 1234

   [PPTP]      Hamzeh, K., et al.,
               "Point-to-Point Tunneling Protocol (PPTP)",
               July 1999, RFC 2637

   [SIXXS]     Jeroen Massar and Pim van Pelt,
               SixXS "IPv6 Deployment",
               http://www.sixxs.net

   [TCP]       DARPA,
               "Transmission Control Protocol (TCP)",
               September 1981, RFC 793

   [TSP]       Blanchet, M.,
               "Tunnel Setup Protocol",
               July 2001, draft-vg-ngtrans-tsp-01.txt

   [UDP]       Postel, J.,
               "User Datagram Protocol",
               August 1980, RFC 768

Author's Address

   Jeroen Massar
   Unfix/SixXS
   Hofpoldersingel 45
   2807 LW Gouda
   The Netherlands

   EMail: jeroen@unfix.org





Massar, Jeroen            [Expires Mar 2004]                    [Page 7]

