text:
MOBIKE Working Group P. Eronen, Ed. Internet-Draft Nokia Expires: April 2, 2006 September 29, 2005 IKEv2 Mobility and Multihoming Protocol (MOBIKE) draft-ietf-mobike-protocol-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows hosts to update the (outer) IP addresses associated with IKEv2 and IPsec Security Associations. A mobile VPN client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the currently used one stops working. Eronen Expires April 2, 2006 [Page 1]
Internet-Draft MOBIKE Protocol September 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 3.1 Basic Operation . . . . . . . . . . . . . . . . . . . . . 4 3.2 Example Protocol Runs . . . . . . . . . . . . . . . . . . 5 3.3 MOBIKE and Network Address Translation (NAT) . . . . . . . 8 3.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . 9 4.1 Signaling Support for MOBIKE . . . . . . . . . . . . . . . 9 4.2 Initial Tunnel Header Addresses . . . . . . . . . . . . . 9 4.3 Additional Addresses . . . . . . . . . . . . . . . . . . . 9 4.4 Changing Addresses in IPsec SAs . . . . . . . . . . . . . 11 4.5 Updating Additional Addresses . . . . . . . . . . . . . . 14 4.6 Return Routability Check . . . . . . . . . . . . . . . . . 15 4.7 Changes in NAT Mappings . . . . . . . . . . . . . . . . . 16 4.8 NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 16 4.9 Path Testing . . . . . . . . . . . . . . . . . . . . . . . 17 4.10 Failure Recovery and Timeouts . . . . . . . . . . . . . 17 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . 19 5.1 MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 19 5.2 ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 19 5.3 NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 19 5.4 UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 19 5.5 UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 20 5.6 COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 20 5.7 NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 20 5.8 UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . 21 6.1 Traffic Redirection and Hijacking . . . . . . . . . . . . 21 6.2 IPsec Payload Protection . . . . . . . . . . . . . . . . . 21 6.3 Denial-of-Service Attacks Against Third Parties . . . . . 22 6.4 Spoofing Network Connectivity Indications . . . . . . . . 23 6.5 Address and Topology Disclosure . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1 Normative References . . . . . . . . . . . . . . . . . . . 25 9.2 Informative References . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . 27 A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . 30 Eronen Expires April 2, 2006 [Page 2]
Internet-Draft MOBIKE Protocol September 2005 1. Introduction IKEv2 is used for performing mutual authentication and establishing and maintaining IPsec Security Associations (SAs). In the current specifications, the IPsec and IKE SAs are created implicitly between the IP addresses that are used when the IKE_SA is established. These IP addresses are then used as the outer (tunnel header) addresses for tunnel mode IPsec packets. Currently, it is not possible to change these addresses after the IKE_SA has been created. There are scenarios where these IP addresses might change. One example is mobility: a host changes its point of network attachment, and receives a new IP address. Another example is a multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason. Although the problem can be solved by creating new IKE and IPsec SAs when the addresses need to be changed, this may not be optimal for several reasons. In some cases, creating a new IKE_SA may require user interaction for authentication (entering a code from a token card, for instance). Creating new SAs often also involves expensive calculations and possibly a large number of roundtrips. Due to these reasons, a mechanism for updating the IP addresses of existing IKE and IPsec SAs is needed. The MOBIKE protocol described in this document provides such a mechanism. The main scenario for MOBIKE is making it possible for a remote access VPN user to move from one address to another without re- establishing all security associations with the VPN gateway. For instance, a user could start from fixed Ethernet in the office, and then disconnect the laptop and move to office wireless LAN. When leaving the office the laptop could start using GPRS, and switch to a different wireless LAN when the user arrives home. MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and others traffic selectors used inside the tunnel stay unchanged. Thus, mobility can be (mostly) invisible to applications and their connections using the VPN. MOBIKE also supports more complex scenarios where the VPN gateway also has several network interfaces: these interfaces could be connected to different networks or ISPs, they may have may be a mix of IPv4 and IPv6 addresses, and the addresses may change over time. Furthermore, both parties could be VPN gateways relaying traffic for other parties. 2. Terminology and Notation When messages containing IKEv2 payloads are described, optional Eronen Expires April 2, 2006 [Page 3]
Internet-Draft MOBIKE Protocol September 2005 payloads are shown in brackets (for instance, "[FOO]"), and a plus sign indicates that a payload can be repeated one or more times (for instance, "FOO+"). In some cases, the diagrams also show what payloads defined in [IKEv2] would be typically included in, for instance, the IKE_AUTH exchange. These payloads are shown for illustrative purposes only; see [IKEv2] for an authoritative description. When this document talks about updating the source/destination addresses of an IPsec SA, it means updating IPsec-related state so that outgoing ESP/AH packets use those addresses in the tunnel header. Depending on how the nominal division between Security Association Database (SAD), Security Policy Database (SPD), and Peer Authorization Database (PAD) described in [IPsecArch] is actually implemented, an implementation can have several different places that have to be updated. In this document, the term "initiator" means the party who originally initiated the first IKE_SA (in a series of possibly several rekeyed IKE_SAs); "responder" is the other peer. During the lifetime of the IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA exchanges; in this case, the terms "exchange initiator" and "exchange responder" are used. The term "original initiator" (which in [IKEv2] refers to the party who started the latest IKE_SA rekeying) is not used in this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 3. Protocol Overview 3.1 Basic Operation MOBIKE allows both parties to have several addresses, and there are up to N*M pairs of IP addresses that could potentially be used. The decision of which of these pairs to use has to take into account several factors. First, the parties have may preferences about which interface should be used, due to performance and cost reasons, for instance. Second, the decision is constrained by the fact that some of the pairs may not work at all due to incompatible IP versions, outages somewhere in the network, problems at the local link at either end, and so on. MOBIKE solves this problem by taking a simple approach: the party that initiated the IKE_SA (the "client" in remote access VPN scenario) is responsible for deciding which address pair is used for the IPsec SAs, and collecting the information it needs to make this Eronen Expires April 2, 2006 [Page 4]
Internet-Draft MOBIKE Protocol September 2005 decision (such as determining which address pairs work or do not work). The other party (the "gateway" in remote access VPN scenario) simply tells the initiator what addresses it has, but does not update the IPsec SAs until it receives a message from the initiator to do so. Making the decision at the initiator is consistent with how normal IKEv2 works: the initiator decides which addresses it uses when contacting the responder. It also makes sense especially when the initiator is the mobile node: it is in a better position to decide which of its network interfaces should be used for both upstream and downstream traffic. The details of exactly how the initiator makes the decision, what information is used in making it, how the information is collected, how preferences affect the decision, and when a decision needs to be changed, are largely beyond the scope of MOBIKE. This does not mean that these details are unimportant: on the contrary, they are likely to be crucial in any real system. However, MOBIKE is concerned with these details only to the extent that they are visible in IKEv2/IPsec messages exchanged between the peers (and thus need to be standardized to ensure interoperability). Many of these issues are also not specific to MOBIKE, but common with the use of existing hosts in dynamic environments or with mobility protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms already exist or are being developed to deal with these issues. For instance, link layer and IP layer mechanisms can be used to track the status of connectivity within the local link [RFC2461], movement detection is being specified in for both IPv4 and IPv6 [DNA4] [DNA6], and so on. Updating the addresses of IPsec SAs naturally has to take into account several security considerations. MOBIKE includes two features designed to address these considerations. First, a "return routability" check can be used to verify the addresses provided by the peer. This makes it more difficult to flood third parties with large amounts of traffic. Second, a "NAT prohibition" feature ensures that IP addresses have not been modified by NATs, IPv4/IPv6 translation agents, or other similar devices. This feature is mainly intended for site-to-site VPNs where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered to be an attack. 3.2 Example Protocol Runs A simple MOBIKE exchange in a mobile scenario is illustrated below: Eronen Expires April 2, 2006 [Page 5]
Internet-Draft MOBIKE Protocol September 2005 Initiator Responder ----------- ----------- 1) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) 2) HDR, SK { IDi, CERT, AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr, N(MOBIKE_SUPPORTED) } --> <-- HDR, SK { IDr, CERT, AUTH, CP(CFG_REPLY), SAr2, TSi, TSr, N(MOBIKE_SUPPORTED) } (Initiator gets information from lower layers that its attachment point and address has changed.) 3) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP) } --> <-- HDR, SK { N(NAT_DETECTION_*_IP) } (Responder verifies that the initiator has given it a correct IP address.) 4) <-- HDR, SK { N(COOKIE2) } HDR, SK { N(COOKIE2) } --> Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform each other that they support MOBIKE. In step 3, the initiator notices a change in its own address, and informs the responder about this. At this point, it also starts to use the new address as a source address in its own outgoing ESP traffic. The responder records the new address, and if so required by policy, performs a return routability check of the address. When this check completes, the responder starts to use the new address as the destination for its outgoing ESP traffic. Another protocol run in multihoming scenario is illustrated below. In this scenario the initiator has one address but the responder has two. Eronen Expires April 2, 2006 [Page 6]
Internet-Draft MOBIKE Protocol September 2005 Initiator Responder ----------- ----------- 1) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) 2) HDR, SK { IDi, CERT, AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr, N(MOBIKE_SUPPORTED) } --> <-- HDR, SK { IDr, CERT, AUTH, CP(CFG_REPLY), SAr2, TSi, TSr, N(MOBIKE_SUPPORTED), N(ADDITIONAL_IPV4_ADDRESS) } (The initiator suspects a problem in the currently used address pair, and probes its liveness.) 3) HDR, SK { N(NAT_DETECTION_*_IP) } --> <-- HDR, SK { N(NAT_DETECTION_*_IP) } (The initiator gives up on the current address pair, and tests the other available address pair.) 4) HDR, SK { N(NAT_DETECTION_*_IP), N(COOKIE2) } --> <-- HDR, SK { N(NAT_DETECTION_*_IP), N(COOKIE2) } (This worked, and the initiator requests the peer to switch to new addresses.) 5) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP) } --> <-- HDR, SK { N(NAT_DETECTION_*_IP) } Eronen Expires April 2, 2006 [Page 7]
Internet-Draft MOBIKE Protocol September 2005 3.3 MOBIKE and Network Address Translation (NAT) In some MOBIKE scenarios the network may contain NATs or stateful packet filters (for brevity, the rest of this document talks simply about NATs). The NAT Traversal feature specified in [IKEv2] allows IKEv2 to work through NATs in many cases, and MOBIKE can leverage this functionality: when the addresses used for IPsec SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. Nevertheless, there are some limitations since NATs usually introduce an asymmetry in the network: only packets coming from the "inside" cause state to be created. This asymmetry leads to restrictions on what MOBIKE can do. To give a concrete example, consider a situation where both peers have only a single address, and the initiator is behind a NAT. If the responder's address now changes, it needs to send a packet to the initiator using its new address. However, if the NAT is, for instance, of the common "restricted cone" type (see [STUN] for one description of different NAT types), this is not possible: the NAT will drop packets sent from the new address (unless the initiator has previously sent a packet to that address -- which it cannot do until it knows the address). For simplicity, MOBIKE does not attempt to handle all possible NAT- related scenarios. Instead, MOBIKE assumes that if NATs are present, the initiator is the party "behind" the NAT, and does not fully support the case where the responder's addresses change. "Does not fully support" means that no special effort is made to support this functionality. However, if the alternative is losing connectivity completely, the responder can still attempt to proceed with the change, and depending on, e.g., the exact type of NAT, it may succeed. However, analyzing the exact circumstances when this will or will not work is not done in this document. 3.4 Limitations This document focuses on the main scenario outlined in Section 1, and supports only tunnel mode. The base version of the MOBIKE protocol may not cover all potential future use scenarios, such as transport mode, application to securing SCTP or optimizations desirable in specific circumstances. Future extensions may be defined later to support additional requirements. Eronen Expires April 2, 2006 [Page 8]
Internet-Draft MOBIKE Protocol September 2005 4. Protocol Exchanges 4.1 Signaling Support for MOBIKE Implementations that wish to use MOBIKE for a particular IKE_SA MUST include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload). The format of the MOBIKE_SUPPORTED notification is described in Section 5. 4.2 Initial Tunnel Header Addresses When an IPsec SA is created, the tunnel header IP addresses (and port if doing UDP encapsulation) are taken from the IKE_SA, not the IP header of the IKEv2 message requesting the IPsec SA. The addresses in the IKE_SA are initialized as follows: If the IKE_SA_INIT request contains the NAT_DETECTION_*_IP notifications and the responder supports NAT Traversal, the values are initialized from the IP header of the first IKE_AUTH request. Otherwise, the values are initialized from the IP header of the IKE_SA_INIT request. The addresses are taken from the IKE_AUTH request when NAT Traversal is being used because IKEv2 requires changing from port 500 to 4500 if a NAT is discovered. To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them (this way, there is no need to change the ports later). 4.3 Additional Addresses Both the initiator and responder MAY include one or more ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload). Eronen Expires April 2, 2006 [Page 9]
Internet-Draft MOBIKE Protocol September 2005 Initiator Responder ----------- ----------- HDR, SK { IDi, [CERT], [IDr], AUTH, [CP(CFG_REQUEST)] SAi2, TSi, TSr, N(MOBIKE_SUPPORTED), [N(ADDITIONAL_*_ADDRESS)+] } --> <-- HDR, SK { IDr, [CERT], AUTH, [CP(CFG_REPLY)], SAr2, TSi, TSr, N(MOBIKE_SUPPORTED) [N(ADDITIONAL_*_ADDRESS)+] } The recipient stores this information, but no other action is taken at this time. Although both the initiator and responder maintain a set of peer addresses (logically associated with the IKE_SA), it is important to note that they use this information for slightly different purposes. The initiator uses the set of responder addresses as an input to its address selection policy; it may at some later point decide to move the IPsec traffic to one of these addresses using the procedure described in Section 4.4. The responder normally does not use the set of initiator addresses for anything: the addresses are used only when the responder's own addresses change (see Section 4.5). The set of addresses available to the peers can change during the lifetime of the IKE_SA. The procedure for updating this information is described in Section 4.5. Note that if some of the initiator's interfaces are behind a NAT (from the responder's point of view), the addresses received by the responder will be incorrect. This means the procedure for changing responder addresses described in Section 4.5 does not fully work when the initiator is behind a NAT. For the same reason, the peers also SHOULD NOT use this information for any other purposes than what is explicitly described in this document. Eronen Expires April 2, 2006 [Page 10]
Internet-Draft MOBIKE Protocol September 2005 4.4 Changing Addresses in IPsec SAs In MOBIKE, the initiator decides what addresses are used in the IPsec SAs. That is, the responder usually never updates any IPsec SAs without receiving an explicit UPDATE_SA_ADDRESSES request from the initiator. (As described below, the responder can, however, update the IKE_SA in some circumstances.) The reasons why the initiator wishes to change the addresses are largely beyond the scope of MOBIKE. Typically triggers include information received from lower layers, such as changes in IP addresses or link-down indications. Some of this information can be unreliable: for instance, ICMP messages could be spoofed by an attacker. Unreliable information itself MUST NOT be used to conclude than an update is needed: instead, the initiator SHOULD trigger dead peer detection (that is, send an INFORMATIONAL request). Changing addresses can also be triggered by events within IKEv2. At least the following events can cause the initiator to re-evaluate its local address selection policy, possibly leading to changing the addresses. o An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working. o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS notifications is received. This means the peer's addresses may have changed. o An UNACCEPTABLE_ADDRESSES notification is received as a response to address update request (described below). o The initiator receives a NAT_DETECTION_DESTINATION_IP notification that does not match the previous UPDATE_SA_ADDRESSES response (see Section 4.7 for a more detailed description). The description in the rest of this section assumes that the initiator has already decided what the new addresses should be. When this decision has been made, the initiator: o Updates the IKE_SA with the new addresses, and sets the "pending_update" flag in the IKE_SA. o Updates the IPsec SAs associated with this IKE_SA with the new addresses (unless the initiator's policy requires a return routability check before updating the IPsec SAs, and the check has not been done for this responder address yet). Eronen Expires April 2, 2006 [Page 11]
Internet-Draft MOBIKE Protocol September 2005 o If the IPsec SAs were updated in the previous step: If NAT Traversal is not enabled, and the responder supports NAT Traversal (as indicated by NAT detection payloads in the IKE_SA_INIT exchange), and the initiator either suspects or knows that a NAT is likely to be present, enables NAT Traversal. o If there are outstanding IKEv2 requests (requests for which the initiator has not yet received a reply), continues retransmitting them using the addresses in the IKE_SA (the new addresses). o When the window size allows, sends an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification (which does not contain any data), and clears the "pending_update" flag. The request will be as follows: Initiator Responder ----------- ----------- HDR, SK { N(UPDATE_SA_ADDRESSES), [N(NAT_DETECTION_*_IP)], [N(NO_NATS_ALLOWED)], [N(COOKIE2)] } --> o If a new address change occurs while waiting for the response, starts again from the first step (and ignores responses to this UPDATE_SA_ADDRESSES request). When processing an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification, the responder: o Determines whether it has already received a newer UPDATE_SA_ADDRESSES request than this one (if the responder uses a window size greater than one, it is possible that requests are received out of order). If it has, a normal response message (described below) is sent, but no other action is taken. o If the NO_NATS_ALLOWED notification is present, processes it as described in Section 4.8. o Checks that the (source IP address, destination IP address) pair in the IP header is acceptable according to local policy. If it is not, replies with a message containing the UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). o Updates the IP addresses in the IKE_SA with the values from the IP header. (Using the address from the IP header is consistent with normal IKEv2, and allows IKEv2 to work with NATs without needing unilateral self-address fixing [UNSAF].) Eronen Expires April 2, 2006 [Page 12]
Internet-Draft MOBIKE Protocol September 2005 o Replies with an INFORMATIONAL response: Initiator Responder ----------- ----------- <-- HDR, SK { [N(NAT_DETECTION_*_IP)], [N(COOKIE2)] } o If necessary, initiates a return routability check for the new initiator address (see Section 4.6) and waits until the check is completed. o Updates the IPsec SAs associated with this IKE_SA with the new addresses. o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal. When the initiator receives the reply, it: o If an address change has occurred after the request was first sent, no MOBIKE processing is done for the reply message, since a new UPDATE_SA_ADDRESSES is going to be sent (or has already been sent, if window size greater than one is in use). o If the response contains the UNEXPECTED_NAT_DETECTED notification, processes it as described in Section 4.8. o If the response contains an UNACCEPTABLE_ADDRESSES notification, the initiator MAY select another addresses and retry the exchange, keep on using the current addresses, or disconnect. o Updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done before sending the request). o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal. There is one exception to the rule that the responder never updates any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If the source address the responder is currently using becomes unavailable (i.e., sending packets using that source address is no longer possible), the responder is allowed to update the IPsec SAs to use some other address (in addition to initiating the procedure described in the next section). Eronen Expires April 2, 2006 [Page 13]
Internet-Draft MOBIKE Protocol September 2005 4.5 Updating Additional Addresses As described in Section 4.3, both the initiator and responder can send a list of additional addresses in the IKE_AUTH exchange. This information can be updated by sending an INFORMATIONAL exchange request message that contains either one or more ADDITIONAL_IP4/ 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. The message exchange will look as follows: Initiator Responder ----------- ----------- HDR, SK { [N(ADDITIONAL_*_ADDRESS)+], [N(NO_ADDITIONAL_ADDRESSES)], [N(NO_NATS_ALLOWED)], [N(COOKIE2)] } --> <-- HDR, SK { [N(COOKIE2)] } When a request containing ADDITIONAL_*_ADDRESS or NO_ADDITIONAL_ADDRESSES notification is received, the exchange responder: o Determines whether it has already received a newer request to update the addresses (if a window size greater than one is used, it is possible that the requests are received out of order). If it has, a response message is sent, but the address set is not updated. o If the NO_NATS_ALLOWED notification is present, processes it as described in Section 4.8. o Updates the set of peer addresses based on the IP header and ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS notifications. o Sends a response. The initiator MAY include these notifications in the same request as UPDATE_SA_ADDRESSES. If the request to update the addresses is retransmitted using several different source addresses, a new INFORMATIONAL request MUST be sent. There is one additional complication: when the responder wants to update the address set, the currently used addresses may no longer work. In this case, the responder uses the additional address list received from the initiator and the list of its own addresses to determine which addresses to use for sending the INFORMATIONAL request. This is the only time the responder uses the additional Eronen Expires April 2, 2006 [Page 14]
Internet-Draft MOBIKE Protocol September 2005 address list received from the initiator. Note that both peers can have their own policies about what addresses are acceptable to use. A minimal "mobile client" could have a policy that says that only the responder's address specified in local configuration is acceptable. This kind of client does not have to send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a simple "VPN gateway" that has only a single address, and is not going to change it, does not need to send or understand ADDITIONAL_*_ADDRESS notifications. 4.6 Return Routability Check Both parties can optionally verify that the other party can actually receive packets at the claimed address. This "return routability check" can be done before updating the IPsec SAs, immediately after updating them, or continuously during the connection. By default, return routability check SHOULD be done before updating the IPsec SAs. In environments where the peer is expected to be well-behaving (many corporate VPNs, for instance), or the address can be verified by some other means (e.g., the address is included in the peer's certificate), the return routability check MAY be omitted or postponed until after the IPsec SAs have been updated. Any INFORMATIONAL exchange can be used for return routability purposes (with one exception, described below): when a valid response is received, we know the other party can receive packets at the claimed address. To ensure that the peer cannot generate the correct INFORMATIONAL response without seeing the request, a new payload is added to INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY include a COOKIE2 notification, and if included, the recipient of an INFORMATIONAL request MUST copy the notification as-is to the response. When processing the response, the original sender MUST verify that the value is the same one as sent. If the values do not match, the IKE_SA MUST be closed. If the same INFORMATIONAL request has been sent to several different addresses (i.e., the destination address in the IKE_SA has been updated after the request was first sent), receiving the INFORMATIONAL response does not tell which address is the working one. In this case, a new INFORMATIONAL request needs to be sent to check return routability. Eronen Expires April 2, 2006 [Page 15]
Internet-Draft MOBIKE Protocol September 2005 4.7 Changes in NAT Mappings IKEv2 performs Dead Peer Detection (DPD) if there has recently been only outgoing traffic on all of the SAs associated with the IKE_SA. In MOBIKE, these messages can also be used to detect if NAT mappings have changed (for example, if the keepalive internal is too long, or the NAT box is rebooted). More specifically, if both peers support both this specification and NAT Traversal, NAT_DETECTION_*_IP notifications MAY be included in any INFORMATIONAL request; if the request includes them, the responder MUST also include them in the response (but no other action is taken, unless otherwise specified). When the initiator is behind a NAT (as detected earlier using NAT_DETECTION_*_IP notifications), it SHOULD include these notifications in DPD messages, and compare the received NAT_DETECTION_DESTINATION_IP notifications with the value from the previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). If the values do not match, the IP address and/or port seen by the responder has changed, and the initiator SHOULD send UPDATE_SA_ADDRESSES as described in Section 4.4. When MOBIKE is in use, the dynamic updates specified in [IKEv2] Section 2.23 (where the peer address and port are updated from the last valid authenticated packet) work in a slightly different fashion. The host not behind a NAT MUST NOT use these dynamic updates for IKEv2 packets, but MAY use them for ESP packets. This ensures that an INFORMATIONAL exchange that does not contain UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be used for, e.g., testing whether a particular path works. 4.8 NAT Prohibition Basic IKEv2/IPsec without NAT Traversal support may work across some types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in tunnel mode. This is because the IKEv2 integrity checksum does not cover the addresses in the IP header. This may be considered a problem in some circumstances, since in some sense any modification of the IP addresses can be considered to be an attack. This specification addresses the issue by protecting the IP addresses when NAT Traversal has not been explicitly enabled. This means that MOBIKE without NAT Traversal support will not work if the paths contain NATs, IPv4/IPv6 translation agents, or other nodes that modify the addresses in the IP header. This feature is mainly intended for site-to-site VPN cases, where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered to be an attack. Eronen Expires April 2, 2006 [Page 16]
Internet-Draft MOBIKE Protocol September 2005 More specifically, when NAT Traversal is not enabled, all messages that can update the addresses associated with the IKE_SA and/or IPsec SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS notifications) MUST also include a NO_NATS_ALLOWED notification. The exchange responder MUST verify that the contents of the NO_NATS_ALLOWED notification match the addresses in the IP header. If they do not match, a response containing an UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the IKE_SA_INIT exchange, no state is created at the responder). The response message is sent to the address and port the corresponding request came from, not the address contained in the NO_NATS_ALLOWED notification. If the exchange initiator receives an UNEXPECTED_NAT_DETECTION notification in response to its request, it SHOULD retry the operation several times using new IKE_SA_INIT/INFORMATIONAL requests. This ensures that an attacker who is able to modify only a single packet does not unnecessarily cause a path to remain unused. If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange responder MUST NOT use the contents of the NO_NATS_ALLOWED notification for any other purpose than possibly logging the information for troubleshooting purposes. 4.9 Path Testing IKEv2 Dead Peer Detection allows the peers to detect if the currently used path has stopped working. However, if either of the peers has several addresses, Dead Peer Detection alone does not tell which of the other paths might work. If required by its address selection policy, the initiator can use normal IKEv2 INFORMATIONAL request/response messages to test whether a certain path works. Implementations MAY do path testing even if the currenly used path is working to, for example, detect when a better (but previously unavailable) path becomes available. 4.10 Failure Recovery and Timeouts In MOBIKE, the initiator is responsible for detecting and recovering from most failures. To give the initiator enough time to detect the error, the responder SHOULD use relatively long timeout intervals when, for instance, retransmitting IKEv2 requests or deciding whether to initiate dead peer detection. While no specific timeout lengths are required, it is suggested that responders continue retransmitting IKEv2 requests Eronen Expires April 2, 2006 [Page 17]
Internet-Draft MOBIKE Protocol September 2005 for at least five minutes before giving up. Eronen Expires April 2, 2006 [Page 18]
Internet-Draft MOBIKE Protocol September 2005 5. Payload Formats 5.1 MOBIKE_SUPPORTED Notify Payload The MOBIKE_SUPPORTED notification is included in the IKE_AUTH exchange to indicate that the implementation supports this specification. The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. 5.2 ADDITIONAL_IP4/6_ADDRESS Notify Payloads Both parties can include ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and INFORMATIONAL exchange request messages; see Section 4.3 and Section 4.5 for more detailed description. The Notify Message Types for ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3, respectively. The Protocol ID and SPI Size fields are set to zero. The data associated with these Notify types is either a four-octet IPv4 address or a 16-octet IPv6 address. 5.3 NO_ADDITIONAL_ADDRESSES Notify Payload The NO_ADDITIONAL_ADDRESSES notification can be included in an INFORMATIONAL exchange request messages to indicate that the exchange initiator does not have addresses beyond the one used in the exchange (see Section 4.5 for more detailed description). The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. 5.4 UPDATE_SA_ADDRESSES Notify Payload This notification is included in INFORMATIONAL exchange requests sent by the initiator to update addresses of the IKE_SA and IPsec SAs (see Section 4.4). The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. Eronen Expires April 2, 2006 [Page 19]
Internet-Draft MOBIKE Protocol September 2005 5.5 UNACCEPTABLE_ADDRESSES Notify Payload The responder can include this notification in an INFORMATIONAL exchange response to indicate that the address change in the corresponding request message (which contained an UPDATE_SA_ADDRESSES notification) was not carried out. The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. 5.6 COOKIE2 Notify Payload This notification MAY be included in any INFORMATIONAL request for return routability check purposes (see Section 4.6). If the INFORMATIONAL request includes COOKIE2, the exchange responder MUST copy the notification to the response message. The data associated with this notification MUST be between 8 and 64 octets in length (inclusive), and MUST be chosen by the exchange initiator in a way that is unpredictable to the exchange responder. The Notify Message Type for this message is TBD-BY-IANA7. The Protocol ID and SPI Size fields are set to zero. 5.7 NO_NATS_ALLOWED Notify Payload See Section 4.8 for a description of this notification. The data field of this notification contains the following information: the IP address and port from which the packet was sent, and the IP address and port to which the packet was sent. The Notify Message Type for this message is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to zero. 5.8 UNEXPECTED_NAT_DETECTED Notify Payload See Section 4.8 for a description of this notification. The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. Eronen Expires April 2, 2006 [Page 20]
Internet-Draft MOBIKE Protocol September 2005 6. Security Considerations The main goals of this specification are to not reduce the security offered by usual IKEv2 procedures and to counter mobility related threats in an appropriate manner. This section describes new security considerations introduced by MOBIKE. See [IKEv2] for security considerations for IKEv2 in general. 6.1 Traffic Redirection and Hijacking MOBIKE payloads relating to updating addresses are encrypted, integrity protected, and replay protected using the IKE_SA. This assures that no one except the participants can, for instance, give a control message to change the addresses. However, just like with normal IKEv2, the actual IP addresses in the IP header are not covered by the integrity protection. This means that a NAT between the parties (or an attacker acting as a NAT) can modify the addresses and cause incorrect tunnel header (outer) IP addresses to be used for IPsec SAs. The scope of this attack is limited mainly to denial-of-service, since all traffic is protected using IPsec. This attack can only be launched by on-path attackers that are capable of modifying IKEv2 messages carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the IP header of these packets, the attackers can lead the peers believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and update the addresses appropriately. MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification of the addresses in the IP header by outsiders. When this notification is used, communication through NATs and other address translators is impossible, so it is sent only when not doing NAT Traversal. This feature is mainly intended for site-to-site VPN cases, where the administrators may know beforehand that valid NATs are not present, and thus any modification to the packet can be considered to be an attack. 6.2 IPsec Payload Protection The use of IPsec protection on payload traffic protects the participants against disclosure of the contents of the traffic, should the traffic end up in an incorrect destination or be Eronen Expires April 2, 2006 [Page 21]
Internet-Draft MOBIKE Protocol September 2005 eavesdropped along the way. However, security associations originally created for the protection of a specific flow between specific addresses may be updated by MOBIKE later on. This has to be taken into account if the level of required protection depends on, for instance, the current location of the VPN client. It is recommended that security policies for peers that are allowed to use MOBIKE are configured in a manner that takes into account that a single security association can be used through paths of varying security properties at different times. 6.3 Denial-of-Service Attacks Against Third Parties Traffic redirection may be performed not just to gain access to the traffic (not very interesting since it is encrypted) or to deny service to the peers, but also to cause a denial-of-service attack for a third party. For instance, a high-speed TCP session or a multimedia stream may be redirected towards a victim host, causing its communications capabilities to suffer. The attackers in this threat can be either outsiders or even one of the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers can be easily dealt with if the authentication performed in the initial IKEv2 negotiation can be traced to persons who can be held responsible for the attack. This may not be the case in all scenarios, particularly with opportunistic approaches to security. Normally such attacks would expire in a short time frame due to the lack of responses (such as transport layer acknowledgements) from the victim. However, as described in [Aura02], malicious participants would typically be able to spoof such acknowledgements and maintain the traffic flow for an extended period of time. For instance, if the attacker opened the TCP stream itself before redirecting it to the victim, the attacker becomes aware of the sequence number space used in this particular session. It should also be noted, as shown in [Bombing], that without ingress filtering in the attacker's network such attacks are already possible simply by sending spoofed packets from the attacker to the victim directly. Furthermore, if the attacker's network has ingress filtering, this attack is largely prevented for MOBIKE as well. Consequently, it makes little sense to protect against attacks of similar nature in MOBIKE. However, it still makes sense to limit the amplification capabilities provided to attackers, so that they cannot use stream redirection to send a large number of packets to the victim by sending just a few packets themselves. Eronen Expires April 2, 2006 [Page 22]
Internet-Draft MOBIKE Protocol September 2005 This specification includes return routability tests to limit the duration of any "third party bombing" attacks by off-path (relative to the victim) attackers. The tests are authenticated messages that the peer has to respond to, and can be performed either before the address change takes effect, immediately afterwards, or even periodically during the session. The tests contain unpredictable data, and only someone who has the keys associated with the IKE SA and has seen the request packet can properly respond to the test. 6.4 Spoofing Network Connectivity Indications Attackers may spoof various indications from lower layers and the network in an effort to confuse the peers about which addresses are or are not working. For example, attackers may spoof link-layer error messages in an effort to cause the parties to move their traffic elsewhere or even to disconnect. Attackers may also spoof information related to network attachments, router discovery, and address assignments in an effort to make the parties believe they have Internet connectivity when in reality they do not. This may cause use of non-preferred addresses or even denial-of- service. MOBIKE does not provide any protection of its own for indications from other parts of the protocol stack. These vulnerabilities can be mitigated through the use of techniques specific to the other parts of the stack, such as validation of ICMP errors [ICMPAttacks], link layer security, or the use of [SEND] to protect IPv6 Router and Neighbor Discovery. Ultimately MOBIKE depends on the delivery of IKEv2 messages to determine which paths can be used. If IKEv2 messages sent using a particular source and destination addresses reach the recipient and a reply is received, MOBIKE will usually consider the path working; if no reply is received even after retransmissions, MOBIKE will suspect the path is broken. An attacker who can consistently control the delivery or non-delivery of the IKEv2 messages in the network can thus influence which addresses actually get used. 6.5 Address and Topology Disclosure MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications reveal information about which networks the peers are connected to. For example, consider a host A with two network interfaces: a cellular connection and a wired Ethernet connection to a company LAN. If host A now contacts host B using IKEv2/MOBIKE and sends ADDITIONAL_IP4/6_ADDRESS notifications, host B receives additional Eronen Expires April 2, 2006 [Page 23]
Internet-Draft MOBIKE Protocol September 2005 information it might not otherwise know. If host A used the cellular connection for the IKEv2/MOBIKE traffic, host B can also see the company LAN address (and perhaps further guess that host A is used by an employee of that company). If host A used the company LAN to make the connection, host B can see that host A has a subscription from this particular cellular operator. These additional addresses can also disclose more accurate location information than just a single address. Suppose that host A uses its cellular connection for IKEv2/MOBIKE traffic, but also sends an ADDITIONAL_IP4_ADDRESS notification containing an IP address corresponding to, say, a wireless LAN at a particular coffee shop location. It is likely that host B can now make a much better guess at A's location than would be possible based on the cellular IP address alone. Furthermore, as described in Section 4.3, some of the addresses could also be private addresses behind a NAT. In many environments, disclosing address information is not a problem (and indeed it cannot be avoided if the hosts wish to use those addresses for IPsec traffic). For instance, a remote access VPN client could consider the corporate VPN gateway sufficiently trustworthy for this purpose. However, if MOBIKE is used in some more opportunistic approach, it can be desirable to limit the information that is sent. The peers naturally do not have to disclose any addresses they do not want to use for IPsec traffic. Also, as noted in Section 4.5, an initiator whose policy is to always use the locally configured responder address does not have to send any ADDITIONAL_IP4/6_ADDRESS payloads. 7. IANA Considerations This document does not create any new namespaces to be maintained by IANA, but it requires new values in namespaces that have been defined in the IKEv2 base specification [IKEv2]. This document defines several new IKEv2 notifications whose values are to be allocated from the "IKEv2 Notify Message Types" namespace. Eronen Expires April 2, 2006 [Page 24]
Internet-Draft MOBIKE Protocol September 2005 Notify Message Value --------------------------- ----- MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) COOKIE2 TBD-BY-IANA7 (16396..40959) NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) These notifications are described in Section 5. 8. Acknowledgements This document is a collaborative effort of the entire MOBIKE WG. We would particularly like to thank Jari Arkko, Francis Dupont, Paul Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also incorporates ideas and text from earlier MOBIKE protocol proposals, including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design document [Design]. 9. References 9.1 Normative References [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. [IPsecArch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), March 2005. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [UDPEncap] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. Eronen Expires April 2, 2006 [Page 25]
Internet-Draft MOBIKE Protocol September 2005 9.2 Informative References [AddrMgmt] Dupont, F., "Address Management for IKE version 2", draft-dupont-ikev2-addrmgmt-07 (work in progress), May 2005. [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proc. 18th Annual Computer Security Applications Conference (ACSAC), December 2002. [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), June 2005. [DNA4] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", draft-ietf-dhc-dna-ipv4-15 (work in progress), August 2005. [DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network Attachment in IPv6 - Best Current Practices for hosts", draft-ietf-dna-hosts-01 (work in progress), June 2005. [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", draft-ietf-mobike-design-02 (work in progress), February 2005. [ICMPAttacks] Gont, F., "ICMP attacks against TCP", draft-gont-tcpm-icmp-attacks-03 (work in progress), December 2004. [Kivinen] Kivinen, T., "MOBIKE protocol", draft-kivinen-mobike-protocol-00 (work in progress), February 2004. [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- IKE)", draft-eronen-mobike-mopo-02 (work in progress), February 2005. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Eronen Expires April 2, 2006 [Page 26]
Internet-Draft MOBIKE Protocol September 2005 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and Multihoming Extensions for IKEv2 (SMOBIKE)", draft-eronen-mobike-simple-00 (work in progress), March 2004. [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. Author's Address Pasi Eronen (editor) Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: email@example.com Appendix A. Changelog (This section should be removed by the RFC editor.) Changes from -02 to -03: o Editorial fixes and clarifications (issues 42 and 43). o Clarified IANA considerations (issue 42). o Added security considerations about address and topology disclosure (issue 42). o Added a suggestion about retransmission timeout (issue 42). o Change dynamic address updates: MUST NOT do them based on IKEv2 packets, MAY do based on ESP (issue 34). Eronen Expires April 2, 2006 [Page 27]
Internet-Draft MOBIKE Protocol September 2005 o Mandate NAT prohibition if not doing NAT traversal (issue 41). o Clarified security considerations related to NATs (issue 41). o Don't use SHA-1 in NO_NATS_ALLOWED, just send the addresses (issue 42). o Added a short section about path testing. o Added an example protocol run in Section 1. Changes from -01 to -02: o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35, 37). o Changed terminology related to NAT prohibition (issues 22, 24). o Rewrote much of the ADDITIONAL_*_ADDRESS text, added NO_ADDITIONAL_ADDRESSES notification. o Use NAT detection payloads to detect changes in NAT mappings (issue 34). o Removed separate PATH_TEST message (issue 34). o Clarified processing of UNACCEPTABLE_ADDRESSES when request has been sent using several different addresses (issue 36). o Clarified changing of ports 500/4500 (issue 33). o Updated security considerations (issues 27 and 28). o No need to include COOKIE2 in non-RR messages (issue 32). o Many editorial fixes and clarifications (issue 38, 40). o Use the terms initiator and responder more consistently. o Clarified that this document does not solve all problems in MOBIKE WG charter (issue 40). Changes from -00 to -01: o Editorial fixes and small clarifications (issues 21, 25, 26, 29). o Use Protocol ID zero for notifications (issue 30). Eronen Expires April 2, 2006 [Page 28]
Internet-Draft MOBIKE Protocol September 2005 o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue 23). o Use the word "path" only in senses that include the route taken (issue 29). Eronen Expires April 2, 2006 [Page 29]
Internet-Draft MOBIKE Protocol September 2005
Intellectual Property Statement
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
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eronen Expires April 2, 2006 [Page 30]


text:
For just $23.99, you could grab one of this 1.3 Megapixel USB Webcam from Light In The Box. This affordable webcam comes with a 1.3MP CMOS image sensor, a built-in high quality microphone, a USB 2.0 connection interface and can capture 640 x 480 VGA video at 30fps. [Product Page]
1.3 Megapixel USB Webcam
Previous post: Nikon WU-1a Wireless Mobile Adapter
Next post: Lomography Monochrome Edition
Comments on this entry are closed.

subset: commoncrawl


text:
Key things you need to know aboutDr. Kayani:
Dr. Kayani's Experience
Research training, expertise and qualifications
Dr. Kayani's Specialties
- Geriatric Medicine
- View 1 specialty and 2 board certifications
Conditions Dr. Kayani Treats
- Alzheimer's Disease
- Anxiety
- See all 5 conditions
More About Dr. Kayani's Background
Hospital Quality
The right hospital is as important as the right doctor
- Summa Barberton Hospital
- 155 5th Street North East
- Barberton, OH 44203
- Summa Akron City and St. Thomas Hospitals
- 525 East Market Street
- Akron, OH 44309
9 Facts About Hospital Quality
Patients' risk of dying during a hospital stay for heart bypass surgery could be 85.2% lower, on average, at a hospital rated 5 stars compared to a hospital rated 1 star for that procedure. Choosing the right hospital is critical to your health. View Slideshow
Patient Satisfaction
Patients' feedback on their experience with Dr. Kayani
Be the first to evaluate Dr. Kayani by taking our Patient Satisfaction Survey.
Your feedback will help other patients make informed decisions, and let the doctor know how she's doing.
8 Facts About Patient Satisfaction Surveys
Patient satisfaction surveys provide a standardized way of reporting about healthcare experiences. But there can be more than meets the eye when reviewing scores. Here's what you should know
Appointments & Offices
Check insurance plans, locations and make an appointment
Accepting new patients?
- Yes
- Summa Physicians - Geriatric Medicine
- Summa Physicians-Geriatric Medicine
- 75 Arch St Ste G2
- Akron, OH 44304
- Center For Senior Health
- Center For Senior Health
- 75 Arch St Ste G2
- Akron, OH 44304
7 Tips to Prepare for Your Appointment
The key to a successful appointment is communication. To get the most out of your visit, prepare ahead of time so you can lead the conversation with your doctor. These 7 tips will get you ready


text:
ACCORDING to the "Guinness Book of Records", the most sparsely populated place on earth is the Antarctic. Anyone spending a day at a county cricket match, watching what is supposedly England's national summer game, might challenge this claim. Forget the packed ballparks of major-league baseball, or the roaring football grounds of Barcelona, Manchester and Turin; the "crowd" at county cricket seems to consist mainly of a few pensioners and perhaps a dog or two. Even last week's meeting of Yorkshire and Kent, a crucial fixture at the climax of the county championship, the premier competition, could draw no more than 3,750. Only the semi-finals and finals of one-day knockout tournaments, and international matches, attract full houses.
To most English cricket-lovers, this would not matter much if the national cricket team were any good. It isn't. In this summer's series against Australia, admittedly the world's finest team, the English were lucky to lose 3-2.
Enter, at the start of this year, Lord MacLaurin, ex-boss of Tesco, a supermarket chain, as chairman of the England and Wales Cricket Board. His remit: to inject some life into the sport, in the hope that it might improve at all levels, but especially at the top. On September 15th, the county clubs spurned his final proposals. Lord MacLaurin deserved better. The counties deserve a loud raspberry.
Lord MacLaurin suggested splitting the 18-team county championship into two divisions, with promotion and relegation between them. That would have meant most counties would be playing meaningful matches until the end of the season, instead of losing any interest in prizes halfway through. No, said the counties. The existing system remains, with an add-on: the top eight will play a knockout tournament of one-day games at the start of the following season. The counties reason thus: a two-division championship will condemn some to second-rate status, and thus cost money. An extra one-day tournament, however, might bring in at least one big crowd.
Tosh. The fact is that championship crowds will stay small come what may—most of it is played when most cricket-lovers are at work or school. But promotion and relegation clashes might bring in a few more customers; and, with more at stake, they ought to make county cricketers into better players. Ultimately that would have benefited the national side, which in turn makes the money that keeps many county clubs going. More than that, a stronger England team is the likeliest way of getting more people to play cricket and to pay to watch it. Meanwhile, the Aussies march on.


text:
Lisa Ray (I)
Lisa Ray was finishing high school in Canada with aspirations of majoring in Journalism at University when a celebrated fashion magazine approached her to model for them, and she ended up on the cover. This catapulted her into a state of instant celebrity. Her high-profile career got her noticed by Indian filmmakers, but she refused many offers ...
See full bio »


text:
Arrangements have been made to enable the inmates of the designation camps of the valley based underground organisations to cast their votes on Thursday. Talking to reporters on Tuesday the chief electoral officer, Manipur, O. Nabakishore said that there are 584 former insurgents in the camps belonging to seven underground organisations. These underground outfits had signed the Memorandum of Understanding with the central and state governments.
He said that he had written a letter to the authority to allow them to cast their votes. These inmates could go to their villages and if their names are in the electoral rolls they could cast their votes.
However sources said that in practical terms it means that these inmates cannot exercise their franchise. First on security grounds they cannot go to their villages. Besides as they have been underground for a number of years their names do not appear in the electoral rolls. The chief electoral officer did not explain why he is taking this double standard since these conditions were not applied in case of the tribal outfits which are signatories to the suspension of operations. The suspension of operations signatories were allowed to cast their votes in full combat fatigue and wielding automatic rifles in the hill districts.
It may be recalled that the other day leaders of these outfits said that they would go back to the jungles and take up arms if they are denied the right to voting. What the chief electoral officer said is not the solution since under the arrangements the inmates of the designated camps cannot cast their votes. The CEO further said that 136 companies of security forces and 47 companies of unarmed companies will be deployed in the valley districts to ensure law and order during the elections on Thursday.
Keywords: Manipur, former insurgents, Designation camps, Lok Sabha elections 2014, Voting


text:
BC Children's and BC Women's Redevelopment Project is building a new Teck Acute Care Centre at BC Children's Hospital in addition to renovating BC Women's Hospital + Health Centre to serve both the current and future needs of children, youth, women and families throughout British Columbia.
Designed with patients, their families and care teams in mind, the redevelopment project's vision is for a campus of patient-centred care that operates in an environment of quality, excellence and innovation. The renovations and new facilities will also assist in attracting and retaining health professionals, clinical staff and researchers.


text:
Luxury Bed and Breakfast that extends across four floors of a sumptuously renovated Grade A listed Georgian Townhouse in Edinburgh City Centre. Room 1 is the master suite.
This elegant Georgian Townhouse is located on Manor Place - Edinburgh's highly regarded West End, a conservation area and World Heritage Site.
The house retains many original features and has all the indulgence and modern comforts of the 21st century.
A delicious, home-made breakfast is served in our dining room and includes fresh and seasonal ingredients sourced, where possible, from local suppliers.
Manor Place is a wide leafy street with a superb open outlook to St Marys Cathedral and Cathedral Green.
Within a few minutes walk you will find an excellent array of specialist shops, cafes/bistros and restaurants. Charlotte Square and George Street are only 5 minutes on foot, and Haymarket Train Station is a short 2 minute stroll away.
Price example:
Family of 4 (with 2 young children) for 2 nights at weekend (Friday and Saturday) = £280
No Hen or Stag parties please.
The bed is king size and complemented by luxury linen, duvets, pillows and mattresses to guarantee a great night sleep.
Each bedroom has a large, modern en-suite bathroom with high quality contemporary fittings.
Luxurious towels and a selection of Scottish and French toiletries are provided.
The room has wi-fi and is equipped with a Freeview HD television, a hairdryer, a shaving point and coffee and tea facilities.
Alternative rooms:
Room 2 Sleeps 2 Adults + 2 Children From £110 per night including Scottish Breakfast.
Room 3 Sleeps 2 Adults From £90 per night including Scottish Breakfast.
Occupancy 2-4 adults.
Room One is the largest and most luxurious suite where original features have been carefully restored, offset by a mix of old and contemporary furnishings.
The sitting room commands spectacular views over St Marys Cathedral through three floor-to-ceiling windows. Double doors lead to the bedroom with a king size four poster bed and a luxury free standing bath. The large, en-suite bathroom has a walk- in high pressure shower and under-floor heating, complemented by luxury linens, towels and bathrobes from The White Company. There is a sofa-bed in the sitting room to accommodate two extra people in real comfort, if required.
This is an ideal suite for a romantic weekend break, a honeymoon or a mid-week get away.
Prices start from just £120. (based on 2 Adults inc Breakfast)
To get a quote / book a room simply click the enquire button below and complete the form. The owner will reply directly to you with availability and a price for your stay... Paying the booking fee online will confirm your booking with the Owner however an additional security deposit will be required prior to or upon arrival.
A deposit of 25% of the total booking amount will be payable and this will be set against payment on departure.
Cancellations must be made by either phone or by email at least 72 hours prior to 15.00 on your planned date of arrival.
Cancellations within 72 hours of 15.00 on your planned date of arrival will be charged at 50% of the total booking amount.
There are currently no reviews available.
No.1 Choice for Luxury Edinburgh Holiday apartments.…
More information »© 2014 innerCityLets | Est. 2004
Compare up to 4 properties side-by-side
Select property to compare
Select property to compare
Select property to compare
Select property to compare
Add up to 8 properties to your basket for quick multiple enquiries.


text:
You know.....just fyi.
Tuesday, May 18, 2010
7 comments:
- Anonymous said...
you went full retard
heil, homo! - May 18, 2010 at 2:30 PM
- Kim said...
Why are the people in the background not in costume?
- May 18, 2010 at 3:08 PM
- http://questforburgers.blogspot.com said...
Great picture and thanks for adding Quest for Burgers to your blogroll!
- May 18, 2010 at 3:35 PM
- SmokeHopper said...
Kim, those poeple just "didn't have what it takes".
- May 18, 2010 at 3:59 PM
- Scarlett said...
A fellow Fort Worthian and Horned Frog here. The hubs and I received a smoker as a gift recently, and will be tearing up your archives looking for ideas/inspiration!
Smoke on! - May 18, 2010 at 5:21 PM
- Anonymous said...
This blog is weird.
- May 19, 2010 at 9:12 AM
- Anonymous said...
When does the Hitler 'stache become the Jordan 'stache? Is it the invasion of a neighbor that makes an icon, iconic? If Jordan killed Pippen in a border dispute, would the mustache cease to be Hitler's?
- June 4, 2010 at 3:43 PM
Subscribe to:
Post Comments (Atom)


text:
Ninth Judicial Circuit Court FRIEND OF THE COURT HANDBOOK - MAKING PAYMENTS
Two addresses for Payments
Payments are to be made through MISDU with a payment coupon unless the support order states otherwise. If you do not have a coupon (you should be receiving them every month in the first week), you should contact your local FOC office and request the coupon information so that your payment will be properly applied. Personal payer's must mail their checks to MiSDU, PO Box 30351, Lansing, MI 48909-7851. Employer's should mail payroll deductions to MiSDU at PO Box 30350, Lansing, MI 48929-7850.
Cash payments or a cashier's check made payable to the Friend of the Court may be delivered in person at the Cashier's window at the Friend of the Court office.
Support Payment Processing - by MiSDU
Child Support payment processing is computerized, and support payments are processed as soon as possible. After your payment is received in Lansing, it is posted to your account. Support checks are usually printed and mailed to the recipient of support the next working day. If the recipient is receiving public assistance benefits, the support amount is sent to the DHS as required by law.
Holding and Returning Checks - by MiSDU
If a check is returned because there is not enough money in a payer's account to cover it (non-sufficient funds), a "bad check hold" is placed on the child support account and no further disbursement checks will be issued until the check is redeemed. If a payer has more than one check returned for non-sufficient funds, the state may require that future payments be made by cashier's check or cash.
Payments received on an account which does not have a support order entered on the computer in MiCSES must be held and cannot be disbursed until an order has been received. As soon as the order is received by the FOC, and your case information is entered these will be applied to your case/docket and disbursements to the recipient will begin.
______________________ Facebook RSS Commissioners/Boards | Services/Programs | Departments/Courts Directories | Employment | Community Calendars | About Us | Email Us | Links County Home Copyright and Disclaimer 1995 - 2015, County of Kalamazoo©


text:
International -- Int'l Business: BRITAIN
THE URGE TO MERGE--AND BEAT THE CLOCK (int'l edition)
British execs fear a Labor government would block many deals
Rarely have London's investment bankers been so busy. On Feb. 15, Granada Group--fresh from its $5.7 billion takeover of hotel-chain Forte--upped its stake in Yorkshire-Tyne Tees Television to just under 25%, in a step toward a possible takeover. Next day, drug distributor Unichem raised its offer to buy Lloyd's Chemists to $950 million, countering an $899 million bid from Germany's GEHE. And Rentokil Group, an environmental-services outfit, began a $2.9 billion hostile takeover for rival BET. Soon after, National Westminster Bank snapped up fund manager Gartmore for $726 million.
The frenetic dealmaking comes right after a record-breaking 1995, when British companies participated in almost 1,700 acquisitions worth $104 billion. "Don't assume it will go on forever," warns John Dear, head of corporate finance at Lazard Brothers & Co. in London. True, but several factors, from politics to deregulation, will keep the merger movement hot for much of the year. And when it's over, British industries from media to utilities will look dramatically different.
One reason the merger rush will continue is the good chance of an early election and a Labor victory. Labor's Prime Minister-in-waiting, Tony Blair, has proposed a change in the public-interest criterion for takeovers. To block a deal now, target companies must show that the takeover actively hurts the public interest--a tough charge to prove. Blair wants the burden shifted so that the acquiring company must prove the public benefits of the takeover. This shift could spell the end of hostile bids in Britain.
Hence, many companies want to snap up rivals fast, especially in politically sensitive industries. After the government released its controlling shares in utilities last March, opening the way for takeovers, a frenzy ensued. Already, 8 of Britain's 12 regional electricity companies have been involved in takeover bids worth a combined $22 billion.
GREEN LIGHTS. Other government moves are shaking up the media. A new broadcasting bill, expected to be enacted midyear, will lift some restraints on cross ownership and the number of broadcast licenses any one company can hold. Some companies are already finding ways to do deals. Granada Group PLC, with interests in hotels and broadcasting, paid $80 million for a higher stake in Yorkshire Television. MAI recently agreed to a $4.6 billion merger with United News & Media. The Labor Party is not opposed to such concentration, but it wants to create a superagency with a lot of clout to root out anticompetitive practices.
Economic fundamentals are also fueling the boom. Kevin Gardiner, an economist at Morgan Stanley & Co. in London, predicts this will be Britain's most profitable business cycle since the 1960s. Balance sheets are brimming with cash, banks are eager to lend, and interest rates remain low. In industries such as pharmaceuticals that must cut costs, it can make sense to buy companies with hot new products rather than sink more funds into research that could take years to bear fruit. That explains Glaxo Holdings PLC's $14 billion takeover of Wellcome PLC last year. Zeneca Group PLC, with its rich pipeline of cancer and other drugs, could go into play next.
While British companies go their merry way, the threat of European intervention increases. The European Commission wants to expand its power to review bids involving large corporations. "For the big companies, that's more of a worry than the possibility of a Labor government," says Christiian Marriott, deputy editor of Acquisitions Monthly. It's just another reason for British chief executives to keep their acquisition specialists busy.BY JULIA FLYNN, WITH HEIDI DAWLEY, IN LONDONReturn to top
Britain's Takeover Boom
Major Acquisitions in The Past Year
WELLCOME: Maker of AIDS drugs was acquired by Glaxo. Price: $14 billion.
TSB GROUP: Lloyds Bank landed this financial services firm. Price: $9.4 billion.
FORTE: After a fight, hotel group succumbed to Granada. Price: $5.7 billion.
EASTERN GROUP: Utility was bought by Hanson. Price: $3.7 billion.
Return to top


text:
Victims were crossing GST Road to Govt. Hospital of Thoracic Medicine when vehicle jumped signal
A 35-year-old woman and her 8-year-old son died at Tambaram Sanatorium on Tuesday morning after they were hit by a speeding vehicle.
For more details, see infographic at left.
According to the police, the victims — B. Alamelu of Kunnam, Perambalur district, and her son Veeramani — were crossing the road to Government Hospital of Thoracic Medicine on Grand Southern Trunk Road when the accident occurred.
Alamelu was bringing her son for treatment at the hospital for his incessant coughing. Her uncle Marudamuthu (63) had accompanied them to Chennai. After reaching Koyambedu on Monday night the three of them had stayed with Alamelu's husband, Babu who works as a supplier in a roadside eatery.
On Tuesday, the three of them took a MTC bus from Koyambedu and got down at the bus stop opposite the hospital around 7 a.m. They were crossing the road when the signal for pedestrians was on, when a Tata Sumo vehicle, whose driver had jumped the signal, hit Alamelu and Veeramani. While the latter died on the spot, his mother succumbed to her injuries on the way to the accident trauma care at Tambaram Taluk Government Hospital in Chromepet.
Marudhamuthu escaped unhurt as he had darted across the road and was not hit by the vehicle. "It all happened within minutes. There were several vehicles waiting for the green light, but the Tata Sumo did not even slow down near the signal and hit the woman and her son," said P. Selvaraj, an eye-witness who works in a tea stall near the accident spot.
Chromepet Traffic Police (Investigation) arrested the vehicle driver, P. Kannan (22) of Red Hills who is an employee of a private travel agency. He had dropped a group of employees working in a private company inside Madras Export Processing Zone–Special Economic Zone at Kodungaiyur and was returning to pick up another batch of employees.
A case under section 304 (ii) of IPC (culpable homicide not amounting to murder) has been registered.
People working in restaurants and other shops around the signal opposite the hospital said many motorists paid little heed to road safety and hardly stopped for the signal. The spot had, in recent times, become accident prone, they said.
At the accident spot, the four-lane road, with a service lane and pavement on either side, has a total width of more than 150 feet.
Patients visiting the hospital, especially the elderly, who get down at the bus stop on the side of the road towards Tambaram direction found it difficult to cross at the spot, pointed out P. Elangovan, a resident of Tambaram Sanatorium.
Keywords: Chennai MUV accident, Chromepet Traffic Police


text:
Eater/Eau, Cyclomethicone, Dimethiconol, Propylene Glycol, Cyclopentasiloxane, Cyclohexasiloxane, Phenyl Trimethicone, Polycrylamide, C13-14 Isoparaffin, Laureth-7, Methacryloyl Ethyl Betaine/Acrylates Copolymer, Cellulose Gum, Methyl Gluceth-10, Polysorbate 20, Methylparaben, Fragrance/Parfum, Amyl Cinnamal, Butylphenyl Methylpropional, Citronellol, Limoene, Linalool, Hydrolyzed Wheat Protein, Hydrolyzed Soy Protein, Aloe Barbadensis Leaf Juice, Prunus Domestica Fruit Extract, Vaccinium Macrocarpon (Cranberry) Fruit Extract, Juglans Regia (Walnut) Shell Extract, Camellia Sinesis Leaf Extract, Vittis Vinifera (Grape) Seed Extract, Methylchloroisothiazolinone, Methylisothiazolinone, Retinyl Palmitate, Tocopheryl Acetate, Ascorbic AcidOverview
Sexy Hair Straight Sexy Darn Straight Lotion straightens and conditions hair without adding weight. Gives a polished look while nourishing hair with vitamins and antioxidants.
- Conditions and straightens
- Protects against heat styling damage
- Does not add weight to hair
- Resists humidity to keep hair straight all day
Apply to damp hair from roots to ends then blow dry for beautiful, straight, shiny hair.


text:
The photo below shows my brother Frankie (left) and me. Frankie died because of what a priest and nuns did to him and to me. I write this blog because I want to protect you and your families from these crimes committed by the catholic church. I want to give survivors of clergy abuse a voice so they can be heard all over the world. We can add our voices to a growing, worldwide community of people who want truth and justice. Please share your experiences with me and others on this blog.
Monday, March 31, 2014
The Italian Bishops' Conference, with the Pope's blessing has once again embraced the policy that states they are not obliged to inform police officers if they suspect a child has been molested. If I, you, or anyone with humanity knew of a child rapist running loose we would report them to the police and they would be locked up. Are priests above the law? For the past 2,000 years they have been above the law or they were the law – isn't it time to stop them?
David Clohessy of St. Louis, Director of SNAP, the Survivors Network of those Abused by Priests said, "With the blessing of the Vatican, Italy's bishops have formally declared they have no duty to call police if they suspect that a child is being sodomized or raped. The stunning, depressing and irresponsible contradiction between what Vatican officials say about abuse and do about abuse continues. And the tragic consequences for kids continue too. This policy – which codifies the long-standing and heartless practice of most Catholic bishops on the plan – will mean that more innocent children will be sexually assaulted."
The Italian Bishops' Conference said the policy reflected suggestions from the Vatican's office that handles sex abuse investigations. Any "suggestion" coming out of the Vatican has the Pope's stamp of approval. So less than a week after Pope Francis appointed a new commission to help the Catholic Church put an end to clerical sexual abuse and a few weeks after the United Nation's report blasted what it called the Vatican's code of silence" around abusive priests – the church is right back to its old criminal tricks.
After the UN report what did Pope Francis announce to the news media about his policy on clerical child rape? He said: "The Catholic Church is perhaps the only public institution to have acted with transparency and responsibility. No-one else has done more. Yet the Church is the only one to have been attacked." Is he in touch with reality – or is the reality that he approves of child abuse?
UN children's rights experts say that "tens of thousands of children worldwide" have been sexually abused by predatory clerics as a result of moving, rather than reporting, clergy child rapists and blasted what it called the Vatican's "code of silence" around abusive priests. How many more international organizations, child advocates, parents and survivors – how many crying children with destroyed lives have to tell the Pope and his minions who hide behind God to STOP HURTING THE CHILDREN!
So the next time you see Pope Francis smiling at the camera and saying what wonderful changes he is making in church policy -- know that he is lying when it comes to stopping the evil that touches millions of innocent children.
15 comments:
- AnonymousMarch 31, 2014 at 10:49 PM
The Catholic Church has always been about lying to the membership! ----- Criminals are running the Catholic Church, so why wouldn't they protect the criminals that are abusing children. (If it walks like a duck, and quacks like a duck, chances are it is a duck!) ---- The Catholic Church will NEVER turn over the Clergy to the civilian authorities, because the abuse goes throughout the Catholic Clergy from the bottom to the top! It is the "good old boy network!" Everyone is covering their own ass! I cannot believe that the average member of the Catholic Church cannot see through this "smoke screen" that is being put out by the Pope. ---- Children have been, and will continue to be abused by Catholic Priests, Brothers and Nuns as long as the members of the Catholic Church keep supporting the Church with their weekly donations. If they cut off their money supply, the leadership of the Church will start to clean their own house. They will throw these criminal clergy to the lions! ------ Just my opinion. ----- God bless!
ReplyDelete - AnonymousApril 1, 2014 at 4:18 PM
Our own Government; gives $2.9 Billion Dollars to the Vatican" according to President Obama ; the Vatican is suppose to help the poor;" I sent an email to President Obama & an email to Vice President Biden" asking have they checked the Vatican's books to see if the $2.9Bl. is going to the poor" or is it going to the lawsuits; I haven't received a response back yet ? I have also contacted Beau Biden in Delaware, he sentenced a Doctor to life in prison; for raping children. Here's what I don't get" just about every Parish in the State of Delaware Priest and Nun's have abused children " & Beau Biden knows this and he is a Catholic. In my email to him, as a victim; I believe that the Child Molester" ( rapist ) found a loophole in the religious system. I contacted Beau Biden's office because I wanted to have The Priest arrested " but the Statue Of Limitation " is protecting the Priest" and also Mnsgr. Cini in Delaware......I also asked President/ Biden in my email , what is the difference between , War Crimes & The Catholic Church Abuse on Children ?
ReplyDeleteReplies- AnonymousApril 2, 2014 at 12:31 PM
The Catholic Church is VERY well connected with the governments throughout the world. Many of the leaders in government are members of the Catholic Church, so as such, there is a BIG conflict of interest. ---- Everyone at that level is in bed with one another. ---- The average person is not even considered. We are all here to serve the religious and political machine, and we are expected to do so without question. It would not surprise me that the church would try to silence those of use who are complaining about child abuse with "excommunication!" ---- Now that is a BIG empty threat. ---- Ask yourself this question, why would anyone in their right mind, who is capable of thinking and reasoning want to be a member of a Church that routinely abuses children, and then hides the criminals in their ranks. ----- By it's own behavior, the Catholic Church has defined itself as the "Church of the Devil!" I have not been to confession since 1968, and I am proud of that fact. I would NEVER discuss my private life with the Criminals of the Catholic Church. Since I have stopped attending Catholic Church Mass my life has gone from extremely negative to positive. Rather than attending Catholic Services on Saturday or Sunday I listen to Joel Osteen on Sunday morning on TV. He presents Christianity in a positive fashion, and he discusses the possibilities of life. On the other hand, the Catholic Church always talks about how much of sinner you are, and the need for more money. ----- The Catholic Church does NOT represent the Christian Religion. It is a self-serving Christian Cult who only wants to keep the organization solvent in terms of financial obligations. They could care less about you and I. We are expendable and we are to be used for the greater good. We are just the financial foot soldiers. Just keep the money coming, and the Catholic Church will guarantee you salvation. The truth is that the Catholic Church cannot save itself. The Catholic Church is like the Titanic. It is going down. It is just a matter of time. If you want the Catholic Church to take responsibility for their past actions cut off the weekly donations. Get the attention of the Priests, Pastors. Bishops, Cardinals and the Pope. Make them accountable to the people. If they choose not to be accountable, find a bible based church and go on with your life. The clergy of the Catholic Church is NOT to be trusted with you soul and with your children. They are very negative / manipulative / deceitful / money hungry people who always have hidden agendas when dealing with people. They speak in "half-truths" in order to get their way, and to secure the financial contributions. They believe that the only law that applies to them is church law. That is why the Catholic Church will never turn over their criminal nuns and priests. We all deserve justice! ---- Just my opinion. ----- God bless!
- AnonymousApril 2, 2014 at 4:51 AM
They will never stop. I don't know why, but raping children is the main mission of the catholic cult. It seems to me that their goals of imperialistic growth and accumulation of wealth are simply designed to support their quest to rape and psychologically abuse children. It is the most corrupt and evil institution in the history of the world. Judge it by its actual actions, not the bullshit PR and propaganda it produces. Judge it by the hundreds of years of systematic abuse and the obvious intention to continue and spread that abuse and culture. I am shocked and disgusted that their lemmings support them financially and politically. I am shocked and disgusted that others don't seem to be outraged by these disgusting cretins.
ReplyDeleteReplies- AnonymousApril 2, 2014 at 12:11 PM
I know that Snapnetwork, also Blogs like this" are doing everything they can to help expose the Priest & Nun's " yes we must continue on ;" but we (The Victims) have to get out there in the hundreds, in Washinghton; so our faces can be seen & our voices heard, if we don't get out there in the public eye" then it will continue to go on and on...........also our Government & the Catholic Church will just continue on with their business just like nothing ever happened; ask yourself " how many decades old is the abuse and for decades the Catholic Church has gotten away with, raping, torturing, abusing children;" and then ask yourself "how many hundreds of victims have marched in Washington all at one time ? I myself have never seen it or heard about anything like this on the TV News .............if it was on the TV News" then it was silenced very quickly" as usual " isn't that the norm" with the Vatican or the TV News" to silence the VICTIMS again" just to be pushed back into the closet ! !
Delete - AnonymousApril 2, 2014 at 12:51 PM
Over the years, the Catholic Church has administered the "Catholic Cool Aid" to both the children in Catholic Schools and to the Adults. They have a large segment of the "Catholic Faithful" brainwashed into thinking that only the Catholic Church can save their soul. The question becomes is "How can a Church that is in league with the Devil save anyone's soul? That would be equivalent to placing a Fox in the "hen house" to guard the chickens. People need to open their eyes, and think for themselves! The Catholic Church is like a cancer. It is destroying people's lives. Children have been abused in the past, and now that they are adults they are living with Post Traumatic Stress Disorder, and the Catholic Church does NOT care. They ignore the problem, except for paying "hush money" to protect their own ass! Where is the just for the individual? ---- Just my opinion. ---- God bless.
Delete Yes, raping children is the main mission of the catholic cult -- said simply and concisely. I agree that everything else they do supports this mission and it will continue unless the faithful realize the evil they are following. Do you think we can educate them? That is what the mission of this site is and all the great comments like this one make that mission likely to succeed.
- AnonymousApril 2, 2014 at 10:35 AM
The true colors of the Roman Coward Church are finally exposed; yellow on yellow.
Mike FerenceReplies- AnonymousApril 2, 2014 at 1:07 PM
There are two reasons why the Catholic Church will fail and they are ignorance and arrogance. The ignorance comes into play, because they really do not see the damage that they have done to human beings over the years. They really believe that they are doing God's Work, because they have a distorted view of God and Christianity. --- The arrogance comes into play because they believe that they are above the criminal law, and they have friends in high government places to protect them from attack. A plan of action might be for all the abused people join in on a massive international class action law suit, not for just financial gain, but to force them to sell their real estate holdings thus bankrupting the Catholic Church forever. Attack their holdings and you control the church. ---- Just my opinion. ----- God bless.
Delete Mike, that is one of the best names I've heard for the catholic church! They should change their robes to yellow.
- AnonymousApril 2, 2014 at 4:03 PM
Since our Government is giving $ 2.9 billion dollars to The Vatican" that money comes from the taxpayers here in the United States" Why can't all of the victims get together " and do like you said" a massive international class action law suit.......also" this money from the United States" this is our tax money; so why can't we have the Pope arrested, for covering and protecting rapist ( Priest & Nuns ) what these Priest and Nuns have done to us " isn't this considered war crimes ?
ReplyDeleteRepliesAn international class action law suit is a great idea but one that requires a lot of backing. SNAP tried to interest the International Criminal Court in such a law suit but even with 22,000 pages of evidence the Court did not think it was a case for them. So SNAP took the evidence and went to the United Nations with it. The UN was interested and used the evidence to develop its report on the rights of the child and to expose what the catholic church was doing to children. So good things are happening. Other people like Kevin Annett who fights for the rights of abused, tortured and murdered Native American also influence world organizations. All of us on this site and on other blogs are visible to the media and we are helping to bring the evil church down. It takes people and organizations - all of us. We have to vote, stop supporting churches fiancially, demonstrate, blog, make youtube videos and keep the pressure on them. They are disgraced, more and more people are leaving the church and even churches want to break lose from the vatican. We are succeeding!
Delete- AnonymousSeptember 12, 2014 at 10:01 AM
The Catholic Church has always been a "negative force in my life!" I spent 12 "horrible years in Catholic School" in the late 40's & 50's both in New York and New Jersey, and I cannot remember ever feeling good about the way I was treated, or the quality of the education. The Catholic Church used their schools to "indoctrinate the young person" into the Catholic Cult Religion. I say "Cult" because the Christian Religion is a religion of love and peace, but the Catholic Church has changed it into a total negative cult experience. There was no "positive / personal self-esteem" in my classes in Catholic School. Questioning was not allowed. "Blind obedience" was the order of the day, and the quality of the academic education was VERY poor. The Nuns did not want the individual student to discover their inner greatness, and use their talents, skills and abilities to build a successful / positive life for themselves. Rather, all they wanted was to create robotic / loyal / cool-aid drinking followers who would blindly obey the orders issued by the Catholic Clergy. The Catholic Church is the biggest joke in the Christian World! The Catholic Clergy will tell the "faithful" to "give money to the church while depriving themselves and their family in the process," but they have no problem using that money to pay "hush money" to cover up their sexual crimes against children. They close their schools because they claim that they do not have the money, but they have enough money for their sexual activities. If Catholics in the United States want justice for their children they have to cut off the money supply to the church. QUESTIONS: When has the Catholic Clergy done a decent days work? They live off the faithful like parasites. ---- Have you ever tried to get a priest during the week? They are never available! ----- QUESTION: What are they doing? ---- ANSWER: ---- Having sex with children! ---- God bless everyone! ---- Stay far away from the Catholic Church for your own mental health and the health of your children. The Clergy are not to be trusted! ---- Have a GREAT day!


text:
70s -Dalani- Womens white and shades of brown slinky polyester longsleeve mid length disco dress. An abstract feathery print, with a flared skirt, button cuffs, fitted waist, fold over collar, ruched shoulders, a V-neckline, button front half placket and attached back ties.
Sorry, this item has SOLD. View other Womens Dresses - Disco
35Bust 28Waist 37Hip
Very Good Condition
Approx Shipping Weight 1.5 lbs.
Item No. 255125


text:
A Rostovian model of endogenous growth and underdevelopment traps
Zilibotti, Fabrizio (1995) A Rostovian model of endogenous growth and underdevelopment traps. European Economic Review, 39, (8), 1569-1602. (doi:10.1016/0014-2921(94)00027-W).
Full text not available from this repository.
The paper presents a model which combines self-sustained growth and ''underdevelopment traps' into a common analytical framework. We provide an analytical interpretations to Rostow's observation that there is 'a decisive interval in the history of a society when growth becomes its normal condition'' and to the empirical evidence that some countries seem not to have achieved this stage yet. The model exhibits aggregate non-convexities and thresholds which separate a region where growth is 'Solow-type', with convergence to a stationary steady-state from a region where growth is 'Romer-type', with endogenous self-sustained growth. In some critical stages of development there exist multiple equilibrium trajectories, consistent with alternative sets of self-fulfilling beliefs.
Item Type: | Article |
ISSNs: | 0014-2921 (print) |
Related URLs: | |
Keywords: | underdevelopment traps, thresholds, externalities, technical progress |
Subjects: | H Social Sciences > HB Economic Theory |
Divisions: | University Structure - Pre August 2011 > School of Social Sciences > Economics |
ePrint ID: | 33090 |
Date Deposited: | 13 Dec 2007 |
Last Modified: | 27 Mar 2014 18:20 |
URI: | http://eprints.soton.ac.uk/id/eprint/33090 |
Actions (login required)
View Item |


text:
We don't yet have a wiki for The Rise & Fall of Australian Rugby: The Bledisloe Cup - Deluxe Edition, but if you would like to start one you can do it here.
To create a wiki or add content to one you need to be logged in. You can log in above or click the 'SIGN UP' link to sign up now for free.
Then please return to this page to start sharing what you know about this game.