Re: [Status] SPRING Charter

Thomas,

On Oct 15, 2013, at 9:27 PM, Thomas Narten wrote:

> Hi John.
> 
>> Thomas,
> 
>> On Oct 15, 2013, at 9:46 AM, Thomas Narten <narten@us.ibm.com> wrote:
> 
>>> When it comes to IPv6, however, the question of who is capable of
>>> adding these "segment routes" becomes very significant. If the
>>> originating end node can add SRs, the attack surface for exploiting
>>> SRs becomes much more complicated
> 
>> Do you think if the document set said "a host SHALL NOT add an
>> explicit route" it would make the attack surface less complicated?
>> Why?
> 
> Not at all. We all know Bad Guys don't follow the rules. If the
> architecture allows for an end host to add stuff to a packet header
> (like an SR) that the other nodes have to deal with, someone wanting
> to exploit the system will use such a capability to do so.

I really don't think banking on an architectural designation of router vs. host is the best approach here. In particular when it comes to anything that resembles tunneling.

> 
> On the other hand, if the architecture didn't make it possible for an
> end host to do this, that would be much better. MPLS effectively
> acheives this because arbitrary end hosts don't have access to the
> MPLS layer. They can only generate IP packets...

If there is demand for SR beyond the traditional boundaries of an MPLS core network, it will find its way. I'd much rather develop this thoughtfully from the get-go than deal with the pressure to expand SR beyond the presumed boundaries of MPLS (as we have already had to do in the past with various MPLS over IP encapsulations). 

> Hence, I'd see a much safer/verifiable way to do this architecturally
> in IPv6 if it was used in conjunction with tunneling, where the tunnel
> entry/exit points were controlled by network admin.

I think Jari's text captures your higher-level point, without presupposing a particular solution:

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

- Mark

> 
> Thomas
> 
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status