On Thu, 23 Aug 2018 20:11:47 +0200
Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > +static struct xt_target seg6_tg6_reg __read_mostly = {
> > + .name = "SEG6",
> > + .family = NFPROTO_IPV6,
> > + .target = seg6_tg6,
> > + .targetsize = sizeof(struct ip6t_seg6_info),
>
> There is no .hook_mask here, can you really use this target from any
> netfilter hook?
>
> This is also mangling the IPv6 dst field, which breaks ongoing
> conntracking/NAT, so I suspect at least you need to restrict this to
> PREROUTING/raw table? Or this explicit needs a rule with -j NOTRACK?
> Probably this extension would fit better in the ingress hook?
>
> If you could post realistic example ruleset that would help understand
> how you plan to use this, or even configuration example where this
> extension is used. Interaction of this module with other existing
> netfilter extensions is broken, I'd appreciate an explanation.
>
> Thanks.
Hi Pablo,
Let me elaborate more here and then I’ll answer the questions.
Classification , Reclassification, and Branching are Core SFC Architecture Components, which is defined in RFC 7665 [1].
Initial classification occurs at the ingress to the SFC domain. The granularity of the initial classification is determined by the capabilities of the classifier.
For instance, classification might be relatively coarse: all packets from this port are subject to SFC policy X , or quite granular: all packets matching this 5-tuple are subject to SFC policy Y.
In case of IPv6 Segment Routing, the Linux kernel currently adding SRv6 SFC policies based on the destination address of packets.
These policies are configured using iproute2 as follows [2]:
ip -6 route add <prefix> encap seg6 mode <encapmode> segs <segments> [hmac <keyid>] dev <device>
However, In most of the cases, the SFC policies should be based on the traffic source which represent the per-customer policy.
This can be achieved using some ip rules as follows which is also presented in the demo shown in [3]
echo “101 customer1” >> /etc/iproute2/rt_tables
ip -6 rule add from <cutomer1_prefix> lookup customer1
or
ip -6 rule add iif <cutomer1_iface> lookup customer1
ip -6 route add <dst_prefix> encap seg6 mode <encapmode> segs <<segments> [hmac <keyid>] dev <device> table customer1
The SFC architecture should support reclassification (or non-initial classification) as well. As packets traverse an SFP, reclassification may occur -- typically performed by a classification function co-resident with a service function.
Reclassification may result in the selection of a new SFP, which is referred to as "branching".
The need for reclassification came from the fact that SFC policies were applied based on layer3 information, while some traffic patterns can only be detected at the application layer and/or some sophisticated firewall rules.
Iptables as Service Function that could be part of an IPv6 SFC chain should be able to support such branching. Here comes the need for such SEG6 target actions. each of these actions can address a some different use-cases as follows:
(1) go-next
consider a use-case where the customer policy requires traffic to be processed by two different firewalls (FW_1 and FW_2) that provides different security levels, as well as QoS treatment service (Q1) that shape the packets received at x Mbps). However, a subset of the traffic (e.g., voice traffic using RTP protocol to avoid delay) doesn’t need to go through all complex rules configured at FW_2. This can be achieved by having the following rule in the second firewall (FW_2)
ip6tables -I INPUT -p udp --dport <rtp_port_range> -m srh --srh-psid <FW_1> -j SEG6 —seg6-action go-next
(2) skip-next
The same use-case described in (1) can be done from FW_1 as follows:
ip6tables -I INPUT -p udp --dport <rtp_port_range> -m srh --srh-nsid <FW_2> -j SEG6 —seg6-action skip-next
(3) go-last
Network can be under congestion which means the Firewalls are totally overloaded, in such a case you might decide to totally skip SFC (for a subset of the traffic) by going to the last Service function in the chain
ip6tables -I INPUT -p udp --dport <portx> -j SEG6 —seg6-action go-last
(4) bind-sid
The firewall might decide to apply DPI for some suspicious traffic which requires adding a new service to the chain
ip6tables -I INPUT -p <protocol> --dport <portx> -j SEG6 —seg6-action bind-sid —sid BD::1
ip -6 route add BD::1 encap seg6 mode <encapmode> segs <<segments> [hmac <keyid>] dev <device>
As for the question:
- .hook_mask is required and as you can see should be the INPUT because the iptbables as a service function should be the packet destination. However the bind-action can be useful to be supported also in ingress/prerouting hook which allows to define more fine grained SRv6 polices
- Regarding the problem with NAT, According to SFC RFC service functions (e.g., NAT ) should be SFC encapsulation aware which means be able to recognise the SFC encapsulation. So the NATing should be done based on dst addr of the real packet not the SFC encapsulation. For the SFC-unware SFs there should be at least a proxy which handles SFC-encapsulated packets before being handed to unaware SFs. A list of SRv6 proxy behaviours are defined in [4] and some of them are implemented in [5].
Thanks,
Ahmed
[1] https://tools.ietf.org/html/rfc7665
[2] https://segment-routing.org/index.php/Implementation/Configuration
[3] https://github.com/SRouting/SR-sfc-demo
[4] https://tools.ietf.org/html/draft-xuclad-spring-sr-service-programming-00
[5] https://github.com/SRouting/SRv6-net-prog
--
Ahmed Abdelsalam <amsalam20@xxxxxxxxx>
