One document matched: draft-marjou-spud-traceroute-use-cases-00.txt

Network Working Group                                     X. Marjou, Ed.
Internet-Draft                                                  A. Braud
Intended status: Informational                                    Orange
Expires: January 1, 2017                                      R. Romuald
                                                        Telecom Bretagne
                                                           June 30, 2016


                      Traceroute Use Case for SPUD
               draft-marjou-spud-traceroute-use-cases-00

Abstract

   In the context of the Substrate Protocol for User Datagrams (SPUD),
   this document proposes a new use case and its derived requirements: a
   traceroute function allowing users to explicitly ask middleboxes
   (a.k.a. network devices) to provide their geospatial information.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 1, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Marjou, et al.           Expires January 1, 2017                [Page 1]

Internet-Draft        Traceroute Use Case for SPUD             June 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Use case  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Global Traceroute . . . . . . . . . . . . . . . . . . . .   3
       3.1.1.  User Initiative . . . . . . . . . . . . . . . . . . .   3
       3.1.2.  Server Initiative . . . . . . . . . . . . . . . . . .   3
     3.2.  Traceroute, First Network Device Only . . . . . . . . . .   3
     3.3.  Do Not Traceroute . . . . . . . . . . . . . . . . . . . .   3
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Traceroute  . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  Do Not Traceroute . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Informative references  . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   The IAB is currently working on the evolution of the IP stack
   program, as captured in [I-D.trammell-stackevo-explicit-coop] to de-
   ossify the IP stack.  The Substrate Protocol for User Datagrams
   (SPUD) is a candidate for solving some of the needs identified by
   this work.  A first set of SPUD use-cases has already been identified
   as described in [I-D.trammell-spud-req].

   This document proposes an additional use-case and the derived
   requirements: a traceroute function allowing users to explicitly ask
   middleboxes (a.k.a. network devices) to provide their geospatial
   information.

2.  Terminology

   Middlebox: As defined in [RFC3234], a middlebox is any intermediary
   device performing functions other than the normal, standard functions
   of an IP router on the datagram path between a source host and
   destination host; e.g. making decisions about forwarding behavior
   based on other than addressing information, and/or modifying a packet
   before forwarding.

   Geospatial information: A set of coordinates containing a longitude,
   a latitude and possibly a timestamp which describes the location of
   the middlebox.



Marjou, et al.           Expires January 1, 2017                [Page 2]

Internet-Draft        Traceroute Use Case for SPUD             June 2016


3.  Use case

3.1.  Global Traceroute

3.1.1.  User Initiative

   A user wishes to obtain hints about the route taken by its IP flows.
   More precisely, the user wishes to get the geospatial information of
   the middleboxes located on the path between his device and the remote
   server.

3.1.2.  Server Initiative

   A service provider like an online bank service wishes to obtain hints
   about the route taken by the IP flows of their users in order to
   increase the probabilities that the remote device is under control of
   the real user and not under control of a fake user.  The activation
   of the traceroute requires the consent of the user.

3.2.  Traceroute, First Network Device Only

   A user wishes to activate the traceroute function on the first
   encountered middlebox to get an approximate location for his device.

3.3.  Do Not Traceroute

   At any time, the user can require the middleboxes to stop providing
   geospatial information.

4.  Requirements

4.1.  Traceroute

   REQ-1: A server endpoint MAY propose the traceroute activation.  It
   will be up to the user to accept or reject the proposal.

   REQ-2: A SPUD client MUST be able to request one or more middleboxes
   to provide their geospatial information.

   REQ-3: The geospatial information provided by a middlebox MUST be non
   repudiable.

   REQ-4: Providing geospatial information MUST not add significant
   delay to the packets of the flow.







Marjou, et al.           Expires January 1, 2017                [Page 3]

Internet-Draft        Traceroute Use Case for SPUD             June 2016


4.2.  Do Not Traceroute

   REQ-5: A SPUD client MUST be able to request the middleboxes not to
   provide geospatial information.

   REQ-6: A middlebox MUST NOT provide geospatial information without an
   explicit consent of the user.

5.  Security Considerations

   When there is a Graphical User Interface (GUI), the user needs an
   explicit notification indicating whether the traceroute mechanism is
   used or not.

6.  IANA Considerations

   None.

7.  Acknowledgements

   To do.

8.  Informative references

   [I-D.trammell-spud-req]
              Trammell, B. and M. KĂźhlewind, "Requirements
              for the design of a Substrate Protocol for User Datagrams
              (SPUD)", draft-trammell-spud-req-01 (work in progress),
              October 2015.

   [I-D.trammell-stackevo-explicit-coop]
              Trammell, B., "Architectural Considerations for Transport
              Evolution with Explicit Path Cooperation", draft-trammell-
              stackevo-explicit-coop-00 (work in progress), September
              2015.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
              <http://www.rfc-editor.org/info/rfc3234>.

Authors' Addresses










Marjou, et al.           Expires January 1, 2017                [Page 4]

Internet-Draft        Traceroute Use Case for SPUD             June 2016


   Xavier Marjou (editor)
   Orange
   2, avenue Pierre Marzin
   Lannion  22307
   France

   Email: xavier.marjou@orange.com


   Arnaud Braud
   Orange
   2, avenue Pierre Marzin
   Lannion  22307
   France

   Email: arnaud.braud@orange.com


   Romuald Corbel
   Telecom Bretagne
   655 Avenue du Technopole
   Plouzane  29200
   France

   Email: romuald.corbel@telecom-bretagne.eu


























Marjou, et al.           Expires January 1, 2017                [Page 5]