text:
[Docs] [txt|pdf] [draft-ietf-mobike...] [Diff1] [Diff2] [IPR]

Network Working Group                                         T. Kivinen
Request for Comments: 4621                                 Safenet, Inc.
Category: Informational                                    H. Tschofenig
                                                             August 2006

     Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

   The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension
   of the Internet Key Exchange Protocol version 2 (IKEv2).  These
   extensions should enable an efficient management of IKE and IPsec
   Security Associations when a host possesses multiple IP addresses
   and/or where IP addresses of an IPsec host change over time (for
   example, due to mobility).

   This document discusses the involved network entities and the
   relationship between IKEv2 signaling and information provided by
   other protocols.  Design decisions for the MOBIKE protocol,
   background information, and discussions within the working group are

Kivinen & Tschofenig         Informational                      [Page 1]

RFC 4621             Design of the MOBIKE Protocol           August 2006

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. Scenarios .......................................................6
      3.1. Mobility Scenario ..........................................6
      3.2. Multihoming Scenario .......................................7
      3.3. Multihomed Laptop Scenario .................................8
   4. Scope of MOBIKE .................................................8
   5. Design Considerations ..........................................10
      5.1. Choosing Addresses ........................................10
           5.1.1. Inputs and Triggers ................................11
           5.1.2. Connectivity .......................................11
           5.1.3. Discovering Connectivity ...........................12
           5.1.4. Decision Making ....................................12
           5.1.5. Suggested Approach .................................12
      5.2. NAT Traversal (NAT-T) .....................................12
           5.2.1. Background and Constraints .........................12
           5.2.2. Fundamental Restrictions ...........................13
           5.2.3. Moving behind a NAT and Back .......................13
           5.2.4. Responder behind a NAT .............................14
           5.2.5. NAT Prevention .....................................15
           5.2.6. Suggested Approach .................................15
      5.3. Scope of SA Changes .......................................15
      5.4. Zero Address Set Functionality ............................16
      5.5. Return Routability Check ..................................17
           5.5.1. Employing MOBIKE Results in Other Protocols ........19
           5.5.2. Return Routability Failures ........................20
           5.5.3. Suggested Approach .................................21
      5.6. IPsec Tunnel or Transport Mode ............................22
   6. Protocol Details ...............................................22
      6.1. Indicating Support for MOBIKE .............................22
      6.2. Path Testing and Window size ..............................23
      6.3. Message Presentation ......................................24
      6.4. Updating Address Set ......................................25
   7. Security Considerations ........................................26
   8. Acknowledgements ...............................................26
   9. References .....................................................27
      9.1. Normative references ......................................27
      9.2. Informative References ....................................27

Kivinen & Tschofenig         Informational                      [Page 2]

RFC 4621             Design of the MOBIKE Protocol           August 2006

1.  Introduction

   The purpose of IKEv2 is to mutually authenticate two hosts, to
   establish one or more IPsec Security Associations (SAs) between them,
   and subsequently to manage these SAs (for example, by rekeying or
   deleting).  IKEv2 enables the hosts to share information that is
   relevant to both the usage of the cryptographic algorithms that
   should be employed (e.g., parameters required by cryptographic
   algorithms and session keys) and to the usage of local security
   policies, such as information about the traffic that should
   experience protection.

   IKEv2 assumes that an IKE SA is created implicitly between the IP
   address pair that is used during the protocol execution when
   establishing the IKEv2 SA.  This means that, in each host, only one
   IP address pair is stored for the IKEv2 SA as part of a single IKEv2
   protocol session, and, for tunnel mode SAs, the host places this
   single pair in the outer IP headers.  Existing IPsec documents make
   no provision to change this pair after an IKE SA is created (except
   for dynamic address update of Network Address Translation Traversal

   There are scenarios where one or both of the IP addresses of this
   pair may change during an IPsec session.  In principle, the IKE SA
   and all corresponding IPsec SAs could be re-established after the IP
   address has changed.  However, this is a relatively expensive
   operation, and it can be problematic when such changes are frequent.
   Moreover, manual user interaction (for example, when using human-
   operated token cards (SecurID)) might be required as part of the
   IKEv2 authentication procedure.  Therefore, an automatic mechanism is
   needed that updates the IP addresses associated with the IKE SA and
   the IPsec SAs.  The MOBIKE protocol provides such a mechanism.

   The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306].  As
   IKEv2 is built on the IPsec architecture [RFC4301], all protocols
   developed within the MOBIKE working group must be compatible with
   both IKEv2 and the architecture described in RFC 4301.  This document
   does not discuss mobility and multi-homing support for IKEv1
   [RFC2409] or the obsoleted IPsec architecture described in RFC 2401

   This document is structured as follows: After some important terms
   are introduced in Section 2, a number of relevant usage scenarios are
   discussed in Section 3.  Section 4 describes the scope of the MOBIKE
   protocol.  Section 5 discusses design considerations affecting the
   MOBIKE protocol.  Section 6 investigates details regarding the MOBIKE
   protocol.  Finally, this document concludes in Section 7 with
   security considerations.

Kivinen & Tschofenig         Informational                      [Page 3]

RFC 4621             Design of the MOBIKE Protocol           August 2006

2.  Terminology

   This section introduces the terminology that is used in this

      A peer is an IKEv2 endpoint.  In addition, a peer implements the
      MOBIKE extensions, defined in [RFC4555].

   Available address

      An address is said to be available if the following conditions are

      *  The address has been assigned to an interface.

      *  If the address is an IPv6 address, we additionally require (a)
         that the address is valid as defined in RFC 2461 [RFC2461], and
         (b) that the address is not tentative as defined in RFC 2462
         [RFC2462].  In other words, we require the address assignment
         to be complete.

         Note that this explicitly allows an address to be optimistic as
         defined in [RFC4429].

      *  If the address is an IPv6 address, it is a global unicast or
         unique site-local address, as defined in [RFC4193].  That is,
         it is not an IPv6 link-local address.

      *  The address and interface is acceptable for sending and
         receiving traffic according to a local policy.

      This definition is taken from [WIP-Ark06] and adapted for the
      MOBIKE context.

   Locally operational address

      An address is said to be locally operational if it is available
      and its use is locally known to be possible and permitted.  This
      definition is taken from [WIP-Ark06].

   Operational address pair

      A pair of operational addresses are said to be an operational
      address pair if and only if bidirectional connectivity can be
      shown between the two addresses.  Note that sometimes it is
      necessary to consider connectivity on a per-flow level between two

Kivinen & Tschofenig         Informational                      [Page 4]

RFC 4621             Design of the MOBIKE Protocol           August 2006

      endpoints.  This differentiation might be necessary to address
      certain Network Address Translation types or specific firewalls.
      This definition is taken from [WIP-Ark06] and adapted for the
      MOBIKE context.  Although it is possible to further differentiate
      unidirectional and bidirectional operational address pairs, only
      bidirectional connectivity is relevant to this document, and
      unidirectional connectivity is out of scope.

      The sequence of routers traversed by the MOBIKE and IPsec packets
      exchanged between the two peers.  Note that this path may be
      affected not only by the involved source and destination IP
      addresses, but also by the transport protocol.  Since MOBIKE and
      IPsec packets have a different appearance on the wire, they might
      be routed along a different path, for example, due to load
      balancing.  This definition is taken from [RFC2960] and adapted to
      the MOBIKE context.

   Current path

      The sequence of routers traversed by an IP packet that carries the
      default source and destination addresses is said to be the Current
      Path.  This definition is taken from [RFC2960] and adapted to the
      MOBIKE context.

   Preferred address

      The IP address of a peer to which MOBIKE and IPsec traffic should
      be sent by default.  A given peer has only one active preferred
      address at a given point in time, except for the small time period
      where it switches from an old to a new preferred address.  This
      definition is taken from [WIP-Nik06] and adapted to the MOBIKE

   Peer address set

      We denote the two peers of a MOBIKE session by peer A and peer B.
      A peer address set is the subset of locally operational addresses
      of peer A that is sent to peer B. A policy available at peer A
      indicates which addresses are included in the peer address set.
      Such a policy might be created either manually or automatically
      through interaction with other mechanisms that indicate new
      available addresses.

Kivinen & Tschofenig         Informational                      [Page 5]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   Bidirectional address pair

      The address pair, where traffic can be sent to both directions,
      simply by reversing the IP addresses.  Note that the path of the
      packets going to each direction might be different.

   Unidirectional address pair

      The address pair, where traffic can only be sent in one direction,
      and reversing the IP addresses and sending reply back does not

   For mobility-related terminology (e.g., Make-before-break or Break-
   before-make), see [RFC3753].

3.  Scenarios

   In this section, we discuss three typical usage scenarios for the
   MOBIKE protocol.

3.1.  Mobility Scenario

   Figure 1 shows a break-before-make mobility scenario where a mobile
   node (MN) changes its point of network attachment.  Prior to the
   change, the mobile node had established an IPsec connection with a
   security gateway that offered, for example, access to a corporate
   network.  The IKEv2 exchange that facilitated the setup of the IPsec
   SA(s) took place over the path labeled as 'old path'.  The involved
   packets carried the MN's "old" IP address and were forwarded by the
   "old" access router (OAR) to the security gateway (GW).

   When the MN changes its point of network attachment, it obtains a new
   IP address using stateful or stateless address configuration.  The
   goal of MOBIKE, in this scenario, is to enable the MN and the GW to
   continue using the existing SAs and to avoid setting up a new IKE SA.
   A protocol exchange, denoted by 'MOBIKE Address Update', enables the
   peers to update their state as necessary.

   Note that in a break-before-make scenario the MN obtains the new IP
   address after it can no longer be reached at the old IP address.  In
   a make-before-break scenario, the MN is, for a given period of time,
   reachable at both the old and the new IP address.  MOBIKE should work
   in both of the above scenarios.

