[Status] WG Review: Source Packet Routing in Networking (spring)

[The IESG <[e-mail]>]

A new IETF working group has been proposed in the Routing Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-22.

Source Packet Routing in Networking (spring)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Stewart Bryant <[e-mail]>

Mailing list
  Address: [e-mail]
  To Subscribe: https://www.ietf.org/mailman/listinfo/status
  Archive:
http://www.ietf.org/mail-archive/web/status/current/maillist.html

Charter:

The ability for a node to specify a forwarding path, other 
than the normal shortest path, that a particular packet 
will traverse, benefits a number of network functions, 
for example:

o    Some types of network virtualization, including multi-
     topology networks and the partitioning of network 
     resources for VPNs
o    Network path and node protection such as fast re-route
o    Network programmability
o    New OAM techniques
o    Simplification and reduction of network signalling 
     components
o    Load balancing and traffic engineering

Source-based routing mechanisms have previously been 
specified for network protocols, but have not seen 
widespread adoption other than in MPLS traffic engineering. 
These applications may require greater flexibility and 
per packet source imposed routing than can be achieved 
through the use of the previously defined methods.

The SPRING working group will define procedures that 
will allow a node to steer a packet along an explicit 
route using information attached to the packet and
without the need for per-path state information to be
held at transit nodes. Full explicit control (through loose
or strict path specification) can be achieved in a network 
comprising only SPRING nodes, however SPRING must 
inter-operate through loose routing in existing networks
and may find it advantageous to use loose routing for
for other network applications. 

The initial data planes that will be considered are MPLS
and IPv6.

There is an assumed trust model such that any node 
imposing an explicit route on a packet is assumed to 
be allowed to do so, however administrative and trust 
boundaries may strip explicit routes from a packet.
For each data plane technology that SPRING specifies, 
a security analysis must be provided showing how protection 
is provided against an attacker disrupting the network by 
for example, maliciously injecting SPRING packets.
There are a number of serious security concerns with 
source routing at the IP layer [RFC 5095].  As a part 
of its work, the working group will define the new 
IPv6-based routing header in way that blind attacks 
are never possible, i.e., attackers will be unable to 
send source routed packets that get successfully 
processed, without being part of the negotiation for 
setting up the source routes or being able to eavesdrop 
legitimate source routed packets. In some networks 
this base level security may be complemented with 
other mechanisms, such as packet filtering,  cryptographic 
security, etc.

Initial work will focus on SPRING within in a single AS, 
however design decisions must not preclude operation 
of SPRING across AS boundaries.

SPRING should support both centralised and distributed 
path computation.  

The SPRING WG should provide OAM and the 
management needed to manage  SPRING enabled networks. 
The SPRING protocol itself may also be used as a tool for OAM
in SPRING enabled networks.

SPRING should avoid modification to existing data 
planes that would make them incompatible with 
existing deployments. Where possible, existing control
and management plane protocols must be used within existing 
architectures to implement the SPRING function. Any
modification of or extension to existing architectures,
data planes, or control or management plane protocols 
must be carried out in the working groups responsible 
for the architecture, data plane, or control or 
management plane protocol being modified and in 
co-ordination with this working group, but may be 
done in this working group after agreement with 
all the relevant WG chairs and responsible Area Directors.

The SPRING working group is chartered for the following 
list of items:

o Identification and evaluation of use cases for SPRING. 
   These use cases must include a definition of the 
   data plane for the environment in which they are to be 
   deployed.

o Definition of requirements and/or any new data plane 
   encodings and procedures, required to implement 
   the use cases. Such procedures must include the 
   necessary security considerations.

o Definition of requirements and/or any new control plane 
   mechanism needed to enable the use cases.

o Definition of requirements and/or management  plane 
   mechanism needed to manage and operate a 
   SPRING enabled network.

The SPRING working group will not work on any 
mechanisms for use in networks that forward IPv4 packets.
 
[ Following to be replaced by milestones before final review]
The working group will develop the following documents:

o One or more documents describing SPRING use cases.

o Specification of a high-level abstract architecture for 
   SPRING and requirements for modifications to existing 
   architecture to support SPRING use cases.

o Specification of any required new procedures to support 
   SPRING use cases.

o One or more data plane extension requirements documents, 
   including documenting the impact on existing deployments
   of the existing data plane.

o One or more control protocol extensions requirements 
   documents.

o Publish SPRING management requirements document.

o Specify the OAM mechanisms needed to support SPRING.

o Document inter-working and co-existence between the 
   new procedures and the existing signalling and routing 
   protocols.

o Inter-operability reports pertaining to the implementation 
   of extensions supporting SPRING.


Milestones:

TBD