netdev - Re: [RFC 1/9] ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bf16f236-174e-7d1b-2b93-071552840995@6wind.com>
Date:   Thu, 1 Sep 2016 15:58:04 +0200
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     David Lebrun <david.lebrun@...ouvain.be>, netdev@...r.kernel.org,
        netfilter-devel <netfilter-devel@...r.kernel.org>
Subject: Re: [RFC 1/9] ipv6: implement dataplane support for rthdr type 4
 (Segment Routing Header)

Le 01/09/2016 à 15:11, David Lebrun a écrit :
> On 08/31/2016 04:51 PM, Nicolas Dichtel wrote:
[snip]
>>> +config IPV6_SEG6
>>> +	bool "IPv6: Segment Routing support"
>>> +	depends on IPV6
>>> +	---help---
>>> +	  Experimental support for IPv6 Segment Routing dataplane as defined
>>> +	  in IETF draft-ietf-6man-segment-routing-header-01. This option
>>> +	  enables the processing of SR-enabled packets allowing the kernel
>>> +	  to act as a segment endpoint (intermediate or egress).
>>> +
>>> +	  If unsure, say N.
>>> +
>> I don't think that the option is needed. At the end, every distributions will
>> turn it on.
>>
> 
> Are you sure ? This is a rather specific feature, used in specific
> environments. Not that I would mind removing the option if it makes sense.
Check default config file of a standard distributions (ubuntu, debian, ...), all
options are enabled (MIP6, SIT_6RD, PIMSM_v2, etc. ;-)).
Anyway, one option is enough. You add 3 or 4 options in your series.

[snip]

>>> +
>>> +	ip6_route_input(skb);
>> The destination address has now changed and the packet is routed again.
>> skb->nfct is not updated, it is intentional? I'm asking me if it's conceptually
>> right.
>>
> 
> I fail to see any usecase where conntrack would run on SR-enabled
> packets. Things such as NAT would just defeat the purpose.

I've added netfilter folks in CC, it would be good to have feedback from them.

For new people, here is the thread:
http://www.spinics.net/lists/netdev/msg392031.html


Regards,
Nicolas