Kivinen & Tschofenig         Informational                      [Page 6]

RFC 4621             Design of the MOBIKE Protocol           August 2006

                          (Initial IKEv2 Exchange)
       Old IP   +--+        +---+                    v
       address  |MN|------> |OAR| -------------V     v
                +--+        +---+ Old path     V     v
                 .                          +----+   v>>>>> +--+
                 .move                      | R  | -------> |GW|
                 .                          |    |    >>>>> |  |
                 v                          +----+   ^      +--+
                +--+        +---+ New path     ^     ^
       New IP   |MN|------> |NAR|--------------^     ^
       address  +--+        +---+                    ^
                          (MOBIKE Address Update)

              ---> = Path taken by data packets
              >>>> = Signaling traffic (IKEv2 and MOBIKE)
              ...> = End host movement

                        Figure 1: Mobility Scenario

3.2.  Multihoming Scenario

   Another MOBIKE usage scenario is depicted in Figure 2.  In this
   scenario, the MOBIKE peers are equipped with multiple interfaces (and
   multiple IP addresses).  Peer A has two interface cards with two IP
   addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1
   and IP_B2.  Each peer selects one of its IP addresses as the
   preferred address, which is used for subsequent communication.
   Various reasons (e.g., hardware or network link failures) may require
   a peer to switch from one interface to another.

     +------------+                                  +------------+
     | Peer A     |           *~~~~~~~~~*            | Peer B     |
     |            |>>>>>>>>>> * Network   *>>>>>>>>>>|            |
     |      IP_A1 +-------->+             +--------->+ IP_B1      |
     |            |         |             |          |            |
     |      IP_A2 +********>+             +*********>+ IP_B2      |
     |            |          *           *           |            |
     +------------+           *~~~~~~~~~*            +------------+

              ---> = Path taken by data packets
              >>>> = Signaling traffic (IKEv2 and MOBIKE)
              ***> = Potential future path through the network
                     (if Peer A and Peer B change their preferred

                      Figure 2: Multihoming Scenario

Kivinen & Tschofenig         Informational                      [Page 7]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   Note that MOBIKE does not aim to support load balancing between
   multiple IP addresses.  That is, each peer uses only one of the
   available address pairs at a given point in time.

3.3.  Multihomed Laptop Scenario

   The third scenario we consider is about a laptop that has multiple
   interface cards and therefore several ways to connect to the network.
   It may, for example, have a fixed Ethernet card, a WLAN interface, a
   General Packet Radio Service (GPRS) adaptor, a Bluetooth interface,
   or USB hardware.  Not all interfaces are used for communication all
   the time for a number of reasons (e.g., cost, network availability,
   user convenience).  The policies that determine which interfaces are
   connected to the network at any given point in time is outside the
   scope of the MOBIKE protocol and, as such, this document.  However,
   as the laptop changes its point of attachment to the network, the set
   of IP addresses under which the laptop is reachable changes too.

   In all of these scenarios, even if IP addresses change due to
   interface switching or mobility, the IP address obtained via the
   configuration payloads within IKEv2 remain unaffected.  The IP
   address obtained via the IKEv2 configuration payloads allow the
   configuration of the inner IP address of the IPsec tunnel.  As such,
   applications might not detect any change at all.

4.  Scope of MOBIKE

   Getting mobility and multihoming actually working requires many
   different components to work together, including coordinating
   decisions between different layers, different mobility mechanisms,
   and IPsec/IKEv2.  Most of those aspects are beyond the scope of
   MOBIKE: MOBIKE focuses only on what two peers need in order to agree
   at the IKEv2 level (like new message formats and some aspects of
   their processing) required for interoperability.

   The MOBIKE protocol is not trying to be a full mobility protocol;
   there is no support for simultaneous movement or rendezvous
   mechanism, and there is no support for route optimization, etc.  The
   design document focuses on tunnel mode; everything going inside the
   tunnel is unaffected by the changes in the tunnel header IP address,
   and this is the mobility feature provided by the MOBIKE.  That is,
   applications running inside the MOBIKE-controlled IPsec tunnel might
   not detect the movement since their IP addresses remain constant.

Kivinen & Tschofenig         Informational                      [Page 8]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   The MOBIKE protocol should be able to perform the following
   operations (not all of which are done explicitly by the current

   o  Inform the other peer about the peer address set

   o  Inform the other peer about the preferred address

   o  Test connectivity along a path and thereby detect an outage

   o  Change the preferred address

   o  Change the peer address set

   o  Ability to deal with Network Address Translation devices

   Figure 3 shows an example protocol interaction between a pair of
   MOBIKE peers.  MOBIKE interacts with the packet processing module of
   the IPsec implementation using an internal API (such as those based
   on PF_KEY [RFC2367]).  Using this API, the MOBIKE module can create
   entries in the Security Association (SAD) and Security Policy
   Databases (SPD).  The packet processing module of the IPsec
   implementation may also interact with IKEv2 and MOBIKE module using
   this API.  The content of the Security Policy and Security
   Association Databases determines what traffic is protected with IPsec
   in which fashion.  MOBIKE, on the other hand, receives information
   from a number of sources that may run both in kernel-mode and in
   user-mode.  These sources form the basis on which MOBIKE makes
   decisions regarding the set of available addresses, the peer address
   set, and the preferred address.  Policies may also affect the
   selection process.

   The peer address set and the preferred address needs to be made
   available to the other peer.  In order to address certain failure
   cases, MOBIKE should perform connectivity tests between the peers
   (potentially over a number of different paths).  Although a number of
   address pairs may be available for such tests, the most important is
   the pair (source address, destination address) of the current path.
   This is because this pair is selected for sending and receiving
   MOBIKE signaling and IPsec traffic.  If a problem along this current
   path is detected (e.g., due to a router failure), it is necessary to
   switch to a new current path.  In order to be able to do so quickly,
   it may be helpful to perform connectivity tests of other paths
   periodically.  Such a technique would also help identify previously
   disconnected paths that become operational again.

Kivinen & Tschofenig         Informational                      [Page 9]

RFC 4621             Design of the MOBIKE Protocol           August 2006

     +---------------------+            +----------------+
     |    User-space       |            |                |
     |   Protocols and     |            |   MOBIKE and   |
     | Functions Relevant  |<---------->|  IKEv2 Module  |
     | MOBIKE (e.g., DHCP, |            |                |
     |     policies)       |            +----------------+
     +---------------------+                    ^
                ^                               |
                |                               |        User space
                |                               |      Kernel space
                |                               v
                |                       +----------------+
                v                       |                |
     +---------------------+            |  IPsec engine  |
     |   Kernel-space      |<---------->| (and databases)|
     |     Protocols       |            |                |
     |    Relevant for     |            +----------------+
     |  MOBIKE (e.g., ND,  |                    ^
     |     DNA, L2)        |<---------------+   |
     +---------------------+                v   v
            ||                          +----------------+
            \/                          |                |
          Inter-  =====================>| IP forwarding, |
          faces   <=====================|input and output|
                                        |                |

         ===> = IP packets arriving/leaving a MOBIKE node
         <->  = control and configuration operations

                            Figure 3: Framework

   Please note that Figure 3 illustrates an example of how a MOBIKE
   implementation could work.  It serves illustrative purposes only.

5.  Design Considerations

   This section discusses aspects affecting the design of the MOBIKE

5.1.  Choosing Addresses

   One of the core aspects of the MOBIKE protocol is the selection of
   the address for the IPsec packets we send.  Choosing addresses for
   the IKEv2 request is a somewhat separate problem.  In many cases,
   they will be the same (and in some design choice they will always be
   the same and could be forced to be the same by design).

Kivinen & Tschofenig         Informational                     [Page 10]

RFC 4621             Design of the MOBIKE Protocol           August 2006

5.1.1.  Inputs and Triggers

   How address changes are triggered is largely beyond the scope of
   MOBIKE.  The triggers can include changes in the set of addresses,
   various link-layer indications, failing dead peer detection, and
   changes in preferences and policies.  Furthermore, there may be less
   reliable sources of information (such as lack of IPsec packets and
   incoming ICMP packets) that do not trigger any changes directly, but
   rather cause Dead Peer Detection (DPD) to be scheduled earlier and,
   if it fails, it might cause a change of the preferred address.

   These triggers are largely the same as for other mobility protocols
   such as Mobile IP, and they are beyond the scope of MOBIKE.

5.1.2.  Connectivity

   There can be two kinds of connectivity "failures": local failures and
   path failures.  Local failures are problems locally at a MOBIKE peer
   (e.g., an interface error).  Path failures are a property of an
   address pair and failures of nodes and links along this path.  MOBIKE
   does not support unidirectional address pairs.  Supporting them would
   require abandoning the principle of sending an IKEv2 reply to the
   address from which the request came.  MOBIKE decided to deal only
   with bidirectional address pairs.  It does consider unidirectional
   address pairs as broken and does not use them, but the connection
   between peers will not break even if unidirectional address pairs are
   present, provided there is at least one bidirectional address pair
   MOBIKE can use.

   Note that MOBIKE is not concerned about the actual path used; it
   cannot even detect if some path is unidirectionally operational if
   the same address pair has some other unidirectional path back.
   Ingress filters might still cause such path pairs to be unusable, and
   in that case MOBIKE will detect that there is no operational address

   In a sense having both an IPv4 and an IPv6 address is basically a
   case of partial connectivity (putting both an IPv4 and an IPv6
   address in the same IP header does not work).  The main difference is
   that it is known beforehand; there is no need to discover that an
   IPv4/IPv6 combination does not work.

Kivinen & Tschofenig         Informational                     [Page 11]

RFC 4621             Design of the MOBIKE Protocol           August 2006

5.1.3.  Discovering Connectivity

   To detect connectivity, the MOBIKE protocol needs to have a mechanism
   to test connectivity.  If a MOBIKE peer receives a reply, it can be
   sure about the existence of a working (bidirectional) address pair.
   If a MOBIKE peer does not see a reply after multiple retransmissions,
   it may assume that the tested address pair is broken.

   The connectivity tests require congestion problems to be taken into
   account because the connection failure might be caused by congestion.
   The MOBIKE protocol should not make the congestion problem worse by
   sending many DPD packets.

5.1.4.  Decision Making

   One of the main questions in designing the MOBIKE protocol was who
   makes the decisions how to fix a situation when failure is detected,
   e.g., symmetry vs. asymmetry in decision making.  Symmetric decision
   making (i.e., both peers can make decisions) may cause the different
   peers to make different decisions, thus causing asymmetric upstream/
   downstream traffic.  In the mobility case, it is desirable that the
   mobile peer can move both upstream and downstream traffic to some
   particular interface, and this requires asymmetric decision making
   (i.e. only one peer makes decisions).

   Working with stateful packet filters and NATs is easier if the same
   address pair is used in both upstream and downstream directions.
   Also, in common cases, only the peer behind NAT can actually perform
   actions to recover from the connectivity problems, as the other peer
   might not be able to initiate any connections to the peer behind NAT.

5.1.5.  Suggested Approach

   The working group decided to select a method whereby the initiator
   will decide which addresses are used.  As a consequence, the outcome
   is always the same for both parties.  It also works best with NATs,
   as the initiator is most likely the node that is located behind a

5.2.  NAT Traversal (NAT-T)

5.2.1.  Background and Constraints

   Another core aspect of MOBIKE is the treatment of different NATs and
   Network Address Port Translations (NAPTs).  In IKEv2 the tunnel
   header IP addresses are not sent inside the IKEv2 payloads, and thus
   there is no need to do unilateral self-address fixing (UNSAF

Kivinen & Tschofenig         Informational                     [Page 12]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   [RFC3424]).  The tunnel header IP addresses are taken from the outer
   IP header of the IKE packets; thus, they are already processed by the

   The NAT detection payloads are used to determine whether the
   addresses in the IP header were modified by a NAT along the path.
   Detecting a NAT typically requires UDP encapsulation of IPsec ESP
   packets to be enabled, if desired.  MOBIKE is not to change how IKEv2
   NAT-T works in particular, any kind of UNSAF or explicit interaction
   with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [WIP-Sti06]) is
   beyond the scope of the MOBIKE protocol.  The MOBIKE protocol will
   need to define how MOBIKE and NAT-T are used together.

   The NAT-T support should also be optional.  If the IKEv2
   implementation does not implement NAT-T, as it is not required in
   some particular environment, implementing MOBIKE should not require
   adding support for NAT-T either.

   The property of being behind NAT is actually a property of the
   address pair and thereby of the path taken by a packet.  Thus, one
   peer can have multiple IP addresses, and some of those might be
   behind NAT and some might not.

5.2.2.  Fundamental Restrictions

   There are some cases that cannot be carried out within MOBIKE.  One
   of those cases is when the party "outside" a symmetric NAT changes
   its address to something not known by the other peer (and the old
   address has stopped working).  It cannot send a packet containing the
   new addresses to the peer because the NAT does not contain the
   necessary state.  Furthermore, since the party behind the NAT does
   not know the new IP address, it cannot cause the NAT state to be

   This case could be solved using some rendezvous mechanism outside
   IKEv2, but that is beyond the scope of MOBIKE.

5.2.3.  Moving behind a NAT and Back

   The MOBIKE protocol should provide a mechanism whereby a peer that is
   initially not behind a NAT can move behind NAT when a new preferred
   address is selected.  The same effect might be accomplished with the
   change of the address pair if more than one path is available (e.g.,
   in the case of a multi-homed host).  An impact for the MOBIKE
   protocol is only caused when the currently selected address pair
   causes MOBIKE packets to traverse a NAT.

Kivinen & Tschofenig         Informational                     [Page 13]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   Similarly, the MOBIKE protocol provides a mechanism to detect when a
   NATed path is changed to a non-NATed path with the change of the
   address pair.

   As we only use one address pair at time, effectively the MOBIKE peer
   is either behind NAT or not behind NAT, but each address change can
   change this situation.  Because of this, and because the initiator
   always chooses the addresses, it is enough to send keepalive packets
   only to that one address pair.

   Enabling NAT-T involves a few different things.  One is to enable the
   UDP encapsulation of ESP packets.  Another is to change the IKE SA
   ports from port 500 to port 4500.  We do not want to do unnecessary
   UDP encapsulation unless there is really a NAT between peers, i.e.,
   UDP encapsulation should only be enabled when we actually detect NAT.
   On the other hand, as all implementations supporting NAT-T must be
   able to respond to port 4500 all the time, it is simpler from the
   protocol point of view to change the port numbers from 500 to 4500
   immediately upon detecting that the other end supports NAT-T.  This
   way it is not necessary to change ports after we later detected NAT,
   which would have caused complications to the protocol.

   If we changed the port only after we detected NAT, then the responder
   would not be able to use the IKE and IPsec SAs immediately after
   their address is changed to be behind NAT.  Instead, it would need to
   wait for the next packet from the initiator to see what IP and port
   numbers are used after the initiator changed its port from 500 to
   4500.  The responder would also not be able to send anything to the
   initiator before the initiator sent something to the responder.  If
   we do the port number changing immediately after the IKE_SA_INIT and
   before IKE_AUTH phase, then we get the rid of this problem.

5.2.4.  Responder behind a NAT

   MOBIKE can work in cases where the responder is behind a static NAT,
   but the initiator would need to know all the possible addresses to
   which the responder can move.  That is, the responder cannot move to
   an address which is not known by the initiator, in case initiator
   also moves behind NAT.

   If the responder is behind a NAPT, then it might need to communicate
   with the NAT to create a mapping so the initiator can connect to it.
   Those external firewall pinhole opening mechanisms are beyond the
   scope of MOBIKE.

   In case the responder is behind NAPT, then finding the port numbers
   used by the responder is outside the scope of MOBIKE.

Kivinen & Tschofenig         Informational                     [Page 14]

RFC 4621             Design of the MOBIKE Protocol           August 2006

5.2.5.  NAT Prevention

   One new feature created by MOBIKE is NAT prevention.  If we detect
   NAT between the peers, we do not allow that address pair to be used.
   This can be used to protect IP addresses in cases where the
   configuration knows that there is no NAT between the nodes (for
   example IPv6, or fixed site-to-site VPN).  This avoids any
   possibility of on-path attackers modifying addresses in headers.
   This feature means that we authenticate the IP address and detect if
   they were changed.  As this is done on purpose to break the
   connectivity if NAT is detected, and decided by the configuration,
   there is no need to do UNSAF processing.

5.2.6.  Suggested Approach

   The working group decided that MOBIKE uses NAT-T mechanisms from the
   IKEv2 protocol as much as possible, but decided to change the dynamic
   address update (see [RFC4306], Section 2.23, second to last
   paragraph) for IKEv2 packets to "MUST NOT" (it would break path
   testing using IKEv2 packets; see Section 6.2).  The working group
   also decided only to send keepalives to the current address pair.

5.3.  Scope of SA Changes

   Most sections of this document discuss design considerations for
   updating and maintaining addresses in the database entries that
   relate to an IKE SA.  However, changing the preferred address also
   affects the entries of the IPsec SA database.  The outer tunnel
   header addresses (source and destination IP addresses) need to be
   modified according to the current path to allow the IPsec protected
   data traffic to travel along the same path as the MOBIKE packets.  If
   the MOBIKE messages and the IPsec protected data traffic travel along
   a different path, then NAT handling is severely complicated.

   The basic question is then how the IPsec SAs are changed to use the
   new address pair (the same address pair as the MOBIKE signaling
   traffic).  One option is that when the IKE SA address is changed, all
   IPsec SAs associated with it are automatically moved along with it to
   a new address pair.  Another option is to have a separate exchange to
   move the IPsec SAs separately.

   If IPsec SAs should be updated separately, then a more efficient
   format than the Notify payload is needed to preserve bandwidth.  A
   Notify payload can only store one Security Parameter Index (SPI) per
   payload.  A separate payload could have a list of IPsec SA SPIs and
   the new preferred address.  If there is a large number of IPsec SAs,
   those payloads can be quite large unless list of ranges of SPI values
   are supported.  If we automatically move all IPsec SAs when the IKE

Kivinen & Tschofenig         Informational                     [Page 15]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   SA moves, then we only need to keep track of which IKE SA was used to
   create the IPsec SA, and fetch the IP addresses from the IKE SA,
   i.e., there is no need to store IP addresses per IPsec SA.  Note that
   IKEv2 [RFC4306] already requires the implementations to keep track of
   which IPsec SAs are created using which IKE SA.

   If we do allow the address set of each IPsec SA to be updated
   separately, then we can support scenarios where the machine has fast
   and/or cheap connections and slow and/or expensive connections and
   wants to allow moving some of the SAs to the slower and/or more
   expensive connection, and prevent the move, for example, of the news
   video stream from the WLAN to the GPRS link.

   On the other hand, even if we tie the IKE SA update to the IPsec SA
   update, we can create separate IKE SAs for this scenario.  For
   example, we create one IKE SA that has both links as endpoints, and
   it is used for important traffic; then we create another IKE SA which
   has only the fast and/or cheap connection, which is used for that
   kind of bulk traffic.

   The working group decided to move all IPsec SAs implicitly when the
   IKE SA address pair changes.  If more granular handling of the IPsec
   SA is required, then multiple IKE SAs can be created one for each set
   of IPsec SAs needed.

5.4.  Zero Address Set Functionality

   One of the features that is potentially useful is for the peer to
   announce that it will now disconnect for some time, i.e., it will not
   be reachable at all.  For instance, a laptop might go to suspend
   mode.  In this case, it could send address notification with zero new
   addresses, which would mean that it will not have any valid addresses
   anymore.  The responder would then acknowledge that notification and
   could then temporarily disable all SAs and therefore stop sending
   traffic.  If any of the SAs get any packets, they are simply dropped.
   This could also include some kind of ACK spoofing to keep the TCP/IP
   sessions alive (or simply setting the TCP/IP keepalives and timeouts
   large enough not to cause problems), or it could simply be left to
   the applications, e.g., allow TCP/IP sessions to notice if the link
   is broken.

   The local policy could then indicate how long the peer should allow
   remote peers to remain disconnected.

   From a technical point of view, this would provide following two

Kivinen & Tschofenig         Informational                     [Page 16]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   o  There is no need to transmit IPsec data traffic.  IPsec-protected
      data can be dropped, which saves bandwidth.  This does not provide
      a functional benefit, i.e., nothing breaks if this feature is not

   o  MOBIKE signaling messages are also ignored.  The IKE SA must not
      be deleted, and the suspend functionality (realized with the zero
      address set) may require the IKE SA to be tagged with a lifetime
      value since the IKE SA should not be kept alive for an undefined
      period of time.  Note that IKEv2 does not require that the IKE SA
      has a lifetime associated with it.  In order to prevent the IKE SA
      from being deleted, the dead-peer detection mechanism needs to be
      suspended as well.

   Due to its complexity and no clear requirement for it, it was decided
   that MOBIKE does not support this feature.

5.5.  Return Routability Check

   Changing the preferred address and subsequently using it for
   communication is associated with an authorization decision: Is a peer
   allowed to use this address?  Does this peer own this address?  Two
   mechanisms have been proposed in the past to allow a peer to
   determine the answer to these questions:

   o  The addresses a peer is using are part of a certificate.
      [RFC3554] introduced this approach.  If the other peer is, for
      example, a security gateway with a limited set of fixed IP
      addresses, then the security gateway may have a certificate with
      all the IP addresses appearing in the certificate.

   o  A return routability check is performed by the remote peer before
      the address is updated in that peer's Security Association
      Database.  This is done in order to provide a certain degree of
      confidence to the remote peer that the local peer is reachable at
      the indicated address.

   Without taking an authorization decision, a malicious peer can
   redirect traffic towards a third party or a black hole.

   A MOBIKE peer should not use an IP address provided by another MOBIKE
   peer as a current address without computing the authorization
   decision.  If the addresses are part of the certificate, then it is
   not necessary to execute the return routability check.  The return
   routability check is a form of authorization check, although it
   provides weaker guarantees than the inclusion of the IP address as a
   part of a certificate.  If multiple addresses are communicated to the
   remote peer, then some of these addresses may be already verified.

Kivinen & Tschofenig         Informational                     [Page 17]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   Finally, it would be possible not to execute return routability
   checks at all.  In case of indirect change notifications (i.e.,
   something we notice from the network, not from the peer directly), we
   only move to the new preferred address after successful dead-peer
   detection (i.e., a response to a DPD test) on the new address, which
   is already a return routability check.  With a direct notification
   (i.e., notification from the other end directly) the authenticated
   peer may have provided an authenticated IP address (i.e., inside IKE
   encrypted and authenticated payload; see Section 5.2.5).  Thus, it is
   would be possible simply to trust the MOBIKE peer to provide a proper
   IP address.  In this case, a protection against an internal attacker
   (i.e., the authenticated peer forwarding its traffic to the new
   address) would not provided.  On the other hand, we know the identity
   of the peer in that case.  There might be problems when extensions
   are added to IKEv2 that do not require authentication of end points
   (e.g., opportunistic security using anonymous Diffie-Hellman).

   There is also a policy issue of when to schedule a return routability
   check.  Before moving traffic?  After moving traffic?

   The basic format of the return routability check could be similar to
   dead-peer detection, but potential attacks are possible if a return
   routability check does not include some kind of a nonce.  In these
   attacks, the valid end point could send an address update
   notification for a third party, trying to get all the traffic to be
   sent there, causing a denial-of-service attack.  If the return
   routability check does not contain any nonce or other random
   information not known to the other peer, then the other peer could
   reply to the return routability checks even when it cannot see the
   request.  This might cause a peer to move the traffic to a location
   where the original recipient cannot be reached.

   The IKEv2 NAT-T mechanism does not perform return routability checks.
   It simply uses the last seen source IP address used by the other peer
   as the destination address to which response packets are to be sent.
   An adversary can change those IP addresses and can cause the response
   packets to be sent to a wrong IP address.  The situation is self-
   fixing when the adversary is no longer able to modify packets and the
   first packet with an unmodified IP address reaches the other peer.
   Mobility environments make this attack more difficult for an
   adversary since the attack requires the adversary to be located
   somewhere on the individual paths ({CoA1, ..., CoAn} towards the
   destination IP address), to have a shared path, or, if the adversary
   is located near the MOBIKE client, to follow the user mobility
   patterns.  With IKEv2 NAT-T, the genuine client can cause third-party
   bombing by redirecting all the traffic pointed to him to a third

Kivinen & Tschofenig         Informational                     [Page 18]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   party.  As the MOBIKE protocol tries to provide equal or better
   security than IKEv2 NAT-T mechanism, it should protect against these

   There may be return routability information available from the other
   parts of the system too (as shown in Figure 3), but the checks done
   may have a different quality.  There are multiple levels for return
   routability checks:

   o  None; no tests.

   o  A party willing to answer the return routability check is located
      along the path to the claimed address.  This is the basic form of
      return routability check.

   o  There is an answer from the tested address, and that answer was
      authenticated and integrity- and replay-protected.

   o  There was an authenticated and integrity- and replay-protected
      answer from the peer, but it is not guaranteed to originate at the
      tested address or path to it (because the peer can construct a
      response without seeing the request).

   The return routability checks do not protect against third-party
   bombing if the attacker is along the path, as the attacker can
   forward the return routability checks to the real peer (even if those
   packets are cryptographically authenticated).

   If the address to be tested is carried inside the MOBIKE payload,
   then the adversary cannot forward packets.  Thus, third-party
   bombings are prevented (see Section 5.2.5).

   If the reply packet can be constructed without seeing the request
   packet (for example, if there is no nonce, challenge, or similar
   mechanism to show liveness), then the genuine peer can cause third-
   party bombing, by replying to those requests without seeing them at

   Other levels might only provide a guarantee that there is a node at
   the IP address that replied to the request.  There is no indication
   as to whether or not the reply is fresh or whether or not the request
   may have been transmitted from a different source address.

5.5.1.  Employing MOBIKE Results in Other Protocols

   If MOBIKE has learned about new locations or verified the validity of
   a remote address through a return routability check, can this
   information be useful for other protocols?

Kivinen & Tschofenig         Informational                     [Page 19]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   When the basic MOBIKE VPN scenario is considered, the answer is no.
   Transport and application layer protocols running inside the VPN
   tunnel are unaware of the outer addresses or their status.

   Similarly, IP-layer tunnel termination at a gateway rather than a
   host endpoint limits the benefits for "other protocols" that could be
   informed -- all application protocols at the other side are unaware
   of IPsec, IKE, or MOBIKE.

   However, it is conceivable that future uses or extensions of the
   MOBIKE protocol make such information distribution useful.  For
   instance, if transport mode MOBIKE and SCTP were made to work
   together, it would potentially be useful for SCTP dynamic address
   reconfiguration [WIP-Ste06] to learn about the new addresses at the
   same time as MOBIKE.  Similarly, various IP-layer mechanisms may make
   use of the fact that a return routability check of a specific type
   has been performed.  However, care should be exercised in all these

   [WIP-Cro04] discusses the use of common locator information pools in
   a IPv6 multi-homing context; it assumes that both transport and IP-
   layer solutions are used in order to support multi-homing, and that
   it would be beneficial for different protocols to coordinate their
   results in some way, for instance, by sharing throughput information
   of address pairs.  This may apply to MOBIKE as well, assuming it
   coexists with non-IPsec protocols that are faced with the same or
   similar multi-homing choices.

   Nevertheless, all of this is outside the scope of the current MOBIKE
   base protocol design and may be addressed in future work.

5.5.2.  Return Routability Failures

   If the return routability check fails, we need to tear down the IKE
   SA if we are using IKEv2 INFORMATIONAL exchanges to send return
   routability checks.  On the other hand, return routability checks can
   only fail permanently if there was an attack by the other end; thus,
   tearing down the IKE SA is a suitable action in that case.

   There are some cases, where the return routability check temporarily
   fails, that need to be considered here.  In the first case, there is
   no attacker, but the selected address pair stops working immediately
   after the address update, before the return routability check.

   What happens is that the initiator performs the normal address
   update; it succeeds, and then the responder starts a return
   routability check.  If the address pair has broken down before that,
   the responder will never get back the reply to the return routability

Kivinen & Tschofenig         Informational                     [Page 20]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   check.  The responder might still be using the old IP address pair,
   which could still work.

   The initiator might be still seeing traffic from the responder, but
   using the old address pair.  The initiator should detect that this
   traffic is not using the latest address pair, and after a while it
   should start dead peer detection on the current address pair.  If
   that fails, then it should find a new working address pair and update
   addresses to that.  The responder should notice that the address pair
   was updated after the return routability check was started and change
   the ongoing return routability check to use the new address pair.
   The result of that return routability check needs to be discarded as
   it cannot be trusted; the packets were retransmitted to a different
   IP address.  So normally the responder starts a new return
   routability check afterward with the new address pair.

   The second case is where there is an attacker along the path
   modifying the IP addresses.  The peers will detect this as NAT and
   will enable NAT-T recovery of changes in the NAT mappings.  If the
   attacker is along the path long enough for the return routability
   check to succeed, then the normal recovery of changes in the NAT
   mappings will take care of the problem.  If the attacker disappears
   before return routability check is finished, but after the update, we
   have a case similar to the last.  The only difference is that now the
   dead peer detection started by the initiator will succeed because the
   responder will reply to the addresses in the headers, not the current
   address pair.  The initiator will then detect that the NAT mappings
   are changed, and it will fix the situation by doing an address

   The important thing for both of these cases is that the initiator
   needs to see that the responder is both alive and synchronized with
   initiator address pair updates.  That is, it is not enough that the
   responder is sending traffic to an initiator; it must also be using
   the correct IP addresses before the initiator can believe it is alive
   and synchronized.  From the implementation point of view, this means
   that the initiator must not consider packets having wrong IP
   addresses as packets that prove the other end is alive, i.e., they do
   not reset the dead peer detection timers.

5.5.3.  Suggested Approach

   The working group selected to use IKEv2 INFORMATIONAL exchanges as a
   return routability check, but included a random cookie to prevent
   redirection by an authenticated attacker.  Return routability checks
   are performed by default before moving the traffic.  However, these
   tests are optional.  Nodes may also perform these tests upon their
   own initiative at other times.

Kivinen & Tschofenig         Informational                     [Page 21]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   It is worth noting that the return routability check in MOBIKE is
   different from Mobile IPv6 [RFC3775], which does not perform return
   routability operations between the mobile node and its home agent at

5.6.  IPsec Tunnel or Transport Mode

   The current MOBIKE design is focused only on the VPN type usage and
   tunnel mode.  Transport mode behavior would also be useful and might
   be discussed in future documents.

6.  Protocol Details

6.1.  Indicating Support for MOBIKE

   In order for MOBIKE to function, both peers must implement the MOBIKE
   extension of IKEv2.  If one of the peers does not support MOBIKE,
   then, whenever an IP address changes, IKEv2 will have to be re-run in
   order to create a new IKE SA and the respective IPsec SAs.  In
   MOBIKE, a peer needs to be confident that its address change messages
   are understood by the other peer.  If these messages are not
   understood, it is possible that connectivity between the peers is

   One way to ensure that a peer receives feedback on whether its
   messages are understood by the other peer is to use IKEv2 messaging
   for MOBIKE and to mark some messages as "critical".  According to the
   IKEv2 specification, either such messages have to be understood by
   the receiver, or an error message has to be returned to the sender.

   A second way to ensure receipt of the above-mentioned feedback is by
   using Vendor ID payloads that are exchanged during the initial IKEv2
   exchange.  These payloads would then indicate whether or not a given
   peer supports the MOBIKE protocol.

   A third approach would use the Notify payload to indicate support of
   MOBIKE extension.  Such Notify payloads are also used for indicating
   NAT traversal support (via NAT_DETECTION_SOURCE_IP and

   Both a Vendor ID and a Notify payload may be used to indicate the
   support of certain extensions.

   Note that a MOBIKE peer could also attempt to execute MOBIKE
   opportunistically with the critical bit set when an address change
   has occurred.  The drawback of this approach is, however, that an
   unnecessary message exchange is introduced.

Kivinen & Tschofenig         Informational                     [Page 22]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   Although Vendor ID payloads and Notify payloads are technically
   equivalent, Notify payloads are already used in IKEv2 as a capability
   negotiation mechanism.  Hence, Notify payloads are used in MOBIKE to
   indicate support of MOBIKE protocol.

   Also, as the information of the support of MOBIKE is not needed
   during the IKE_SA_INIT exchange, the indication of the support is
   done inside the IKE_AUTH exchange.  The reason for this is the need
   to keep the IKE_SA_INIT messages as small as possible so that they do
   not get fragmented.  IKEv2 allows that the responder can do stateless
   processing of the first IKE_SA_INIT packet and request a cookie from
   the other end if it is under attack.  To mandate the responder to be
   able to reassemble initial IKE_SA_INIT packets would not allow fully
   stateless processing of the initial IKE_SA_INIT packets.

6.2.  Path Testing and Window size

   As IKEv2 has a window of outgoing messages, and the sender is not
   allowed to violate that window (meaning that if the window is full,
   then the sender cannot send packets), it can cause some complications
   to path testing.  Another complication created by IKEv2 is that once
   the message is created and sent to the other end, it cannot be
   modified in its future retransmissions.  This makes it impossible to
   know what packet actually reached the other end first.  We cannot use
   IP headers to find out which packet reached the other end first
   because if the responder gets retransmissions of the packet it has
   already processed and replied to (and those replies might have been
   lost due unidirectional address pair), it will retransmit the
   previous reply using the new address pair of the request.  Because of
   this, it might be possible that the responder has already used the IP
   address information from the header of the previous packet, and the
   reply packet ending up at the initiator has a different address pair.

   Another complication comes from NAT-T.  The current IKEv2 document
   says that if NAT-T is enabled, the node not behind NAT SHOULD detect
   if the IP address changes in the incoming authenticated packets and
   update the remote peers' addresses accordingly.  This works fine with
   NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs
   the ability to probe other address pairs without breaking the old

   One approach to fix this would be to add a completely new protocol
   that is outside the IKE SA message id limitations (window code),
   outside identical retransmission requirements, and outside the
   dynamic address updating of NAT-T.

Kivinen & Tschofenig         Informational                     [Page 23]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   Another approach is to make the protocol so that it does not violate
   window restrictions and does not require changing the packet on
   retransmissions, and change the dynamic address updating of NAT-T to
   "MUST NOT" for IKE SA packets if MOBIKE is used.  In order not to
   violate window restrictions, the addresses of the currently ongoing
   exchange need to be changed to test different paths.  In order not to
   require that the packet be changed after it is first sent requires
   that the protocol restart from the beginning in case the packet was
   retransmitted to different addresses (because the sender does not
   know which packet the responder got first, i.e., which IP addresses
   it used).

   The working group decided to use normal IKEv2 exchanges for path
   testing and decided to change the dynamic address updating of NAT-T
   to MUST NOT for IKE SA packets; a new protocol outside of IKEv2 was
   not adopted.

6.3.  Message Presentation

   The IP address change notifications can be sent either via an
   informational exchange already specified in IKEv2, or via a MOBIKE-
   specific message exchange.  Using an informational exchange has the
   main advantage that it is already specified in the IKEv2 protocol and
   implementations can already incorporate the functionality.

   Another question is the format of the address update notifications.
   The address update notifications can include multiple addresses, of
   which some may be IPv4 and some IPv6 addresses.  The number of
   addresses is most likely going to be limited in typical environments
   (with less than 10 addresses).  The format may need to indicate a
   preference value for each address.  The format could either contain a
   preference number that determines the relative order of the addresses
   or could simply be an ordered list of IP addresses.  If using
   preference numbers, then two addresses can have the same preference
   value; an ordered list avoids this situation.

   Load balancing is currently outside the scope of MOBIKE; however,
   future work might include support for it.  The selected format needs
   to be flexible enough to include additional information in future
   versions of the protocol (e.g., to enable load balancing).  This may
   be realized with an reserved field, which can later be used to store
   additional information.  As other information may arise that may have
   to be tied to an address in the future, a reserved field seems like a
   prudent design in any case.

   There are two basic formats that place IP address lists into a
   message.  One includes each IP address as separate payload (where the
   payload order indicates the preference order, or the payload itself

Kivinen & Tschofenig         Informational                     [Page 24]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   might include the preference number).  Alternatively, we can put the
   IP address list as one payload to the exchange, and that one payload
   will then have an internal format that includes the list of IP

   Having multiple payloads, each one carrying one IP address, makes the
   protocol probably easier to parse, as we can already use the normal
   IKEv2 payload parsing procedures.  It also offers an easy way for the
   extensions, as the payload probably contains only the type of the IP
   address (or the type is encoded to the payload type), and the IP
   address itself.  As each payload already has a length field
   associated to it, we can detect if there is any extra data after the
   IP address.  Some implementations might have problems parsing more
   than a certain number of IKEv2 payloads, but if the sender sends them
   in the most preferred first, the receiver can only use the first
   addresses it was willing to parse.

   Having all IP addresses in one big MOBIKE-specified internal format
   provides more compact encoding and keeps the MOBIKE implementation
   more concentrated to one module.

   Another choice is which type of payloads to use.  IKEv2 already
   specifies a Notify payload.  It includes some extra fields (SPI size,
   SPI, protocol, etc.), which gives 4 bytes of the extra overhead, and
   there is the notification data field, which could include the
   MOBIKE-specific data.

   Another option would be to have a custom payload type, which would
   then include the information needed for the MOBIKE protocol.

   The working group decided to use IKEv2 Notify payloads, and put only
   one data item per notify.  There will be one Notify payload for each
   item to be sent.

6.4.  Updating Address Set

   Because the initiator decides all address updates, the initiator
   needs to know all the addresses used by the responder.  The responder
   also needs that list in case it happens to move to an address not
   known by the initiator, and it needs to send an address update
   notification to the initiator.  It might need to try different
   addresses for the initiator.

   MOBIKE could send the whole peer address list every time any of the
   IP addresses change (addresses are added or removed, the order
   changes, or the preferred address is updated) or an incremental
   update.  Sending incremental updates provides more compact packets
   (meaning we can support more IP addresses), but on the other hand

Kivinen & Tschofenig         Informational                     [Page 25]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   this approach has more problems in the synchronization and packet
   reordering cases.  That is, incremental updates must be processed in
   order, but for full updates we can simply use the most recent one and
   ignore old ones, even if they arrive after the most recent one (IKEv2
   packets have a message ID that is incremented for each packet; thus,
   it is easy to know the sending order).

   The working group decided to use a protocol format where both ends
   send a full list of their addresses to the other end, and that list
   overwrites the previous list.  To support NAT-T, the IP addresses of
   the received packet are considered as one address of the peer, even
   when they are not present in the list.

7.  Security Considerations

   As all the packets are already authenticated by IKEv2, there is no
   risk that any attackers would undetectedly modify the contents of the
   packets.  The IP addresses in the IP header of the packets are not
   authenticated; thus, the protocol defined must take care that they
   are only used as an indication that something might be different, and
   that they do not cause any direct actions, except when doing NAT

   An attacker can also spoof ICMP error messages in an effort to
   confuse the peers about which addresses are not working.  At worst,
   this causes denial of service and/or the use of non-preferred

   One type of attack that needs to be taken care of in the MOBIKE
   protocol is the bombing attack type.  See [RFC4225] and [Aur02] for
   more information about flooding attacks.

   See the security considerations section of [RFC4555] for more
   information about security considerations of the actual protocol.

8.  Acknowledgements

   This document is the result of discussions in the MOBIKE working
   group.  The authors would like to thank Jari Arkko, Pasi Eronen,
   Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld,
   James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch,
   Udo Schilcher, Tom Henderson, Andreas Pashalidis, and Maureen
   Stillman for their input.

   We would like to particularly thank Pasi Eronen for tracking open
   issues on the MOBIKE mailing list.  He helped us make good progress
   on the document.

Kivinen & Tschofenig         Informational                     [Page 26]

RFC 4621             Design of the MOBIKE Protocol           August 2006

9.  References

9.1.  Normative references

   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
                Internet Protocol", RFC 4301, December 2005.

   [RFC4306]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
                RFC 4306, December 2005.

9.2.  Informative References

   [Aur02]      Aura, T., Roe, M., and J. Arkko, "Security of Internet
                Location Management", In Proc. 18th Annual Computer
                Security Applications Conference, pages 78-87, Las
                Vegas, NV USA, December 2002.

   [RFC2367]    McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
                Management API, Version 2", RFC 2367, July 1998.

   [RFC2401]    Kent, S. and R. Atkinson, "Security Architecture for the
                Internet Protocol", RFC 2401, November 1998.

   [RFC2409]    Harkins, D. and D. Carrel, "The Internet Key Exchange
                (IKE)", RFC 2409, November 1998.

   [RFC2461]    Narten, T., Nordmark, E., and W. Simpson, "Neighbor
                Discovery for IP Version 6 (IPv6)", RFC 2461,
                December 1998.

   [RFC2462]    Thomson, S. and T. Narten, "IPv6 Stateless Address
                Autoconfiguration", RFC 2462, December 1998.

   [RFC2960]    Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
                Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
                Zhang, L., and V. Paxson, "Stream Control Transmission
                Protocol", RFC 2960, October 2000.

   [RFC3303]    Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
                and A. Rayhan, "Middlebox communication architecture and
                framework", RFC 3303, August 2002.

   [RFC3424]    Daigle, L. and IAB, "IAB Considerations for UNilateral
                Self-Address Fixing (UNSAF) Across Network Address
                Translation", RFC 3424, November 2002.

Kivinen & Tschofenig         Informational                     [Page 27]

RFC 4621             Design of the MOBIKE Protocol           August 2006

   [RFC3554]    Bellovin, S., Ioannidis, J., Keromytis, A., and R.
                Stewart, "On the Use of Stream Control Transmission
                Protocol (SCTP) with IPsec", RFC 3554, July 2003.

   [RFC3753]    Manner, J. and M. Kojo, "Mobility Related Terminology",
                RFC 3753, June 2004.

   [RFC3775]    Johnson, D., Perkins, C., and J. Arkko, "Mobility
                Support in IPv6", RFC 3775, June 2004.

   [RFC4193]    Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
                Addresses", RFC 4193, October 2005.

   [RFC4225]    Nikander, P., Arkko, J., Aura, T., Montenegro, G., and
                E. Nordmark, "Mobile IP Version 6 Route Optimization
                Security Design Background", RFC 4225, December 2005.

   [RFC4429]    Moore, N., "Optimistic Duplicate Address Detection (DAD)
                for IPv6", RFC 4429, April 2006.

   [RFC4555]    Eronen, P., "IKEv2 Mobility and Multihoming Protocol
                (MOBIKE)", RFC 4555, June 2006.

   [WIP-Ark06]  Arkko, J. and I. Beijnum, "Failure Detection and Locator
                Pair Exploration Protocol for IPv6 Multihoming", Work in
                Progress, June 2006.

   [WIP-Cro04]  Crocker, D., "Framework for Common Endpoint Locator
                Pools", Work in Progress, February 2004.

   [WIP-Nik06]  Nikander, P., "End-Host Mobility and Multihoming with
                the Host Identity Protocol", Work in Progress,
                June 2006.

   [WIP-Ste06]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
                Conrad, "Stream Control Transmission Protocol (SCTP)
                Dynamic Address Reconfiguration", Work in Progress,
                June 2006.

   [WIP-Sti06]  Stiemerling, M., Tschofenig, H., Aoun, C., and E.
                Davies, "NAT/Firewall NSIS Signaling Layer Protocol
                (NSLP)", Work in Progress, June 2006.

Kivinen & Tschofenig         Informational                     [Page 28]

RFC 4621             Design of the MOBIKE Protocol           August 2006

Authors' Addresses

   Tero Kivinen
   Safenet, Inc.
   Fredrikinkatu 47
   HELSINKI  FI-00100

   EMail: kivinen@safenet-inc.com

   Hannes Tschofenig
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739

   EMail: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com

Kivinen & Tschofenig         Informational                     [Page 29]

RFC 4621             Design of the MOBIKE Protocol           August 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Kivinen & Tschofenig         Informational                     [Page 30]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/


Content-Type: application/http; msgtype=response

WARC-Identified-Payload-Type: application/xhtml+xml

WARC-Truncated: length

WARC-Type: response

text:
Totally Radical Sportz!

Three Assholes – Episode 107

Posted in erbooker by erbooker on 12/21/2011

Nate, Mike & Keith are childhood Maine friends. They’re also assholes.

Episode 107 – A Christmas Party

Mary:  Now boys, I don’t want any mischief while we’re gone. We’ll be up in Dover-Foxcroft for the night and we want this place in tip-top shape when we get back in time for Christmas weekend. No more indoor snowball fights.

Mike:  Yes, Mom.

Mike Sr.:  You listen to your mother, son.

Mike:  Yes, Dad.

Mary:  (waving from the station wagon)  You boys be good.

Keith:  (waving, with lit firecracker behind back)  Bye, Mr. & Mrs. Miner!

(The station wagon pulls out and takes off down the road. Keith spins and hucks the firecracker into the Miners’ living room…)

Keith:  Party!

(Mike plops into his dad’s recliner while Keith battles the carpet fire with an extinguisher…)

Nate:  (on the couch with a cat in his lap)  So. Party?

Keith:  (looks up, sprays shoe with extinguisher)  Yeah yeah, party.

Mike:  No party. You heard Mom and Dad.

Keith:  What are you, twelve? C’mon, let’s party.

Mike:  No party.

Keith:  But MTV taught me that partying is cool.

Nate:  C’mon, Mike. Just a little shindig. It’s Christmas. We’ll buy a keg, stir up a little eggnog, wear Santa hats.

Keith:  Yeah! And put mistletoe on our crotches so girls have to kiss our wieners!

Mike:  Well…maybe just a little party.

Nate:  Great. I got a guy who can get us a keg.

Keith:  And I’ll call up Minnie and get her and her stripper friends over here. Talk about a Yule log! Wait, that didn’t make sense.

Mike:  How ’bout you let me handle the whole calling my girlfriend thing, Keith.

Nate:  Maybe we could invite some old friends from high school. I bet a lot of people are back in town visiting for the holidays.

Mike:  Okay, but let’s try to keep this low-key. Mom and Dad’ll kill me if they come home to an 80’s hair band video.

Keith:  Ooh! Let’s put a Santa hat on the cat!

(At Punchers, a local dive bar…)

Mike:  How are we going to afford this keg? Collectively we have, like, none money.

Nate:  Trust me, I know this guy. He used to work at the dam with my mom.  (bursts through the double-doors)  Tommy!

(A group of burly leather-clad ruffians turn and stare at the three assholes…)

Keith:  (whispering loudly)  Is this one of those S&M bars?

(A heavily-mustachioed giant makes his way through the bar patrons…)

Tommy:  Is that little Nate Shoops?

Nate:  (laughing nervously)  Well, not so little anymore.

Tommy:  No, no. You’re about the same size. Just as petite as the day I met you. How’s Mom?

Nate:  She’s dead.

Tommy:  Aw. I’m sorry to hear that, buddy. You need a drink?

Keith:  Yes.

Nate:  (elbows Keith)  Actually, we need a lot of them. We were hoping we could bum a keg off you.

Tommy:  Of course! Anything for a Shoops.

Nate:  Thing is, we don’t really have any money.

Tommy:  Well now, that’s a problem. What’s this keg for? Office Christmas party at the dam?

Nate:  No. They sorta outlawed alcohol shortly after you left.

(The men guffaw and Tommy pats his belly…)

Tommy:  Yeah, we had some fun times there.

Keith:  Didn’t you flood the town one summer?

Tommy:  (shoving a finger in Keith’s face)  There was a severe drought!

Nate:  Actually Tommy, we’re just having a little holiday season get-together at my friend Mike’s parents’ house.

Tommy:  A party, eh? I’ll tell you what. I’ll give you a keg on the house. And four more on top of that, if my boys are invited.

Keith:  Deal!

Nate:  Now, not so fast. Pardon my judge-a-book-by-its-cover mentality, but you fellas sorta look like a biker gang.

Tommy:  Well, that’s because we are.

Nate:  Oh.

Tommy:  We’re the Old Dogs.

Mike:  Oh, like that Robin Williams laffer.

Tommy:  Hey, we had the name long before that movie which also co-stars John Travolta and a delightful supporting role by Family Guy‘s Seth Green.

Mike:  It really is a great film. And I’d imagine you can most likely purchase a copy at your nearest Best Buy.

Tommy:  Sure would make a helluva stocking-stuffer this holiday season.

Mike:  Sure would.

Tommy:  Great. So we’ll deliver the kegs tonight. Any girls gonna be there?

Keith:  (hanging up his cellphone)  Just got off the phone with Minnie. The entire staff of Diva’s Gentleman’s Club will be in attendance.

Tommy:  Ai chi-wa-wa! We’re gonna have a ball tonight, boys!

(The bike gang hoots and hollers as Mike, Nate and Keith make their way towards the exit…)

Mike:  Um.

Nate:  Just roll with it, Mikey.

Mike:  (sighs)  I just know one of those bikes is gonna end up parked in my living room.

Keith:  Your mom’s living room.

(That evening Mike, Nate and Keith are mingling with the strippers and their other guests, which are one guy…)

Oliver:  Hey, guys.

Keith:  (pointing directly at Oliver’s face)  Oliver Welsh? This is the best we could do?

Oliver:  Heh. Keith’s still got it!

Mike:  I invited everybody on my Facebook that we went to high school with. Oliver was the only one to respond.

Oliver:  Hehe. First!

Keith:  (sighs)  Oliver, you have always been the worst.

Oliver:  (pouts)

Mike:  (gagging)  Ugh. Keith, what did you put in this eggnog?

Keith:  Ooh, that’s not eggnog.

Nate:  Where the heck are the Old Dogs?

(Oliver gets punched hard and collapses to the ground as the door flies open and the biker gang blasts in with kegs and assorted barfolk…)

Tommy:  (tapping the first keg)  Happy holidays!

(Everyone cheers as Tommy sprays beer foam on the strippers…)

Otto:  Where can I put this keg, Blotto?

Blotto:  Here, Otto. I’ll make some room.

(Blotto raises a sledgehammer over his head and brings it down on the oak coffee table, sending wood shards everywhere…)

Mike:  Oh c’mon, Blotto!

Keith:  Bikers rule!

Mike:  Where’d he even get that sledgehammer?

(The next morning, Mike wakes up in his parents’ bed with Minnie. He makes his way out to the living room, carefully stepping over bikers and strippers, only to find the Christmas tree on its side and a motorcycle leaking oil in the center of the room…)

Mike:  (sighs)  Merry Christmas, everybody.

Comments Off on Three Assholes – Episode 107

%d bloggers like this:

warcinfo:
robots: classic
hostname: ip-10-149-109-157.ec2.internal
software: Nutch 1.6 (CC)
isPartOf: CC-MAIN-2018-05
operator: Common Crawl Admin
description: Wide crawl of the web for January 2018
publisher: Common Crawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf


WARC-Identified-Payload-Type: text/html

text:
Towards the New Creation

by Stefania Caterina and Tomislav Vlašić

Rewriting History – Volume II – “The Universe and Its Inhabitants” – More appeals to the Pope, the Church and the humanity of Earth

06 March 2015

By Stefania Caterina and Tomislav Vlašić

Dearest Brothers and Sisters,

On page 336 the book “The Universe and Its Inhabitants” refers to the message of St. Michael the Archangel of November 2013. That is a very important message. It is a document that offers an overview of all that is going on in the universe. I will quote his words: “My words today close a cycle of your history and start a new one. Today I turn to the humanity of the Earth for the last time.” So, it is very important that we share the whole message so that those who read it for the first time also get a proper view, an overall picture of how the grace of God is unfolding in the whole universe.

Message of St. Michael the Archangel of November 19, 2013: “Do not be afraid, little flock …” (Lk 12:32)[1]

“I greet you brothers and sisters of the Earth! God has sent me to you one more time. However, this is not like any other message you have received so far: my words today close a cycle of your history and start a new one. Today I turn to the humanity of the Earth for the last time. Many things have already been explained to you; therefore, I will not repeat what you already know. I will just highlight some points to remind you once again of your responsibility as human beings and believers. Here are the points I invite you to think about.

  1. Everything you have been told in recent years will be accomplished on Earth. The plan to unite all things in Christ will be realized. The enemies of God and his people should not delude themselves! God has the power to bring to completion what he has planned. If it seems that it is not so, it is just because God is patient with the men of the Earth and gives everyone time to understand if they wish to understand. God’s promises always come true for those who love Him and seek Him sincerely; they will come true even for the enemies of God who, willingly or unwillingly, must bend to the will of the Holy Trinity. In fact, men, angels, demons and all creatures are subject to the power of God and nothing escapes his eyes. Sooner or later, everything will have to be fulfilled. Be sure of this.
  2. The plan to recapitulate all things in Christ is already in action in the universe. The nuclei, the new priesthood, the mystical union with Christ and other aspects, about which much has been said, are already operating in a large part of the universe, especially among the humanities faithful to God who live in the high universe; they are also operating among most of the humanities of the middle universe. There, in fact, a deep and widespread work of evangelisation has been carried out by the brothers and sisters faithful to God and has given good fruit. Whole planets of the middle universe were converted to God and, together with the faithful humanity, form a great and mighty people.

I tell you these things to prevent you from thinking that what has been announced in recent years is a beautiful utopia. God does not sell smoke like many of your political and religious leaders do; He does not deceive anyone and certainly not those who love Him. Therefore, what is already happening in other parts of the universe will have to take place on Earth and in the low universe where the Earth is.

The Earth is very much behind due to its distance from God, its arrogance and unfaithfulness. Your planet was supposed to be the centre of the spread of the message of Salvation throughout the universe because of the fact that Jesus incarnated on Earth. Instead, you can see for yourself that the Earth has become a centre of the spread of sin and corruption. Most of your humanity lives outside the laws of God: in fact, it follows the law of selfishness, sin and death.

  1. In every age God has formed His little rest on Earth, a humble people who remained faithful to His law of love and life: the small flock of which Jesus speaks (Lk 12, 32), for whose sake God has forgiven many sins of this humanity, and for whose sake He will carry out His projects also on Earth. The saints, the prophets and the righteous who have lived on your planet along history paved the way for the realization of God’s plans on Earth. Usually insulted and persecuted, they have offered their lives and their suffering for all of you, removing the punishments that your humanity would have justly deserved. As it is written: “… God has tested them, like gold in a furnace, and found them worthy to be with him. He has accepted them, just as he accepts the sacrifices which his worshipers burn on the altar” (Wis 3:5-6). Their sacrifice, permitted by God, was not in vain and this will become clear at the end of times.

Even today this little flock is present on Earth; it is united to God and to his instruments and works in silence in the midst of the difficulties of a pagan world without faith and law. It is like a sprout but it is destined to grow. From this sprout God will bring forth a new people that will carry out His plans. You are all called to be part of this people because God does not favour anybody. To be part of it, however, enthusiasm is not enough: you must let go of all selfishness, compromises and ambitions and decide to seriously change your life, to live according to the laws of God that God has made known through Jesus Christ.

Lucifer and his followers are numerous and powerful on Earth as you may well see. They hate the little flock of God, they want to disperse and exterminate it, but God watches over whom belongs to Him. The enemies of God and Jesus Christ shall be well aware of it!

  1. The humanity of the Earth handed itself over to Lucifer in the moment it committed original sin. There he placed his throne; he too formed a people on Earth, and from there he intended to expand His kingdom throughout the low universe. The situation on your planet is serious, but the majority of the people are completely unaware of the risk it is running as they are so caught up in the struggle to survive. If Lucifer cannot realise his plans, he will destroy you. That is what he always does: he destroys what he cannot achieve. A hierarchy that serves Lucifer holds the power on Earth solidly in its hands; you can see where it is leading you: the Earth is a place of despair, known in the entire universe as “the planet of death”, dangerous and hostile.
  2. The humanity of the Earth will not manage to get out of the tunnel in which it slipped all by itself. Therefore, you will need the help of the brothers and sisters faithful to God. God has always wished to send you help through your brothers and sisters of the universe faithful to Him, against whom Lucifer cannot do anything; yet, God has always respected your freedom. Many of you do not accept the idea that other human beings exist in the universe; this has delayed God’s plans. What is more, your rulers and religious leaders, who are strongly afraid of an intervention by the faithful brothers and sisters, have hidden from the people the reality of the universe; this has made things even more complicated. Nevertheless, God has determined to send you help from the universe, and He will do so by putting a limit to the slyness and arrogance of the men of Earth who refuse to accept the reality as it is in God and to bend to His will.

To this day, the faithful brothers and sisters to God have travelled the middle universe announcing all the peoples the redemption carried out by Jesus Christ and baptizing in His name entire humanities. They are waiting for God’s command to enter the low universe in order to accomplish the same work of evangelisation. In this universe where you also are, the situation is delicate: here Lucifer holds great power over the various humanities because they are rebellious to God. They will not easily accept the coming of the faithful brothers and sisters; on the contrary, they will react with violence. When the faithful brothers and sisters enter the low universe with all their power and begin their evangelisation; it will also have a strong impact on the Earth, because Lucifer and his followers will constantly be in a state of alarm; they will multiply their endeavours to push away the faithful brothers and sisters.

The Earth will be the last planet of the low universe to be visited by the faithful brothers and sisters. Yet, they will be in communion with the little flock of the Earth, which has accepted their existence a long time ago and is expecting their appearance with love. God will send the faithful brothers and sisters to Earth to visit well prepared single individuals and nuclei in order to teach and protect the children of God. When the time comes, God will order them to manifest themselves openly to the whole humanity on Earth. At that point, the lies of your rulers, your arms and even your missile defence shields will avail you nothing. Then you will see signs in the sky, the sun, the moon and the stars (Lk 21, 25); everyone will understand the reality as it is, but for many it will be too late. Now is the time for all of you, from the biggest to the smallest, to make your choice: either with God or with Lucifer. Do not waste time because there is not much time left.

  1. Before all this happens, the true children of God, those who wish to be reunited to Christ to become new human creatures, will not lack anything. They will be informed about everything that awaits them: the Holy Spirit will guide them internally to the truth, and they will receive increasingly stronger confirmations in due time. God will protect His little flock despite the battle that awaits it: this little rest will collide frontally with the forces of evil and the Earth will be the scene of the largest battle of spirits of all times: the Spirit of God present in His children and the spirit of this world present in the children of darkness.
  2. To be capable of facing such a battle, God has placed the three major instruments of this time at the side of His people: the angels, the Central Nucleus and the brothers and sisters faithful to God. Those who welcome them and enter into communion with them will be strongly protected. God’s instruments are in full action in the universe and are facing difficult situations: they must prepare in spirit the entry of the faithful brothers and sisters in the low universe and protect the fragile among God’s people. God has called them to a silent and powerful action.
  3. God is slowly drawing His ordinary and extraordinary instruments into silence to make them focus their work where it is really needed. The great prophetic voices of this time will slowly decrease until they remain silent altogether. That is the great silence of God that comes before the big events that are awaiting you. The confused voices of the false prophets will continue crying on the squares. Only those who stand firmly in God will be able to discern the voices in the big disorder that is awaiting you: political, social, religious unrest; even the nature that you have devastated beyond all limits will be in disorder. “Nation will rise against nation and kingdom against kingdom.There will be great earthquakes, famines and pestilences in various places, and fearful events …”(Lk 21, 10). God will no longer speak to the deaf who do not want to hear, nor will He manifest His actions to the blind who do not want to see: God’s work will be understood solely by those who are united to Him. God will withdraw the graces given to those who misuse His kindness without converting and will give them to those who walk in the will of God. Your humanity will be tried severely, not because God wants to punish you, but because he wants to purify and save you: your stubbornness is such that you do not leave God any other option than that of trial; only in this way you bend to what is good while you are actually always ready to choose evil.
  4. The plan of God to save His children is unfolding in all its power in the entire universe. It will not stop until the kingdom of Lucifer is destroyed. All creation will be affected by the Trinitarian action that will spread everywhere like a huge wave. Decide now which side you want to take; tomorrow may be too late.
  5. The Church of the Earth will also be severely tried in order to be purified from the many sins with which she has defiled herself. God loves His Church and wants to save her; however, this will not be possible without a true atonement of her sins.

For this reason, once again, I invite the Pope and the hierarchies of all Christian churches to recognize and proclaim the existence of life in the universe, especially the existence of the faithful brothers and sisters to God. I also invite them to recognize the existence of the three extraordinary instruments of this time, and to enter into communion with them in order to receive help and protection. Finally, I invite them to recognize my authority as the Precursor of the glorious coming of Christ and as the guide of the people of God in these last times. I do not ask this for myself but for God’s plans and according to His will. I do not ask you to erect expensive statues for me, but to obey my orders that are orders of God for the good of His people. If this is done, the suffering of the humanity on Earth will be shortened and you will receive all necessary help from me and all the instruments that I am leading. This is the last call that I send you after which it will be God’s turn to speak, and He will do what He intends to do. Reflect and pray to respond in the right way.

I call on all of the priests and Christians, from the least to the most important, to analyse their own behaviour and to offer themselves unconditionally to God. Lift your eyes as they are too focused on earthly matters; you are so absorbed by the worries of this world that the seed of God does not grow within you as it should (Mt 13, 22). It is right that you do your pastoral, social, family duties, however, they are not the highest in the list of God’s values: remember that first you have to seek God and His kingdom and that all the rest will be given to you as well (Mt 6:33). You are rushing from morning to evening worrying about mostly unnecessary things: rarely do you choose what is better, as Jesus said (Lk 10:38-42).

It is time that the Christians become brave and real witnesses of the gospel through a righteous life in God and in true fraternal communion: “You are the salt of the earth. But if the salt loses its saltiness, how can it be made salty again? It is no longer good for anything, except to be thrown out and trampled underfoot” (Mt 5:13).Too many Christians have become insipid, and this is one reason why there are so many troubles on Earth. Repent!

I turn to every man who says he does not believe in God but is of good will: it is not too late to discover God. It is a time of great graces for those who wish to change their life for the better. Seek Jesus Christ and He will manifest His life. You will be new people, and you will contribute to build a new future for the humanity of the entire universe. God needs every one of you and has created you for His glory. Think about it.

I turn to those who have decided to adore and serve Lucifer: your time is almost up. You will not be able to stop God’s work nor to suffocate His people whose number is growing increasingly in the whole universe. You are still in time to convert and to atone for your sins if you want. You can still escape the slavery of Lucifer; be careful though, as there is little time left. If you do not convert, you will have the same fate as your master.

My speech ends here. I have told you everything God has ordered me to say; I will continue to pray for you. I bless all those who will read these words; I bless particularly those who welcome these words and put them into practice. My little flock, I tell you not to be afraid because God will always be by your side. Remain in peace and allow your faith, hope and love to grow. Be a sign of God’s presence in the midst of the people of the Earth who will be more and more lost and confused. This is what God expects from you. It falls to God to accomplish the great things; it is up to you instead to be small and simple like the children who lovingly rely on the Father’s hands. Pray intensively and beg God for mercy upon the humanity of the Earth.

I bless you and I bless the entire humanity of the Earth, in the name of the Father, of the Son and of the Holy Spirit”.

In this message St. Michael has been very clear and has given a clear overview of the situation in the whole universe. You may well understand that the matter is not extraterrestrial but profoundly Christian and connected to all that has been announced by Jesus Christ and His apostles.

I would like to explain some points of this document. As you know, we explained that we would withdraw into silence because silence would precede many events. Since, according to St. Michael, the official Church has not given the expected response, God sent us to speak to you again as He saw that the people were misinformed. We will speak about all that God tells us and that will be useful for you. After completing this book, we will try to focus on giving explanations about how to walk, how to get together and how to live in these times, especially for those who want to join the plan of God which comes through His instruments. One more thing must be underlined: St. Michael announced in the previous message that he would instruct you; yet, he did not go any further and, as you know, shared his last message for the humanity of the Earth. I quote: “This is the last call that I send you after which it will be God’s turn to speak, and He will do what He intends to do. Reflect and pray to respond in the right way.” The meaning of this content is clear; however, it can only become clear within us if we pray and love God; if we strengthen our faith with hope and love; if we take responsibility for our life, the life of the Earth and of the whole universe and give our response in these times.

I bless you in the name of the Father, of the Son and of the Holy Spirit.

[1] Message published in November, 2013, on the website

Comments are closed.


text:
The truth…in small doses

I have never been particularly interested in blogging about films I’ve seen, or interesting anecdotes about my day, or travel, or food, or anything marginally trendy. I’ve only ever been drawn to write about deeply personal things, feelings, and experiences. Which is why there are often long gaps between my posts, because sometimes it’s impossible to do that without sharing something intimate or private that also affects someone else who might not want to share so openly. Continue reading

Self-identity and the social grape vine

The dictionary definition of self-identity is ‘the perception or recognition of one’s characteristics as a particular individual, especially in relation to social context.’  That last part is quite important I think. Like the proverbial tree falling in the forest, if I think I have a certain quality but others don’t, do I really have it? There’s no easy answer. Continue reading


text:
United States - Other expense (current LCU)

Other expense (current LCU) in United States was reported at 268125000000 LCU in 2016, according to the World Bank collection of development indicators, compiled from officially recognized sources.

 united states other expense current lcu wb data
Trading Economics members can view, download and compare data from nearly 200 countries, including more than 20 million economic indicators, exchange rates, government bond yields, stock indexes and commodity prices.

The Trading Economics Application Programming Interface (API) provides direct access to our data. It allows API clients to download millions of rows of historical data, to query our real-time economic calendar, subscribe to updates and receive quotes for currencies, commodities, stocks and bonds.

Other expense is spending on dividends, rent, and other miscellaneous expenses, including provision for consumption of fixed capital.

United States | Public Sector


text:
Browsing Low German translation

2 of 14 results
No description available
Keen Beschrieven verföögbor
Translated by Sönke Dibbern on 2009-08-04
Located in kresourceassistant.cpp:126
2 of 14 results

This translation is managed by Ubuntu Low German Translators, assigned by Ubuntu Translators.

You are not logged in. Please log in to work on translations.