ICN Ping Protocol
draft-mastorakis-icnrg-icnping-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Spyridon Mastorakis , Jim Gibson , Ilya Moiseenko , Ralph Droms , David R. Oran | ||
| Last updated | 2016-08-26 | ||
| Replaced by | draft-irtf-icnrg-icnping | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mastorakis-icnrg-icnping-00
The header of an echo reply consists of the header fields of a CCNx
Content Object and a hop-by-hop PathSteering TLV. The value of the
packet type field is Echo Reply. The exact numeric value of this
field type is to be determined. The PathSteering header TLV is as
defined for the echo request packet.
A ping echo reply message is of type Content Object, contains a Name
TLV (name of the corresponding echo request), a PayloadType TLV and
an ExpiryTime TLV with a value of 0 to indicate that echo replies
must not be cached by the network.
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
+---------------+---------------+---------------+---------------+
| | |
| MessageType = 2 | MessageLength |
| | |
+---------------+---------------+---------------+---------------+
| |
| Name TLV |
| |
+---------------+---------------+---------------+---------------+
| |
| PayloadType TLV |
| |
+---------------+---------------+---------------+---------------+
| |
| ExpiryTime TLV |
| |
+---------------+---------------+---------------+---------------+
Echo Reply Message Format
The PayloadType TLV is presented below. It is of type
T_PAYLOADTYPE_DATA, and the data schema consists of 2 TLVs: 1) the
name of the sender of this reply (with the same structure as a CCNx
Name TLV), 2) the sender's signature of their own name (with the same
structure as a CCNx ValidationPayload TLV), 3) a TLV with return
codes to indicate what led to the generation of this reply (i.e.,
existence of a local application, a CS hit or a match with a
forwarder's administrative name as specified in Section 5).
Mastorakis, et al. Expires February 27, 2017 [Page 9]
Internet-Draft ICN Ping August 2016
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
+---------------+---------------+---------------+---------------+
| | |
| T_PAYLOADTYPE_DATA | Length |
| | |
+---------------+---------------+---------------+---------------+
/ /
/ Sender's Name TLV /
/ /
+---------------+---------------+---------------+---------------+
/ /
/ Sender's Signature TLV /
/ /
+---------------+---------------+---------------+---------------+
/ /
/ Echo Reply Code TLV /
/ /
+---------------+---------------+---------------+---------------+
Echo Reply Message Format
The goal of including the name of the sender in the echo reply is to
enable the user to reach this entity directly to ask for further
management/administrative information using generic Interest-Data
exchanges after a successful verification of the sender's name.
The structure of the Echo Reply Code TLV is presented below (16-bit
value). The potential values are the following:
o 1: Indicates that the target name matched the administrative name
of a forwarder.
o 2: Indicates that the target name matched a prefix served by an
application.
o 3: Indicates that the target name matched the name of an object in
a forwarder's CS.
Mastorakis, et al. Expires February 27, 2017 [Page 10]
Internet-Draft ICN Ping August 2016
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
+---------------+---------------+---------------+---------------+
| | |
| Echo_Reply_Code_Type | Echo_Reply_Code_Length = 2 |
| | |
+---------------+---------------+---------------+---------------+
| |
| Echo_Reply_Code_Value |
+---------------+---------------+---------------+---------------+
Echo Reply Code TLV
5. Forwarder Handling
When a forwarder receives an echo request, it will first extract the
message's base name (i.e., the request name with the Nonce name
component excluded).
In some cases, the forwarder will originate an echo reply, sending
the reply downstream through the face on which the echo request was
received. An echo reply will include the forwarder's own name and
signature, and, the appropriate echo reply code based on the
condition that triggered the reply generation. It will also include
a path steering TLV, initially a null value (since the echo reply
originator does not forward the request and, thus, does not make a
path choice).
The forwarder generates an echo reply in the following cases:
o Assuming that a forwarder has been given one or more
administrative names, the echo request base name exactly matches
any of the forwarder's administrative name(s).
o The echo request's base name exactly matches the name of a
content-object residing in the forwarder's CS (unless the ping
client application has chosen not to receive replies due to CS
hits as specified in Appendix A).
o The echo request base name matches (in a Longest Prefix Match
manner) a FIB entry with an outgoing face referring to a local
application.
If none of the conditions to reply to the echo request are met, the
forwarder will attempt to forward the echo request upstream based on
Mastorakis, et al. Expires February 27, 2017 [Page 11]
Internet-Draft ICN Ping August 2016
the path steering value (if present) the results of the FIB LPM
lookup and PIT creation (based on the name including the nonce typed
name component). If no valid next-hop is found, an InterestReturn is
sent downstream (as with a failed attempt to forward an ordinary
Interest).
A received echo reply will be matched to an existing PIT entry as
usual. On the reverse path, the path steering TLV of an echo reply
will be updated by each forwarder to encode its next-hop choice.
When included in subsequent echo requests, this path steering TLV
will allow the forwarders to steer the requests along the same path.
6. Security Considerations
To avoid reflection attacks, where a compromised forwarder includes
in the reply the name of a victim forwarder to redirect the future
administrative traffic towards the victim, the forwarder that
generates a reply has to sign the name included in the payload. In
this way, the client is able to verify that the included name is
legitimate and refers to the forwarder that generated the reply.
Alternatively, the forwarder can include in the reply payload their
routable prefix(es) encoded as a signed NDN Link Object [SNAMP].
7. Acknowledgements
The authors would like to thank Mark Stapp for the fruitful
discussion on the objectives of ICN ping protocol.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References
[CCNMessages]
Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format.", 2016, <https://tools.ietf.org/html/draft-irtf-
icnrg-ccnxmessages-03>.
[LIPSIN] Jokela, P. and et al, "LIPSIN: line speed publish/
subscribe inter-networking, ACM SIGCOMM Computer
Communication Review 39.4: 195-206", 2009.
Mastorakis, et al. Expires February 27, 2017 [Page 12]
Internet-Draft ICN Ping August 2016
[SNAMP] Afanasyev, A. and et al, "SNAMP: Secure namespace mapping
to scale NDN forwarding, IEEE Conference on Computer
Communications Workshops (INFOCOM WKSHPS)", 2015.
Appendix A. Ping Client Application (Consumer) Operation
This section is an informative appendix regarding the proposed ping
client operation.
The ping client application is responsible for generating echo
requests for prefixes provided by users.
When generating a series of echo requests for a specific name, the
first echo request will typically not include a PathSteering TLV,
since no TLV value is known. After an echo reply containing a
PathSteering TLV is received, each subsequent echo request can
include the received path steering value in the PathSteering header
TLV to drive the requests towards a common path as part of checking
the network performance. To discover more paths, a client can omit
the path steering TLV in future requests. Moreover, for each new
ping echo request, the client has to generate a new nonce and record
the time that the request was expressed. It will also set the
lifetime of an echo request, which will have semantics similar to the
lifetime of an Interest.
Moreover, the client application might like not to receive echo
replies due to CS hits. A mechanism to achieve that would be to use
a Content Object Hash Restriction TLV with a value of 0 in the
payload of an echo request message.
When it receives an echo reply, the client would typically match the
reply to a sent request and compute the round-trip time of the
request. It should parse the PathSteering value and decode the
reply's payload to parse the the sender's name and signature. The
client should verify that both the received message and the
forwarder's name have been signed by the key of the forwarder, whose
name is included in the payload of the reply (by fetching this
forwarder's public key and verifying the contained signature). The
client can also decode the Echo Reply Code TLV to understand the
condition that triggered the generation of the reply.
In the case that an echo reply is not received for a request within a
certain time interval (lifetime of the request), the client should
time-out and send a new request with a new nonce value up to some
maximum number of requests to be sent specified by the user.
Mastorakis, et al. Expires February 27, 2017 [Page 13]
Internet-Draft ICN Ping August 2016
Authors' Addresses
Spyridon Mastorakis
UCLA
Los Angeles, CA
US
Email: mastorakis@cs.ucla.edu
Jim Gibson
Cisco Systems
Cambridge, MA
US
Email: gibson@cisco.com
Ilya Moiseenko
Cisco Systems
Cambridge, MA
US
Email: iliamo@mailbox.org
Ralph Droms
Cisco Systems
Cambridge, MA
US
Email: rdroms.ietf@gmail.com
Dave Oran
Cisco Systems
Cambridge, MA
US
Email: daveoran@orandom.net
Mastorakis, et al. Expires February 27, 2017 [Page 14]