draft-ietf-nsis-tunnel-11.txt   draft-ietf-nsis-tunnel-12.txt 
IETF Next Steps in Signaling C. Shen IETF Next Steps in Signaling C. Shen
Internet-Draft H. Schulzrinne Internet-Draft H. Schulzrinne
Intended status: Experimental Columbia U. Intended status: Experimental Columbia U.
Expires: December 5, 2010 S. Lee Expires: January 7, 2011 S. Lee
J. Bang J. Bang
Samsung AIT Samsung AIT
June 3, 2010 July 6, 2010
NSIS Operation Over IP Tunnels NSIS Operation Over IP Tunnels
draft-ietf-nsis-tunnel-11.txt draft-ietf-nsis-tunnel-12.txt
Abstract Abstract
NSIS Quality of Service (QoS) signaling enables applications to NSIS Quality of Service (QoS) signaling enables applications to
perform QoS reservation along a data flow path. When the data flow perform QoS reservation along a data flow path. When the data flow
path contains IP tunnel segments, NSIS QoS signaling has no effect path contains IP tunnel segments, NSIS QoS signaling has no effect
within those tunnel segments and the resulting QoS-untended tunnel within those tunnel segments and the resulting tunnel segments could
segments could become the weakest QoS link which may invalidate the become the weakest QoS link which may invalidate the QoS efforts in
QoS efforts in the rest of the end-to-end path. The problem with the rest of the end-to-end path. The problem with NSIS signaling
NSIS signaling within the tunnel is caused by the tunnel within the tunnel is caused by the tunnel encapsulation which masks
encapsulation which masks packets' original IP header fields. Those packets' original IP header fields. Those original IP header fields
original IP header fields are needed to intercept NSIS signaling are needed to intercept NSIS signaling messages and classify QoS data
messages and classify QoS data packets. This document defines a packets. This document defines a solution to this problem by mapping
solution to this problem by mapping end-to-end QoS session requests end-to-end QoS session requests to corresponding QoS sessions in the
to corresponding QoS sessions in the tunnel, thus extending the end- tunnel, thus extending the end-to-end QoS signaling into the IP
to-end QoS signaling into the IP tunnel segments. tunnel segments.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2010. This Internet-Draft will expire on January 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 22 skipping to change at page 3, line 22
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10
4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11 4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13 4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13
5. NSIS Operation over Tunnels with Pre-configured QoS 5. NSIS Operation over Tunnels with Pre-configured QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14 5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14
5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15 5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15
6. NSIS Operation over Tunnels with Dynamically Created QoS 6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 16 6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 17
6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 19 6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 19
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22 7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
IP tunneling is a technique that allows a packet to be encapsulated IP tunneling is a technique that allows a packet to be encapsulated
and carried as payload within an IP packet. The resulting and carried as payload within an IP packet. The resulting
encapsulated packet is called an IP tunnel packet, and the packet encapsulated packet is called an IP tunnel packet, and the packet
being tunneled is called the original packet. In typical scenarios, being tunneled is called the original packet. In typical scenarios,
IP tunneling is used to exert explicit forwarding path control (e.g., IP tunneling is used to exert explicit forwarding path control (e.g.,
in Mobile IP [RFC3344]), facilitate the secure IP delivery in Mobile IP [RFC3344]), facilitate the secure IP delivery
architecture (e.g., in IPSEC [RFC4301]), and help packet routing in architecture (e.g., in IPsec [RFC4301]), and help packet routing in
IP networks of different characteristics (e.g., between IPv6 and IPv4 IP networks of different characteristics (e.g., between IPv6 and IPv4
networks [RFC4213]). networks [RFC4213]).
This document considers the situation when the packet being tunneled This document considers the situation when the packet being tunneled
contains a Next Step In Signaling (NSIS) [RFC4080] message. NSIS is contains a Next Step In Signaling (NSIS) [RFC4080] message. NSIS is
an IP network layer signaling architecture consisting of a Generic an IP network layer signaling architecture consisting of a Generic
Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer
for signaling transport, and an NSIS Signaling Layer Protocol (NSLP) for signaling transport, and an NSIS Signaling Layer Protocol (NSLP)
sub-layer customizable for different applications. We focus on the sub-layer customizable for different applications. We focus on the
Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides
skipping to change at page 5, line 41 skipping to change at page 5, line 41
the specific tunnel mechanism used. the specific tunnel mechanism used.
Tunnel Intermediate Node (Tmid): A node which resides in the middle Tunnel Intermediate Node (Tmid): A node which resides in the middle
of the forwarding path between the tunnel entry-point node and the of the forwarding path between the tunnel entry-point node and the
tunnel exit-point node. tunnel exit-point node.
Flow Identifier (Flow ID): The set of header fields which is used to Flow Identifier (Flow ID): The set of header fields which is used to
identify a [data] flow. For example, it may include flow sender identify a [data] flow. For example, it may include flow sender
and receiver addresses, protocol and port numbers. and receiver addresses, protocol and port numbers.
End-to-end [QoS] Signaling: The signaling process that manipulates End-to-end QoS Signaling: The signaling process that manipulates the
the QoS control information in the end-to-end path from the flow QoS control information in the end-to-end path from the flow
sender to the flow receiver. When the end-to-end flow path sender to the flow receiver. When the end-to-end flow path
contains tunnel segments, this document uses end-to-end [QoS] contains tunnel segments, this document uses end-to-end QoS
signaling to refer specially to the [QoS] signaling outside the signaling to refer specially to the QoS signaling outside the
tunnel segments. tunnel segments. This document uses "end-to-end QoS signaling"
and "end-to-end signaling" interchangeably.
Tunnel [QoS] Signaling: The signaling process that manipulates the Tunnel QoS Signaling: The signaling process that manipulates the QoS
QoS control information in the path inside a tunnel, between the control information in the path inside a tunnel, between the
tunnel entry-point and the tunnel exit-point nodes. tunnel entry-point and the tunnel exit-point nodes. This document
uses "tunnel QoS signaling" and "tunnel signaling"
interchangeably.
NSIS-aware Node: A node that supports NSIS signaling. NSIS-aware Node: A node that supports NSIS signaling.
NSIS-aware Tunnel End-point Node: A tunnel end-point node which is NSIS-aware Tunnel End-point Node: A tunnel end-point node which is
also an NSIS node. also an NSIS node.
NSIS-tunnel-aware [Tunnel] End-point Node: An NSIS-aware Tunnel End- NSIS-tunnel-aware Tunnel End-point Node: An NSIS-aware Tunnel End-
point node which also supports the mechanism for NSIS operating point node which also supports the mechanism for NSIS operating
over IP tunnels defined in this document. over IP tunnels defined in this document. This document uses
"NSIS-tunnel-aware tunnel end-point node" and "NSIS-tunnel-aware
end-point node" interchangeably.
3. Problem Statement 3. Problem Statement
3.1. IP Tunneling Protocols 3.1. IP Tunneling Protocols
Tunnel from node B to node D Tunnel from node B to node D
<----------------------> <---------------------->
Tunnel Tunnel Tunnel Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point Entry-Point Intermediate Exit-Point
Node Node Node Node Node Node
skipping to change at page 7, line 46 skipping to change at page 8, line 6
< Tunnel IP Packet > < Tunnel IP Packet >
Figure 2: IP Tunnel Encapsulation Figure 2: IP Tunnel Encapsulation
Commonly used IP tunneling protocols include Generic Routing Commonly used IP tunneling protocols include Generic Routing
Encapsulation (GRE) [RFC1701][RFC2784], Generic Routing Encapsulation Encapsulation (GRE) [RFC1701][RFC2784], Generic Routing Encapsulation
over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP
(IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP (IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP
(MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213], (MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213],
Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473] Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473]
and IPSEC tunneling mode (IPSEC) [RFC4301][RFC4303]. Among these and IPsec tunneling mode (IPsec) [RFC4301][RFC4303]. Among these
tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4 and tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4 and
IPv6GEN contain only a tunnel IP header, and no tunnel specific IPv6GEN contain only a tunnel IP header, and no tunnel specific
header. All the other tunneling protocols have a tunnel header header. All the other tunneling protocols have a tunnel header
consisting of both a tunnel IP header and a tunnel specific header. consisting of both a tunnel IP header and a tunnel specific header.
The tunnel specific header is the GRE header for GRE and GREIPv4, the The tunnel specific header is the GRE header for GRE and GREIPv4, the
minimum encapsulation header for MINENC and the Encapsulation minimum encapsulation header for MINENC and the Encapsulation
Security Payload (ESP) header for IPSEC tunneling mode. As will be Security Payload (ESP) header for IPsec tunneling mode. As will be
discussed in Section 4.3, some of the tunnel specific headers may be discussed in Section 4.3, some of the tunnel specific headers may be
used to identify a flow in the tunnel and facilitate NSIS operating used to identify a flow in the tunnel and facilitate NSIS operating
over IP tunnels. over IP tunnels.
3.2. NSIS QoS Signaling in the Presence of IP Tunnels 3.2. NSIS QoS Signaling in the Presence of IP Tunnels
Typically, applications use NSIS QoS signaling to reserve resources Typically, applications use NSIS QoS signaling to reserve resources
for a flow along the flow path. NSIS QoS signaling can be initiated for a flow along the flow path. NSIS QoS signaling can be initiated
by either the flow sender or flow receiver. Figure 3 shows an by either the flow sender or flow receiver. Figure 3 shows an
example scenario with five NSIS nodes, including flow sender node A, example scenario with five NSIS nodes, including flow sender node A,
skipping to change at page 8, line 44 skipping to change at page 8, line 50
receiver node E. The RESERVE message gets forwarded by intermediate receiver node E. The RESERVE message gets forwarded by intermediate
NSIS Nodes B, C, and D and finally reaches receiver node E. Receiver NSIS Nodes B, C, and D and finally reaches receiver node E. Receiver
node E then sends back a RESPONSE message confirming the QoS node E then sends back a RESPONSE message confirming the QoS
reservation, again through the previous intermediate NSIS nodes in reservation, again through the previous intermediate NSIS nodes in
the flow path. the flow path.
There are two important aspects in the above signaling process that There are two important aspects in the above signaling process that
are worth mentioning. First, the flow sender does not initially know are worth mentioning. First, the flow sender does not initially know
exactly which intermediate nodes are NSIS-aware and should be exactly which intermediate nodes are NSIS-aware and should be
involved in the signaling process for a flow from node A to node E. involved in the signaling process for a flow from node A to node E.
Discovery of those nodes, namely node B, C and D is accomplished by a Discovery of those nodes, namely nodes B, C and D is accomplished by
separate NSIS peer discovery process (not shown above, see a separate NSIS peer discovery process (not shown above, see
[I-D.ietf-nsis-ntlp]). The NSIS peer discovery messages contain [I-D.ietf-nsis-ntlp]). The NSIS peer discovery messages contain
special IP header and payload format or include a Router Alert Option special IP header and payload format or include a Router Alert Option
(RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery (RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery
messages allow node B, C and D to intercept them and subsequently messages allow nodes B, C and D to intercept them and subsequently
insert themselves into the signaling path for the flow in question. insert themselves into the signaling path for the flow in question.
After formation of the signaling path, all signaling messages After formation of the signaling path, all signaling messages
corresponding to this flow will be passed to these nodes for corresponding to this flow will be passed to these nodes for
processing. Other nodes which are not NSIS-aware simply forward all processing. Other nodes which are not NSIS-aware simply forward all
signaling messages like any other IP packets without additional signaling messages like any other IP packets without additional
handling. handling.
Node A Node B Node C Node D Node E Node A Node B Node C Node D Node E
| | | | | | | | | |
| RESERVE | | | | | RESERVE | | | |
skipping to change at page 10, line 9 skipping to change at page 10, line 15
insert itself in the flow signaling path. Furthermore, the Flow ID insert itself in the flow signaling path. Furthermore, the Flow ID
of the original flow is based on IP header fields of the original of the original flow is based on IP header fields of the original
packet. Those fields are also hidden in the payload of the tunnel packet. Those fields are also hidden in the payload of the tunnel
packet. So there is no way node C can classify packets belonging to packet. So there is no way node C can classify packets belonging to
that flow in the tunnel. In summary, the problem is that tunnel that flow in the tunnel. In summary, the problem is that tunnel
intermediate nodes are unable to intercept original NSIS signaling intermediate nodes are unable to intercept original NSIS signaling
messages and unable to classify original data flow packets as a messages and unable to classify original data flow packets as a
result of tunnel encapsulation. An IP tunnel segment appears just result of tunnel encapsulation. An IP tunnel segment appears just
like a QoS-unaware virtual link. Since the best QoS of an end-to-end like a QoS-unaware virtual link. Since the best QoS of an end-to-end
path is judged based on its weakest segment, leaving the tunnel path path is judged based on its weakest segment, leaving the tunnel path
"untended" risks voiding other efforts to provide QoS in the rest of without QoS risks voiding other efforts to provide QoS in the rest of
the path. the path.
Tunnel from node B to node D Tunnel from node B to node D
<----------------------> <---------------------->
Tunnel Tunnel Tunnel Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point Entry-Point Intermediate Exit-Point
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E| |A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
skipping to change at page 12, line 5 skipping to change at page 12, line 11
session uses sender-initiated or receiver-initiated NSIS signaling session uses sender-initiated or receiver-initiated NSIS signaling
mode. The details about which end-to-end session can be mapped to mode. The details about which end-to-end session can be mapped to
which pre-configured tunnel session depend on policy mechanisms which pre-configured tunnel session depend on policy mechanisms
outside the scope of this document. outside the scope of this document.
For tunnels that do not maintain pre-configured QoS sessions, the For tunnels that do not maintain pre-configured QoS sessions, the
NSIS-tunnel-aware end-points dynamically create and manage a NSIS-tunnel-aware end-points dynamically create and manage a
corresponding tunnel QoS session for the end-to-end session. Since corresponding tunnel QoS session for the end-to-end session. Since
the initiation mode of both QoS sessions can be sender-initiated or the initiation mode of both QoS sessions can be sender-initiated or
receiver-initiated, to simplify the design, we require that the receiver-initiated, to simplify the design, we require that the
initiation mode of the tunnel QoS session follow that of the end-to- initiation mode of the tunnel QoS session follows that of the end-to-
end QoS session. In other words, the end-to-end QoS session and its end QoS session. In other words, the end-to-end QoS session and its
corresponding tunnel QoS session are either both sender-initiated or corresponding tunnel QoS session are either both sender-initiated or
both receiver-initiated. To keep the handling mechanism consistent both receiver-initiated. To keep the handling mechanism consistent
with the case for tunnels with pre-configured QoS sessions, the with the case for tunnels with pre-configured QoS sessions, the
tunnel entry-point always initiates the mapping between the tunnel tunnel entry-point always initiates the mapping between the tunnel
session and the end-to-end session. session and the end-to-end session.
As the mapping initiator, the tunnel entry-point records the As the mapping initiator, the tunnel entry-point records the
association between the end-to-end session and its corresponding association between the end-to-end session and its corresponding
tunnel session, both in tunnels with and without pre-configured QoS tunnel session, both in tunnels with and without pre-configured QoS
skipping to change at page 13, line 33 skipping to change at page 13, line 40
A tunnel Flow ID identifies the end-to-end flow for packet A tunnel Flow ID identifies the end-to-end flow for packet
classification within the tunnel. The tunnel Flow ID is based on a classification within the tunnel. The tunnel Flow ID is based on a
set of tunnel header fields. Different tunnel Flow ID can be chosen set of tunnel header fields. Different tunnel Flow ID can be chosen
for different tunneling mechanisms in order to minimize the for different tunneling mechanisms in order to minimize the
classification overhead. This document specifies the following Flow classification overhead. This document specifies the following Flow
ID formats for the respective tunneling protocols. ID formats for the respective tunneling protocols.
o For IPv6 tunneling protocols (IPv6GEN), the tunnel Flow ID o For IPv6 tunneling protocols (IPv6GEN), the tunnel Flow ID
consists of the tunnel entry-point IPv6 address and the tunnel consists of the tunnel entry-point IPv6 address and the tunnel
exit-point IPv6 address plus a unique IPv6 flow label [RFC3697]. exit-point IPv6 address plus a unique IPv6 flow label [RFC3697].
o For IPSEC tunnel mode (IPSEC), the tunnel Flow ID contains the o For IPsec tunnel mode (IPsec), the tunnel Flow ID contains the
tunnel entry-point IP address and the tunnel exit-point IP address tunnel entry-point IP address and the tunnel exit-point IP address
plus the Security Parameter Index (SPI). plus the Security Parameter Index (SPI).
o For all other tunneling protocols (GRE, GREIPv4, IPv4INIPv4, o For all other tunneling protocols (GRE, GREIPv4, IPv4INIPv4,
MINENC, IPv6INIPv4), the tunnel entry-point inserts an additional MINENC, IPv6INIPv4), the tunnel entry-point inserts an additional
UDP header between the tunnel header and the original packet. The UDP header between the tunnel header and the original packet. The
Flow ID consists of the tunnel entry-point and tunnel exit-point Flow ID consists of the tunnel entry-point and tunnel exit-point
IP addresses and the source port number in the additional UDP IP addresses and the source port number in the additional UDP
header. In these cases, it is especially important that the header. The source port number is dynamically chosen by the
tunnel exit-point also understands the additional UDP tunnel entry-point and conveyed to the tunnel exit-point. In
encapsulation, and therefore can correctly decapsulate both the these cases, it is especially important that the tunnel exit-point
normal tunnel header and the additional UDP header. In other understands the additional UDP encapsulation, and therefore can
words, both tunnel end-points need to be NSIS-tunnel-aware. correctly decapsulate both the normal tunnel header and the
additional UDP header. In other words, both tunnel end-points
need to be NSIS-tunnel-aware.
The above recommendations about choosing tunnel Flow ID apply to The above recommendations about choosing tunnel Flow ID apply to
dynamically created QoS tunnel sessions. For pre-configured QoS dynamically created QoS tunnel sessions. For pre-configured QoS
tunnel sessions, the corresponding Flow ID is determined by the tunnel sessions, the corresponding Flow ID is determined by the
configuration mechanism itself. For example, if the tunnel QoS is configuration mechanism itself. For example, if the tunnel QoS is
DiffServ based, the DiffServ Code Point (DSCP) field value may be DiffServ based, the DiffServ Code Point (DSCP) field value may be
used to identify the corresponding tunnel session. used to identify the corresponding tunnel session.
5. NSIS Operation over Tunnels with Pre-configured QoS Sessions 5. NSIS Operation over Tunnels with Pre-configured QoS Sessions
skipping to change at page 22, line 38 skipping to change at page 23, line 4
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length | |A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NODE_CAPABILITY_TUNNEL Object Format Figure 10: NODE_CAPABILITY_TUNNEL Object Format
Type: TBD from the shared NSLP object type space Type: TBD from the shared NSLP object type space
Length: 0 Length: 0
The bits marked 'A' and 'B' define the desired behavior for objects The bits marked 'A' and 'B' define the desired behavior for objects
whose Type field is not recognized. If a node does not recognize the whose Type field is not recognized. If a node does not recognize the
NODE_CAPABILITY_TUNNEL object, the desired behavior is "Forward". NODE_CAPABILITY_TUNNEL object, the desired behavior is "Forward".
That is, the object must be retained unchanged and forwarded as a That is, the object must be retained unchanged and forwarded as a
result of message processing. This is satisfied by setting 'AB' to result of message processing. This is satisfied by setting 'AB' to
'10'. '10'.
The 'r' bit stands for 'reserved'.
The NODE_CAPABILITY_TUNNEL object is included in a tunnel QUERY' or The NODE_CAPABILITY_TUNNEL object is included in a tunnel QUERY' or
RESERVE' message by a tunnel end-point that needs to learn about the RESERVE' message by a tunnel end-point that needs to learn about the
other end-point's NSIS tunnel handling capability. If the receiving other end-point's NSIS tunnel handling capability. If the receiving
tunnel end-point is indeed NSIS-tunnel-aware, it recognizes this tunnel end-point is indeed NSIS-tunnel-aware, it recognizes this
object and knows that the sending end-point is NSIS-tunnel-aware. object and knows that the sending end-point is NSIS-tunnel-aware.
The receiving tunnel end-point places the same object in a tunnel The receiving tunnel end-point places the same object in a tunnel
RESPONSE' message to inform the sending end-point that it is also RESPONSE' message to inform the sending end-point that it is also
NSIS-tunnel-aware. The use of the NODE_CAPABILITY_TUNNEL object in NSIS-tunnel-aware. The use of the NODE_CAPABILITY_TUNNEL object in
the cases of sender-initiated reservation and receiver-initiated the cases of sender-initiated reservation and receiver-initiated
reservation are as follows. reservation are as follows.
skipping to change at page 23, line 41 skipping to change at page 24, line 7
8. IANA Considerations 8. IANA Considerations
This document defines a new object type called NODE_CAPABILITY_TUNNEL This document defines a new object type called NODE_CAPABILITY_TUNNEL
for QoS NSLP. Its Type value needs to be assigned by IANA. The for QoS NSLP. Its Type value needs to be assigned by IANA. The
object format and the setting of the extensibility bits are defined object format and the setting of the extensibility bits are defined
in Section 7. in Section 7.
9. Security Considerations 9. Security Considerations
This draft does not raise new security threats. Security There are two IPsec related security considerations about using this
considerations for NSIS NTLP and QoS NSLP are discussed in NSIS and IP tunnel interoperation mechanism. First, NSIS messages
[I-D.ietf-nsis-ntlp] and [I-D.ietf-nsis-qos-nslp], respectively. may require per-hop processing within the IPsec tunnel, and that is
General threats for NSIS can be found in [RFC4081]. potentially incompatible with IPsec. A similar problem exists for
RSVP interacting with IPsec, when the Router Alert option is used
(Section A.1 of RFC4302 [RFC4302]). If this mechanism is indeed used
for NSIS and IPsec tunnels, a so-called covert channel could exist
where someone can create spurious NSIS signaling flows within the
protected network in order to create signaling in the outside
network, which then someone else is monitoring. For highly secure
networks, this would be seen as a way to smuggle information out of
the network, and therefore this channel will need to be rate-limited.
A similar covert channel rate-limit problem exists for using
Differentiated Service (DS) or Explicit Congestion Notification (ECN)
fields with IPsec (Section 5.1.2 of RFC4301 [RFC4301]).
Second, since the NSIS-tunnel-aware end-point is responsible for
adapting changes between the NSIS signaling both inside and outside
the tunnel, there could be additional risks for an IPsec end-point
which is also an NSIS-tunnel-aware end-point. For example, security
vulnerability (e.g., buffer overflow) on the NSIS stack of that IPsec
tunnel end-point may be exposed to the unprotected outside network.
Nevertheless, it should also be noted that if any node along the
signaling path is compromised, the whole end-to-end QoS signaling
could be affected, whether the end-to-end path includes an IPsec
tunnel or not.
Several other documents discussed security issues for NSIS. General
threats for NSIS can be found in [RFC4081]. Security considerations
for NSIS NTLP and QoS NSLP are discussed in [I-D.ietf-nsis-ntlp] and
[I-D.ietf-nsis-qos-nslp], respectively.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Roland Bless, Georgios Karagiannis, The authors would like to thank Roland Bless, Francis Dupont, Lars
Jukka Manner, Martin Rohricht, Martin Stiemerling, Hannes Tschofenig, Eggert, Russ Housley, Georgios Karagiannis, Jukka Manner, Martin
Rohricht, Peter Saint-Andre, Martin Stiemerling, Hannes Tschofenig,
and other members of the NSIS working group for comments to this and other members of the NSIS working group for comments to this
work. work. Thanks to Yaron Sheffer for pointing out the IPsec related
security considerations.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), January 2010. (work in progress), January 2010.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
11.2. Informative References 11.2. Informative References
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994. Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1702, Routing Encapsulation over IPv4 networks", RFC 1702,
October 1994. October 1994.
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996. October 1996.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996. October 1996.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
Authors' Addresses Authors' Addresses
Charles Shen Charles Shen
Columbia University Columbia University
Department of Computer Science Department of Computer Science
1214 Amsterdam Avenue, MC 0401 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
skipping to change at page 26, line 8 skipping to change at page 27, line 4
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
1214 Amsterdam Avenue, MC 0401 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
USA USA
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
Sung-Hyuck Lee Sung-Hyuck Lee
SAMSUNG Advanced Institute of Technology SAMSUNG Advanced Institute of Technology
San 14-1, Nongseo-ri, Giheung-eup San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712 Yongin-si, Gyeonggi-do 449-712
KOREA South Korea
Phone: +82 31 280 9552 Phone: +82 31 280 9552
Email: starsu.lee@samsung.com Email: starsu.lee@samsung.com
Jong Ho Bang Jong Ho Bang
SAMSUNG Advanced Institute of Technology SAMSUNG Advanced Institute of Technology
San 14-1, Nongseo-ri, Giheung-eup San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712 Yongin-si, Gyeonggi-do 449-712
KOREA South Korea
Phone: +82 31 280 9585 Phone: +82 31 280 9585
Email: jh0278.bang@samsung.com Email: jh0278.bang@samsung.com
 End of changes. 34 change blocks. 
78 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/