One document matched: draft-kuptsov-sava-hip-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5202 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5202.xml">
<!ENTITY RFC5203 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5203.xml">
<!ENTITY RFC5204 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5204.xml">
<!ENTITY RFC5205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5205.xml">
<!ENTITY RFC5206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5206.xml">
<!ENTITY RFC4423 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4423.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC4727 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4727.xml">
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC5203 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5203.xml">
<!ENTITY RFC5210 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5210.xml">
<!ENTITY I-D.lindqvist-hip-opportunistic SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-lindqvist-hip-opportunistic-01.xml">
<!ENTITY I-D.ietf-hip-opportunistic SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-lindqvist-hip-opportunistic-01.xml">
<!ENTITY I-D.bi-savi-csa SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bi-savi-csa-00.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-kuptsov-sava-hip-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="SAVAH">SAVAH: Source address validation architecture with Host Identity Protocol</title>
<author fullname="Dmitriy Kuptsov" initials="D.K."
surname="Kuptsov">
<organization>Helsinki Institute for Information Technology</organization>
<address>
<postal>
<street>PO. Box 9800</street>
<city>TKK</city>
<code>FI-02015</code>
<country>Finland</country>
</postal>
<phone>+358 50 301 2613</phone>
<email>dmitriy.kuptsov@hiit.fi</email>
</address>
</author>
<author fullname="Andrei Gurtov" initials="A.G."
surname="Gurtov">
<organization>Helsinki Institute for Information Technology</organization>
<address>
<postal>
<street>PO. Box 9800</street>
<city>TKK</city>
<code>FI-02015</code>
<country>Finland</country>
</postal>
<phone></phone>
<email>gurtov@hiit.fi</email>
</address>
</author>
<author fullname="Jun Bi" initials="J.B."
surname="Bi">
<organization>Tsinghua Univeristy</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email></email>
</address>
</author>
<date year="2009" />
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword></keyword>
<abstract>
<t>
This document describes an architecture for the source address
validation with help of Host Identity Protocol (HIP), SAVAH. The architecture
utilizes the properties of cryptographically strong protocol to
authenticate an originator of a network communication. In addition
this architecture offers network access control, data
protection, host mobilty and multihoming features and
is suitable for the wireless networks. The proposed, architecture
is the first-hop router solution, meaning that it should be deployed on the
router placed on the edge of a local network topology.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document specifies an extension to Host Identity Protocol (HIP)
<xref target="RFC4423">RFC 4423</xref> and its component (i.e.
HIP firewall) to perform per packet source address validation and
authentication. The extension provides means to authenticate the
traffic using properties of cryptographic algorithms. It is assumed
that this approach is to be implemented on the edge, or first-hop,
router of the local network.
The approach in this document should be easily integrated with
Source Address Validation Architecture (SAVA) specified
in <xref target="RFC5210">RFC5210</xref> and provide
an alternative for a <xref target="I-D.bi-savi-csa">
CGA based Source Address Authorization and Authentication (CSA)
Mechanism </xref>.
</t>
<t>
This document assumes that the solution is tailored to validate the source addresses
only of the nodes that belong to the same network. Traffic generated
from the hosts from outside network is not checked, validated or
authenticated, meaning that some other solutions are needed to be used
to achieve this goal.
</t>
<t>
To authenticate the traffic using HIP the following approaches can be used:
<list style="symbols">
<t>
First propose, when both communicating peers are HIP enabled. Then HIP
firewall (which is in fact should be deployed on the edge of the local
subnetwork) tracks base exchange signaling packets from of all hosts that
try to communicate with hosts outside the local subnetwork and only lets
through packets with valid HITs and IP addresses. Later data packets are
sent in ESP encapsulated packets so that the firewall can check SPI values
of the packets and drop those that does not match previously seen base
exchange. The shortcoming of this approach is requirement of universal
deployment of HIP.
</t>
<t>
Secondly, hosts that are inside the local subnetwork, including first-hop
router, assumed to support HIP with SAVAH extension. This document focuses
on a description of SAVAH extension.
</t>
<t>
Finally, HIP tunneling approach can be used. It is thought to be less efficient in
terms of performance, but can provide better security and mobility support to the wireless
clients. The client creates a tunnel between himself and the SAVAH router using HIP base
exchange and SAVAH extension. Later all traffic is forwarded through this tunnel to the
Internet.
</t>
</list>
</t>
</section>
<section anchor="Overview" title="SAVAH protocol overview">
<t>
This section describes the SAVAH extension. It illustrates
and explains the signaling and data packets, as well as it
discusses the source address validation mechanism.
<figure align="center" anchor="msq_squence">
<artwork align="left"><![CDATA[
Client DHCP Router Peer
| Request network | | |
| configuration | | |
|------------------>| | |
| Offer netwoork | | |
| configuration | | |
|<------------------| | |
+-----| | | |
|Get | | | |
|gate | | | |
|way | | |--------+ |
+---->| I1 | | Check | |
|--------------------------->| HIT | |
| | | in ACL | |
| | |<-------+ |
| R1 (REG_INFO) | |
|<---------------------------| |
| | | |
| | |--------+ |
| I2 (REG_REQUEST) | Check | |
|--------------------------->| HIT | |
| | | in ACL | |
| | |<-------+ |
| R2 (REG_RESPONSE) | |
|<---------------------------| |
| | | |
| | |--------+ |
| Plain IP(SAVAH opt) | Check | |
|--------------------------->| source | |
| | | IP | |
| | |<-------+ |
| | | Plain IP (no SAVAH opt) |
| | |----------------------------->|
| | | |
| | | |
| | | Plain IP (no SAVAH opt) |
|<----------------------------------------------------------|
| | | |
| | | |
]]></artwork>
</figure>
SAVAH is targeted to solve the source address validation problem in the
edge router of the local network, serving as a default gateway. Because of
that, SAVAH architecture is composed of two main components:
<list style="symbols">
<t>
SAVAH enabled client, which is a combination of a HIP daemon and a
firewall in a client mode supporting SAVAH extension
</t>
<t>
SAVAH enabled router running the HIP daemon and the firewall
but in server mode
</t>
</list>
DHCP server can be considered a third component in our architecture.
Its main role in the network is to offer particular configuration for
SAVAH aware hosts. For instance, DHCP can provide the default gateway IP address
as well as HIT of the SAVAH router. Availability and proper configuration of
DHCP server can help to solve the problem of opportunistic mode that is
being discussed later in this section. However, we consider DHCP as an
optional component in the network topology. SAVAH aware clients can be configured
manually, meaning that the IP address and the HIT of the SAVAH router can be setup by
a system administrator prior to any communication. However, manual configuration
can be a tedious task in a large scale network. As a third option, if non of the
advised is accessible in the local network, the SAVAH enabled client can try to
discover the SAVAH router using the opportunistic mode.
The message sequence diagram for SAVAH registration and further authentication
process is shown in Figure 1. As discussed previously it can involve three
entities in the local network to perform the source address validation: the
SAVAH client, the SAVAH router and the DHCP server (optionally). The receiver
on Figure 1 is playing the role of a legacy peer, i.e., it may or may not support
HIP. Of course, if both communicating peers support HIP protocol the whole scenario
requires only normal HIP-enabled firewall to filter the traffic based on HITs.
</t>
<section anchor="discovery" title="SAVAH router discovery and registration">
<t>
Successful passing of the address validation procedure on the first-hop
router requires a client to register. This is completed through HIP
registration extension <xref target="RFC5203">
RFC5203</xref>.
Since SAVAH router is the first-hop router, it should be placed
on the edge of the local network and serve as a default gateway. If the
default gateway and the SAVAH router are not placed physically on the same
node it becomes meaningless, because all network traffic flowing through
the SAVAH-unaware router would not contain SAVAH option and would be discarded.
If DHCP server does not offer a HIT of the SAVAH router during the address
assignment phase, then the SAVAH client is obliged to discover the presence
of the SAVAH service automatically. Otherwise, the client is aware of the HIT and
the IP address of the SAVAH router and can register to the service directly.
It is also possible to preconfigure the client and specify the IP address and HIT
of the default gateway.
Optionally, the presence of a SAVAH-unaware DHCP means that the client will obtain only
the IP address of the default gateway. No prior knowledge of
the SAVAH router's HIT forces the client to discover the service using the HIP
<xref target="I-D.lindqvist-hip-opportunistic">opportunistic mode
</xref> and a set of standardized procedures
for HIP service registration as described in <xref target="RFC5203">
RFC5203</xref>.The drawback of
such broadcasting is that in the opportunistic mode the client is unaware of
the HIT of SAVAH router and any node can thus pretend to be a valid router. This
reminds a similar problem with SSH, when connecting to an unknown hosts.
Hence, the opportunistic mode should be used only in a trusted environment.
To trigger a registration in opportunistic mode, the SAVAH client requests from the
system the default gateway IP address and sends an I1 packet with the destination HIT as a
hashed source IP address. On the other side, the default gateway running SAVAH in a server
mode responds with an R1 packet containing an offer for available services in REG_INFO
parameter. Upon receiving the R1 packet the client chooses the supported services and
responds with an I2 packet containing a REG_REQUEST parameter to SAVAH server.
If REG INFO parameter does not contain the SAVAH service offer, the client completes
base exchange normally and afterward falls to a normal communication, i.e. SAVAH mode
is not supported in this network. Finally, depending on the setup of
the SAVAH router, it either grants or denies the service to client in a R2 packet in a
REG_RESPONSE or REG_FAILED parameter correspondingly. Receiving REG_FAILED parameter
in an R2 message during the base exchange or experiencing a timeout in a I1 state
means that either the default gateway does not support SAVAH extension or
that HIP daemon with SAVAH extension is not running at all. This situation should
indicate to the SAVAH client to fallback to a normal communication, i.e., the
packets that would be forwarded through the default gateway will not
contain any authentic information. As an opposite result, if the SAVAH router
grants the service to the registering client, both parties will posses a
shared secret key.
</t>
</section>
<section anchor="validation" title="Source address validation">
<t>
For performance issues, the keys that are used
for authentication (i.e., HMAC keys) in IPSec
were selected to authenticate the source
addresses. Depending on a setup, symmetric
cryptography can be selected as well.
Filtering based on HITs can be done to ensure
that the peer trying to register to the SAVAH
service is legitimate. This filtering can
enforce to either grant or deny the SAVAH
service to the registrars. The grounds for such
a decision can be rules specified in the
HIP-enabled firewall. By default, all packets
with unknown identifier are dropped.
After completion of the HIP base exchange,
the SAVAH router adds the source IP address of
the host to a database. This works
if no record with such IP address
already present in the database. If a record
with such IP address already exists, it is
likely
that the host is trying to spoof someone else
address and the packet should be dropped nor
state is added. Moreover this incident can be
logged and reported for further analysis.
If the host experiences an address change, then
the record is replaced with a new IP address. To
ensure the validity of the host, HIP UPDATE
packet has to be received and handled properly.
This will guarantee that the host indeed who it
is claiming to be. The record should be removed
from the database upon a timeout or when the
host removes a security association (e.g., HIP
CLOSE packet is received from the corresponding
host). To ensure that the client is alive, SAVAH
router can also send heartbeats to the client,
without waiting for the timeout.
After the secret keys were established by means
of the HIP base exchange, the SAVAH client may
communicate with the nodes outside of the local
network by including an authenticated source IP
address in each packet. Current implementation
has two options to deliver the authenticated
hash value to the router. First approach is to
replace the original source IP address of each
packet with truncated result obtained from
HMAC(key | {P}) operation, where {P} is
the packet to be transmitted. We have chosen the
packet value as a feed to HMAC function to
introduce simple protect mechanism from replay
attacks.
This approach has some drawbacks. First
of all, for IPv4 networks the size of
authentication value will be only 32 bits.
Secondly, that would decrease the performance
since additional address translation would be
required on the router. Finally, that method
will require additional changes to the router to
recognize locally routed traffic.
A different way to carry the authenticated
source IP address to SAVAH router is to store it
in an IP option. Since the SAVAH router is the
first-hop router and all SAVAH related options
are striped out on the forward direction, this
ensures that no modifications are required for
other routers on the path. Placing the
authentication value in the IP option can have
certain advantages. First of all, this approach
slightly optimizes the performance of the
architecture. Secondly, stronger security
can be achieved by increasing the length of the
authentication value. We suggest to keep this
length within wise bounds, since it affects the
size of the actual payload.
To authenticate the packet source address, the
following algorithm is used. On the router side,
each packet in forward direction is searched
for the SAVAH IP option. If found, the router
compares the value of the option against
truncated 128-bit result from HMAC(key |
{P}) operation, where {P} is the packet
to be forwarded. If matches, the SAVAH option is
striped out and the packet is re-injected to the
network. If not, the pinhole is searched for a
given source and destination IP addresses. If
the pinhole is found, the packet is said to be
an
inbound packet for previously authenticated
outbound communication. Finally, if both are
failed the packet is dropped.
If the tunneling approach is used, then the
authentication succeeds if the SAVAH router can
successfully decrypt the ESP packet and resend
encapsulated in ESP original packet to its final
destination. Unlike the lightweight approach for
inbound traffic, the SAVAH router in a tunnel
mode should properly encrypt and tunnel the
packet to the corresponding mobile node.
</t>
</section>
<section anchor="tunneling" title="SAVAH tunneling mode">
<t>
This section describes how SAVAH operates in tunneling mode. The major
difference from the lightweight SAVHA mode (<xref target="Overview">
SAVAH protocol overview section</xref>) is that all traffic leaving the
local host is encapsulated in ESP packets and forwarded to SAVAH router.
<figure align="center" anchor="msq_squence_tunnel">
<artwork align="left"><![CDATA[
Client DHCP Router Peer
| Request network | | |
| configuration | | |
|------------------>| | |
| Offer netwoork | | |
| configuration | | |
|<------------------| | |
+-----| | | |
|Get | | | |
|gate | | | |
|way | | |---------+ |
+---->| I1 | | Check | |
|----------------------------->| HIT | |
| | | in ACL | |
| | |<--------+ |
| R1 (REG_INFO) | |
|<-----------------------------| |
| | | |
| | |--------+ |
| I2 (REG_REQUEST) | Check | |
|----------------------------->| HIT | |
| | | in ACL | |
| | |<-------+ |
| R2 (REG_RESPONSE) | |
|<-----------------------------| |
| | | |
| | |--------+ |
| ESP tunneld IP traffic | Check | |
|----------------------------->| source | |
| | | IP | |
| | | Decrypt| |
| | | ESP | |
| | |<-------+ |
| | | |
| | | |
| | | Plain IP (non encypted) |
| | |----------------------------->|
| | | |
| | | |
| | | Plain IP (non encrypted) |
| | |<-----------------------------|
| | | |
| | +--------+ |
| | |Check | |
| | |pinhole | |
| | |Encrypt | |
| | |traffic | |
| | +------->| |
| | | |
| ESP tunneled IP traffic | |
|<-----------------------------| |
| | | |
]]></artwork>
</figure>
The registration and source address validation mechanisms are the same
as in lightweight SAVAH mode.
</t>
<t>
Once the encrypted packet arrives on the SAVAH router it decrypts
the packet validates the source IP address and forwards the encapsulated
original packet to the destination host.
</t>
<t>
Upon the arrival of the packet from the Internet on the SAVAH router, its
task to check if the pinhole exists. If there was previous communication
the SAVAH router encrypts the packet (in similar way it is done on the
SAVAH client) and forwards ESP encapsulated packet to the corresponding SAVAH
client.
</t>
</section>
</section>
<section anchor="pkt_format" title="Packet format">
<t>
This section describes the format of the IP options that are
used to carry authentication data.
</t>
<t>
For IPv4 protocol the format of SAVAH option is as follows:
<figure align="center" anchor="ipv4_pkt">
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option type | Option Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Encrypted source IP address |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list style="symbols">
<t>
Option Type (value 158) is the field that describes SAVAH option,
and concatenation of the following bit values:
<list style="symbols">
<t>
First highest bit is 1 indicating to copy this option
to every packet
</t>
<t>
Next 2 bits (Option Class) is 00 meaning that this is
control option
</t>
<t>
The last 5 bits are 11110 which signal the experimental purpose of the option
as assigned in <xref target="RFC4727">RFC 4727</xref>
</t>
</list>
</t>
<t>
Encrypted source IP address is the truncated 128 bit length result
from operation HMAC(key|IP address), where key is the pre-shared
secret key, and IP address is the source address of the packet
</t>
<t>
Padding is zero fill up to the multiplicative of 32 <xref target="RFC0791">
RFC 791</xref>
</t>
</list>
</t>
<t>
For IPv6 protocol the format of SAVAH option is as follows:
<figure align="center" anchor="ipv6_pkt">
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Option type | Option Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Encrypted source IP address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Type | Padding Len | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list style="symbols">
<t>
Next Header field is selected to be Destination Option
as described in <xref target="RFC2460">RFC 2460</xref>
</t>
<t>
Hdr Ext Len is the length of option 8-octet units, not
including the first 8 octets. For SAVAH this is equal to
2
</t>
<t>
Option Type is the field that describes the actual data
in the option, for Destination Option there can be multiple
such TVL encoded fields. Here the Option type is encoded as
follows:
<list style="symbols">
<t>
Highest 2 bits are 00 indicating to skip the option if
it is not recognized by the router
</t>
<t>
Next bit is 0 meaning Option Data does not change en-route
</t>
<t>
The last 5 bits are 11110 as assigned in <xref target="RFC4727">
RFC 4727</xref> for experiments
</t>
</list>
</t>
<t>
Encrypted source IP address is the truncated 128 bit length result
from operation HMAC(key|IP address), where key is the pre-shared
secret key, and IP address is the source address of the packet
</t>
<t>
Padding is of type PadN as described in <xref target="RFC2460">RFC 2460</xref>
</t>
<t>
Padding Len is the length of actual padding excluding first 2 octets,
and in SAVAH case equal to 2
</t>
<t>
Padding is the 2 zero filled octets
</t>
</list>
</t>
<t>
IPv4/IPv6 packet structure for SAVAH in tunnel mode:
<figure align="center" anchor="befor_esp">
<artwork align="left"><![CDATA[
BEFORE APPLYING ESP
-----------------------------
| Outer IP hdr | Payload |
| | |
-----------------------------
]]></artwork>
</figure>
<list style="symbols">
<t>
Outer IP hdr is the IPv4 or IPv6 header containing the source IP address
of the local host and the destination of the host in the Internet, or host
in the local sub-network.
</t>
<t>
Payload is the data containing the upper layer protocol PDU (such as TCP, UDP,
SCTP, etc.) and the user payload.
</t>
</list>
<figure align="center" anchor="after_esp">
<artwork align="left"><![CDATA[
AFTER APPLYING ESP
------------------------------------------------------------------
| SAVAH IP hdr | | | | ESP | ESP |
| (any options) | ESP | Outer IP Hdr | Payload | Trailer | ICV |
------------------------------------------------------------------
|<----- encryption ----->|
|<--------- integrity -------->|
]]></artwork>
</figure>
<list style="symbols">
<t>
Gateway IP hdr is the IPv4 or IPv6 header containing the source IP address of
the local host and the destination IP address of the SAVAH router in given local
sub-network.
</t>
<t>
ESP is the Encapsulated Security Payload in BEET mode.
</t>
<t>
Outer IP header is the IPv4 or IPv6 header containing the source address of the
localhost and the destination address of the host in the Internet, or of the host
in the local sub-network. It is different from ESP BEET mode Outer address, and more
reflects the meaning of the Outer IP address of the ESP tunnel mode.
</t>
</list>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Using opportunistic mode in HIP should be considered as a security risk
in untrusted environment, due to the fact that the router's HIT is not
known before the registration. This gives a possibility to an attacker
to hijack the HIP I1 packet and pretend to be a SAVAH router by sending
the R1 packet to the client.
</t>
<t>
Using tunneling approach a single SAVAH router may become a single
point of failure as well as a bottleneck in the network communication.
For that reason it is recommended to use load balancing between multiple
SAVAH router and forward the traffic from the client to the Internet through
several (depending on the network size) SAVAH routers.
</t>
</section>
<section anchor="Credits" title="Credits">
<t>
The following people have provided thoughtful
and helpful discussions and/or suggestions that have helped to improve
this document:
<list style="symbols">
<t>Miika Komu</t>
</list>
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC4423;
&RFC2460;
&RFC4727;
&RFC0791;
&RFC5203;
&RFC5210;
&I-D.lindqvist-hip-opportunistic;
&I-D.bi-savi-csa;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:12:00 |