Re: [Status] Status of Spring

Hi Jari,

> As a result of this worry I now have to turn on filtering on the border of my
> network for the new routing header. Is there a way around this?

Let me clarify my previous message reg such filtering ...

The filtering to your infrastructure addresses should be applied for
both IPv4 and IPv6 packets. SR v6 header would be a regular v6 header
(not new routing header) with perhaps few additional extension headers
embedded to indicate the strict or loose transit nodes.

So filtering applied on the edge of the network (which should be there
regardless of SR or not) would be identical to normal case and would
in fact effectively filter out any external attempt to insert SR
routed packet into your network just based on the standard v6 header
destination IP address.

The only price to pay for this is to set bgp next hop to self if you
want segment route the transit traffic, but this for one is pretty
common today and also same would be required for MPLS encapsulation
anyway.

Best regards,
R.

On Thu, Oct 10, 2013 at 11:03 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
> Thanks Stewart and others.
>
> I wanted to add one clarification and some more technical discussion.
>
>> Jari who is the main discuss holder will work with us over
>> the next couple of days to try to get some text that will allow
>> us to go forward.
>
> I would really like to work with you to get this resolved. I see the issue, as I think do others, but I need your help in the WG to figure out what to do about it. I do not currently have a good idea, but I am sure we'll resolve it somehow. Some of you have already offered help - thanks.
>
> To provide a bit more context why just saying that we'll use it in closed networks is unlikely to work:
>
> The MPLS case was easy because these networks are naturally restricted to specific areas, and there is no way for a random person in some other part of the Internet to send you packets with MPLS labels.
>
> The basic problem with IP is that when someone defines a new source-routing header solution and applies it in network X, it does not affect just X. The code will be on various devices - with RH0 we had it on BSD, Linux, various brands of routers, maybe even on hosts, etc. Often turned on by default, leaving vulnerabilities open in many networks.
>
> We could say that the feature MUST be by default off and can only be enabled upon explicit request from the network manager. However, if I have a thousand devices in my network I start to worry that at least one of them has accidentally enabled the feature. So now that device could potentially reflect traffic sent to it from the outside to an internal destination. This could be used to subvert firewall policies, DoS attacks on nodes not visible from the Internet, etc. As a result of this worry I now have to turn on filtering on the border of my network for the new routing header. Is there a way around this?
>
> Also, the charter is clear that you are wishing for at least an eventual inter-AS solution. That raises the bar.
>
> In any case, I could completely off base with the above - I have not read your proposed solutions and maybe you are thinking of something completely different, or have already found the clever solutions to the problem. I'm happy to learn more :-)
>
> Jari
>
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status