source route reversal

[Tony Li <[e-mail]>]

   > A question on the current rr draft  (I don't know the answer)
   > 
   > A number of places the current draft says that if there is a source 
   > route in the packet and any response (ICMP etc) has to be generated, 
   > the source route MUST be reversed and used to direct the return packet.  
   > The issue of doing this sort of thing came up in the IPv6 source route 
   > discussions and some people like Tony Li had strong thoughts that
	this type of 
   > behavior should not be required.  
   > 
   > Is this something that should be brought up for specific discussion?

   Well maybe.  I expect that the draft wording correctly reflects the 
   general agreement of the group and the intent of source routes.      
   Tony, What does SDR have to say on this matter?

I dunno.  I don't speak for the group.  

I fully understand and support the intent of reversing the source
route.  My understanding is that the goal here is to have path
symmetry.  However, in an environment which supports policy routing,
this is perhaps not optimal.  I believe that the author's intent was
to disallow wholesale removal of the source route by lazy
implementations.

I believe that there is a "strong" vs.  "weak" source routing
argument, where the existing text represents the "strong" side.  The
result of the "strong" argument in a policy routing environment means
that if the reply packet would violate policy by having a source route
not matching policy, that the packet MUST be dropped.  Note that the
originator may have no mechanism for determining a source route that
is acceptable to the destination's outbound policy.  This effectively
means that source routing to the destination is effectively useless,
as it severs connectivity.  This in turn implies that much of the
initial work with policy routing is likely to be futile as we are not
able to deploy anything until we have a coherent mechanism for global
policy distribution and calculation.  In other words, never.

The "weak" source routing argument would say that connectivity is
paramount, and that the source should never have any need to know
about the destination's outbound policy, which should, in fact, be
private.  The intent of the source route reversal is to provide path
symmetry wherever possible, but is not to provide security.  Thus,
asymmetric paths are preferable to disconnection.

Accordingly, I recommend that the text be changed to reflect the
following:

- If the node is unaware of outbound policy constraints, then the node
  MUST reverse the source route.
- If the node is aware of outbound policy constraints then the node is
  free to return the packet using appropriate mechanisms within the
  bounds of those constraints.

I would appreciate having this resolved quickly.

Tony