| Message ID | 1559253021-16772-7-git-send-email-tom@quantonium.net |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | seg6: Segment routing fixes | expand |
On Thu, 30 May 2019 14:50:21 -0700 Tom Herbert <tom@herbertland.com> wrote: > Mutable fields related to segment routing are: destination address, > segments left, and modifiable TLVs (those whose high order bit is set). > > Add support to rearrange a segment routing (type 4) routing header to > handle these mutability requirements. This is described in > draft-herbert-ipv6-srh-ah-00. > Hi Tom, David, I think it is very early to have such implementation in the mainline of the Linux kernel. The draft (draft-herbert-ipv6-srh-ah-00) has been submitted to IETF draft couple of days ago. We should give the IETF community the time to review and reach a consensus on this draft. Thanks, Ahmed
On Fri, May 31, 2019 at 7:05 AM Ahmed Abdelsalam <ahabdels.dev@gmail.com> wrote: > > On Thu, 30 May 2019 14:50:21 -0700 > Tom Herbert <tom@herbertland.com> wrote: > > > Mutable fields related to segment routing are: destination address, > > segments left, and modifiable TLVs (those whose high order bit is set). > > > > Add support to rearrange a segment routing (type 4) routing header to > > handle these mutability requirements. This is described in > > draft-herbert-ipv6-srh-ah-00. > > > > Hi Tom, David, > I think it is very early to have such implementation in the mainline of the Linux kernel. > The draft (draft-herbert-ipv6-srh-ah-00) has been submitted to IETF draft couple of days ago. > We should give the IETF community the time to review and reach a consensus on this draft. Hi Ahmed, That draft is based on the mutability requirements specified in draft-ietf-6man-segment-routing-header-19. It was quite an arduous battle even to get them to nail down any requirements about what bits the network is allowed to change (and even though the that draft is in WGLC, they _still_ are making changes in the area). IMO, the AH requirements should be part of the SRH specification as it is with any other extension headers, but the WG chairs decided to defer that to other docs and that is their prerogative-- hence my draft in response which is simple and straightforward. Regardless of the history and current state though, the current implementation allows both AH and SRH to be configured simultaneously. This won't work. If a user does this they may be in a world of hurt because the effects may be non deterministic. For instance, some packets for a flow might take a route that uses SRH, and some may not, so some packets get through and others don't-- that's going to be hard to debug. IMO, we shouldn't wait for IETF to get their act together on this which in their time frame can be years. We should take action to address an identified issue that could adversely impact users. If implementing this method isn't the right direction, please suggest an alternative. Thanks, Tom > Thanks, > Ahmed > > -- > Ahmed Abdelsalam <ahabdels.dev@gmail.com>
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c index 032491c..0c5ca29 100644 --- a/net/ipv6/ah6.c +++ b/net/ipv6/ah6.c @@ -27,6 +27,7 @@ #include <net/icmp.h> #include <net/ipv6.h> #include <net/protocol.h> +#include <net/seg6.h> #include <net/xfrm.h> #define IPV6HDR_BASELEN 8 @@ -141,6 +142,13 @@ static bool zero_out_mutable_opts(struct ipv6_opt_hdr *opthdr) return __zero_out_mutable_opts(opthdr, 2, 0x20, IPV6_TLV_PAD1); } +static bool zero_out_mutable_srh_opts(struct ipv6_sr_hdr *srh) +{ + return __zero_out_mutable_opts((struct ipv6_opt_hdr *)srh, + seg6_tlv_offset(srh), 0x80, + SR6_TLV_PAD1); +} + #if IS_ENABLED(CONFIG_IPV6_MIP6) /** * ipv6_rearrange_destopt - rearrange IPv6 destination options header @@ -243,6 +251,20 @@ static bool ipv6_rearrange_type0_rthdr(struct ipv6hdr *iph, return true; } +static bool ipv6_rearrange_type4_rthdr(struct ipv6hdr *iph, + struct ipv6_rt_hdr *rthdr) +{ + struct ipv6_sr_hdr *srh = (struct ipv6_sr_hdr *)rthdr; + + if (!zero_out_mutable_srh_opts(srh)) + return false; + + rthdr->segments_left = 0; + iph->daddr = srh->segments[0]; + + return true; +} + static bool ipv6_rearrange_rthdr(struct ipv6hdr *iph, struct ipv6_rt_hdr *rthdr) { switch (rthdr->type) { @@ -251,6 +273,8 @@ static bool ipv6_rearrange_rthdr(struct ipv6hdr *iph, struct ipv6_rt_hdr *rthdr) /* fallthrough */ case IPV6_SRCRT_TYPE_0: /* Deprecated */ return ipv6_rearrange_type0_rthdr(iph, rthdr); + case IPV6_SRCRT_TYPE_4: + return ipv6_rearrange_type4_rthdr(iph, rthdr); default: /* Bad or unidentified routing header, we don't know how * to fix this header for security purposes. Return failure.
Mutable fields related to segment routing are: destination address, segments left, and modifiable TLVs (those whose high order bit is set). Add support to rearrange a segment routing (type 4) routing header to handle these mutability requirements. This is described in draft-herbert-ipv6-srh-ah-00. Signed-off-by: Tom Herbert <tom@quantonium.net> --- net/ipv6/ah6.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)