From: Andreas Roeseler <hidden> Date: 2021-03-30 01:45:54
The popular utility ping has several severe limitations, such as the
inability to query specific interfaces on a node and requiring
bidirectional connectivity between the probing and probed interfaces.
RFC 8335 attempts to solve these limitations by creating the new utility
PROBE which is a specialized ICMP message that makes use of the ICMP
Extension Structure outlined in RFC 4884.
This patchset adds definitions for the ICMP Extended Echo Request and
Reply (PROBE) types for both IPV4 and IPV6, adds a sysctl to enable
responses to PROBE messages, expands the list of supported ICMP messages
to accommodate PROBE types, adds ipv6_dev_find into ipv6_stubs, and adds
functionality to respond to PROBE requests.
Changes:
v1 -> v2:
- Add AFI definitions
- Switch to functions such as dev_get_by_name and ip_dev_find to lookup
net devices
v2 -> v3:
Suggested by Willem de Bruijn [off-list ref]
- Add verification of incoming messages before looking up netdev
- Add prefix for PROBE specific defined variables
- Use proc_dointvec_minmax with zero and one for sysctl
- Create struct icmp_ext_echo_iio for parsing incoming packets
Reported-by: kernel test robot <redacted>
Reported-by: Dan Carpenter <redacted>
- Include net/addrconf.h library for ipv6_dev_find
v3 -> v4:
- Use in_addr instead of __be32 for storing IPV4 addresses
- Use IFNAMSIZ to statically allocate space for name in
icmp_ext_echo_iio
Suggested by Willem de Bruijn [off-list ref]
- Use skb_header_pointer to verify fields in incoming message
- Add check to ensure that extobj_hdr.length is valid
- Check to ensure object payload is padded with ASCII NULL characters
when probing by name, as specified by RFC 8335
- Statically allocate buff using IFNAMSIZ
- Add rcu blocking around ipv6_dev_find
- Use __in_dev_get_rcu to access IPV4 addresses of identified
net_device
- Remove check for ICMPV6 PROBE types
v4 -> v5:
- Statically allocate buff to size IFNAMSIZ on declaration
- Remove goto probe in favor of single branch
- Remove strict check for incoming PROBE request padding to nearest
32-bit boundary
Reported-by: kernel test robot <redacted>
v5 -> v6:
- Add documentation for icmp_echo_enable_probe sysctl
- Remove RCU locking around ipv6_dev_find()
- Assign iio based on ctype
Andreas Roeseler (6):
icmp: add support for RFC 8335 PROBE
ICMPV6: add support for RFC 8335 PROBE
net: add sysctl for enabling RFC 8335 PROBE messages
net: add support for sending RFC 8335 PROBE messages
ipv6: add ipv6_dev_find to stubs
icmp: add response to RFC 8335 PROBE messages
Documentation/networking/ip-sysctl.rst | 6 ++
include/net/ipv6_stubs.h | 2 +
include/net/netns/ipv4.h | 1 +
include/uapi/linux/icmp.h | 42 ++++++++
include/uapi/linux/icmpv6.h | 3 +
net/ipv4/icmp.c | 134 ++++++++++++++++++++++---
net/ipv4/ping.c | 4 +-
net/ipv4/sysctl_net_ipv4.c | 9 ++
net/ipv6/addrconf_core.c | 7 ++
net/ipv6/af_inet6.c | 1 +
10 files changed, 195 insertions(+), 14 deletions(-)
--
2.17.1
From: Andreas Roeseler <hidden> Date: 2021-03-30 01:45:54
Add definitions for PROBE ICMP types and codes.
Add AFI definitions for IP and IPV6 as specified by IANA
Add a struct to represent the additional header when probing by IP
address (ctype == 3) for use in parsing incoming PROBE messages
Add a struct to represent the entire Interface Identification Object
(IIO) section of an incoming PROBE packet
Signed-off-by: Andreas Roeseler <redacted>
---
Changes:
v1 -> v2:
- Add AFI_IP and AFI_IP6 definitions
v2 -> v3:
Suggested by Willem de Bruijn [off-list ref]
- Add prefix for PROBE specific defined variables
- Create struct icmp_ext_echo_iio for parsing incoming packet
v3 -> v4:
- Use in_addr instead of __be32 for storing IPV4 addresses
- Use IFNAMSIZ to statically allocate space for name in
icmp_ext_echo_iio
v4 -> v5:
- Use __be32 instead of __u32 in defined structs
---
include/uapi/linux/icmp.h | 42 +++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
From: Andreas Roeseler <hidden> Date: 2021-03-30 01:46:25
Add definitions for the ICMPV6 type of Extended Echo Request and
Extended Echo Reply, as defined by sections 2 and 3 of RFC 8335.
Signed-off-by: Andreas Roeseler <redacted>
---
include/uapi/linux/icmpv6.h | 3 +++
1 file changed, 3 insertions(+)
From: Andreas Roeseler <hidden> Date: 2021-03-30 01:46:26
Section 8 of RFC 8335 specifies potential security concerns of
responding to PROBE requests, and states that nodes that support PROBE
functionality MUST be able to enable/disable responses and that
responses MUST be disabled by default
Signed-off-by: Andreas Roeseler <redacted>
---
Changes:
v1 -> v2:
- Combine patches related to sysctl
v2 -> v3:
Suggested by Willem de Bruijn [off-list ref]
- Use proc_dointvec_minmax with zero and one
v5 -> v6:
- Add documentation to ip-sysctl.rst
---
Documentation/networking/ip-sysctl.rst | 6 ++++++
include/net/netns/ipv4.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 9 +++++++++
3 files changed, 16 insertions(+)
@@ -1143,6 +1143,12 @@ icmp_echo_ignore_all - BOOLEAN Default: 0+icmp_echo_enable_probe - BOOLEAN+ If set to one, then the kernel will respond to RFC 8335 PROBE+ requests sent to it.++ Default: 0+ icmp_echo_ignore_broadcasts - BOOLEAN If set non-zero, then the kernel will ignore all ICMP ECHO and TIMESTAMP requests sent to it via broadcast/multicast.
From: Andreas Roeseler <hidden> Date: 2021-03-30 01:46:26
Modify the ping_supported function to support PROBE message types. This
allows tools such as the ping command in the iputils package to be
modified to send PROBE requests through the existing framework for
sending ping requests.
Signed-off-by: Andreas Roeseler <redacted>
---
net/ipv4/ping.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Andreas Roeseler <hidden> Date: 2021-03-30 01:46:57
Modify the icmp_rcv function to check PROBE messages and call icmp_echo
if a PROBE request is detected.
Modify the existing icmp_echo function to respond ot both ping and PROBE
requests.
This was tested using a custom modification to the iputils package and
wireshark. It supports IPV4 probing by name, ifindex, and probing by
both IPV4 and IPV6 addresses. It currently does not support responding
to probes off the proxy node (see RFC 8335 Section 2).
The modification to the iputils package is still in development and can
be found here: https://github.com/Juniper-Clinic-2020/iputils.git. It
supports full sending functionality of PROBE requests, but currently
does not parse the response messages, which is why Wireshark is required
to verify the sent and recieved PROBE messages. The modification adds
the ``-e'' flag to the command which allows the user to specify the
interface identifier to query the probed host. An example usage would be
<./ping -4 -e 1 [destination]> to send a PROBE request of ifindex 1 to the
destination node.
Signed-off-by: Andreas Roeseler <redacted>
---
Changes:
v1 -> v2:
- Reorder variable declarations to follow coding style
- Switch to functions such as dev_get_by_name and ip_dev_find to lookup
net devices
v2 -> v3:
Suggested by Willem de Bruijn [off-list ref]
- Add verification of incoming messages before looking up netdev
Reported-by: kernel test robot <redacted>
Reported-by: Dan Carpenter <redacted>
- Include net/addrconf.h library for ipv6_dev_find
v3 -> v4:
Suggested by Willem de Bruijn [off-list ref]
- Use skb_header_pointer to verify fields in incoming message
- Add check to ensure that extobj_hdr.length is valid
- Check to ensure object payload is padded with ASCII NULL characters
when probing by name, as specified by RFC 8335
- Statically allocate buff using IFNAMSIZ
- Add rcu blocking around ipv6_dev_find
- Use __in_dev_get_rcu to access IPV4 addresses of identified
net_device
- Remove check for ICMPV6 PROBE types
v4 -> v5:
- Statically allocate buff to size IFNAMSIZ on declaration
- Remove goto probe in favor of single branch
- Remove strict check for incoming PROBE requests padding to nearest
32-bit boundary
Reported-by: kernel test robot <redacted>
- Use rcu_dereference when accessing i6_ptr in net_device
v5 -> v6:
- Remove RCU locking around ipv6_dev_find()
- Assign iio based on length specified by ctype
---
net/ipv4/icmp.c | 134 +++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 121 insertions(+), 13 deletions(-)
@@ -979,27 +979,125 @@ static bool icmp_redirect(struct sk_buff *skb)*includedinthereply.*RFC1812:4.3.3.6SHOULDhaveaconfigoptionforsilentlyignoring*echorequests,MUSThavedefault=NOT.+*RFC8335:8MUSThaveaconfigoptiontoenable/disableICMP+*ExtendedEchoFunctionality,MUSTbedisabledbydefault*SeealsoWRThandlingofoptionsoncetheyaredoneandworking.*/staticboolicmp_echo(structsk_buff*skb){+structicmp_ext_hdr*ext_hdr,_ext_hdr;+structicmp_ext_echo_iio*iio,_iio;+structicmp_bxmicmp_param;+structnet_device*dev;+charbuff[IFNAMSIZ];structnet*net;+u16ident_len;+u8status;net=dev_net(skb_dst(skb)->dev);-if(!net->ipv4.sysctl_icmp_echo_ignore_all){-structicmp_bxmicmp_param;+/* should there be an ICMP stat for ignored echos? */+if(net->ipv4.sysctl_icmp_echo_ignore_all)+returntrue;++icmp_param.data.icmph=*icmp_hdr(skb);+icmp_param.skb=skb;+icmp_param.offset=0;+icmp_param.data_len=skb->len;+icmp_param.head_len=sizeof(structicmphdr);-icmp_param.data.icmph=*icmp_hdr(skb);+if(icmp_param.data.icmph.type==ICMP_ECHO){icmp_param.data.icmph.type=ICMP_ECHOREPLY;-icmp_param.skb=skb;-icmp_param.offset=0;-icmp_param.data_len=skb->len;-icmp_param.head_len=sizeof(structicmphdr);-icmp_reply(&icmp_param,skb);+gotosend_reply;}-/* should there be an ICMP stat for ignored echos? */-returntrue;+if(!net->ipv4.sysctl_icmp_echo_enable_probe)+returntrue;+/* We currently only support probing interfaces on the proxy node+*ChecktoensureL-bitisset+*/+if(!(ntohs(icmp_param.data.icmph.un.echo.sequence)&1))+returntrue;+/* Clear status bits in reply message */+icmp_param.data.icmph.un.echo.sequence&=htons(0xFF00);+icmp_param.data.icmph.type=ICMP_EXT_ECHOREPLY;+ext_hdr=skb_header_pointer(skb,0,sizeof(_ext_hdr),&_ext_hdr);+/* Size of iio is class_type dependent.+*Onlycheckheaderhereandassignlengthbasedonctypeintheswitchstatement+*/+iio=skb_header_pointer(skb,sizeof(_ext_hdr),sizeof(iio->extobj_hdr),&_iio);+if(!ext_hdr||!iio)+gotosend_mal_query;+if(ntohs(iio->extobj_hdr.length)<=sizeof(iio->extobj_hdr))+gotosend_mal_query;+ident_len=ntohs(iio->extobj_hdr.length)-sizeof(iio->extobj_hdr);+status=0;+dev=NULL;+switch(iio->extobj_hdr.class_type){+caseEXT_ECHO_CTYPE_NAME:+iio=skb_header_pointer(skb,sizeof(_ext_hdr),sizeof(_iio),&_iio);+if(ident_len>=IFNAMSIZ)+gotosend_mal_query;+memset(buff,0,sizeof(buff));+memcpy(buff,&iio->ident.name,ident_len);+dev=dev_get_by_name(net,buff);+break;+caseEXT_ECHO_CTYPE_INDEX:+iio=skb_header_pointer(skb,sizeof(_ext_hdr),sizeof(iio->extobj_hdr)++sizeof(iio->ident.ifindex),&_iio);+if(ident_len!=sizeof(iio->ident.ifindex))+gotosend_mal_query;+dev=dev_get_by_index(net,ntohl(iio->ident.ifindex));+break;+caseEXT_ECHO_CTYPE_ADDR:+if(ident_len!=sizeof(iio->ident.addr.ctype3_hdr)++iio->ident.addr.ctype3_hdr.addrlen)+gotosend_mal_query;+switch(ntohs(iio->ident.addr.ctype3_hdr.afi)){+caseICMP_AFI_IP:+iio=skb_header_pointer(skb,sizeof(_ext_hdr),sizeof(iio->extobj_hdr)++sizeof(structin_addr),&_iio);+if(ident_len!=sizeof(iio->ident.addr.ctype3_hdr)++sizeof(structin_addr))+gotosend_mal_query;+dev=ip_dev_find(net,iio->ident.addr.ip_addr.ipv4_addr.s_addr);+break;+#if IS_ENABLED(CONFIG_IPV6)+caseICMP_AFI_IP6:+iio=skb_header_pointer(skb,sizeof(_ext_hdr),sizeof(_iio),&_iio);+if(ident_len!=sizeof(iio->ident.addr.ctype3_hdr)++sizeof(structin6_addr))+gotosend_mal_query;+dev=ipv6_stub->ipv6_dev_find(net,&iio->ident.addr.ip_addr.ipv6_addr,dev);+if(dev)+dev_hold(dev);+break;+#endif+default:+gotosend_mal_query;+}+break;+default:+gotosend_mal_query;+}+if(!dev){+icmp_param.data.icmph.code=ICMP_EXT_NO_IF;+gotosend_reply;+}+/* Fill bits in reply message */+if(dev->flags&IFF_UP)+status|=EXT_ECHOREPLY_ACTIVE;+if(__in_dev_get_rcu(dev)&&__in_dev_get_rcu(dev)->ifa_list)+status|=EXT_ECHOREPLY_IPV4;+if(!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))+status|=EXT_ECHOREPLY_IPV6;+dev_put(dev);+icmp_param.data.icmph.un.echo.sequence|=htons(status);+send_reply:+icmp_reply(&icmp_param,skb);+returntrue;+send_mal_query:+icmp_param.data.icmph.code=ICMP_EXT_MAL_QUERY;+gotosend_reply;}/*
@@ -1088,6 +1186,16 @@ int icmp_rcv(struct sk_buff *skb)icmph=icmp_hdr(skb);ICMPMSGIN_INC_STATS(net,icmph->type);++/* Check for ICMP Extended Echo (PROBE) messages */+if(icmph->type==ICMP_EXT_ECHO){+/* We can't use icmp_pointers[].handler() because it is an array of+*sizeNR_ICMP_TYPES+1(19elements)andPROBEhascode42.+*/+success=icmp_echo(skb);+gotosuccess_check;+}+/**18isthehighest'known'ICMPtype.Anythingelseisamystery*
@@ -1097,7 +1205,6 @@ int icmp_rcv(struct sk_buff *skb)if(icmph->type>NR_ICMP_TYPES)gotoerror;-/**ParsetheICMPmessage*/
@@ -1123,7 +1230,7 @@ int icmp_rcv(struct sk_buff *skb)}success=icmp_pointers[icmph->type].handler(skb);-+success_check:if(success){consume_skb(skb);returnNET_RX_SUCCESS;
@@ -1340,6 +1447,7 @@ static int __net_init icmp_sk_init(struct net *net)/* Control parameters for ECHO replies. */net->ipv4.sysctl_icmp_echo_ignore_all=0;+net->ipv4.sysctl_icmp_echo_enable_probe=0;net->ipv4.sysctl_icmp_echo_ignore_broadcasts=1;/* Control parameter - ignore bogus broadcast responses? */
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Mon, 29 Mar 2021 18:45:04 -0700 you wrote:
The popular utility ping has several severe limitations, such as the
inability to query specific interfaces on a node and requiring
bidirectional connectivity between the probing and probed interfaces.
RFC 8335 attempts to solve these limitations by creating the new utility
PROBE which is a specialized ICMP message that makes use of the ICMP
Extension Structure outlined in RFC 4884.
[...]
We have received a report that this breaks compiliation of trinity
because it includes <netinet/in.h> and <linux/icmp.h> at the same time,
and there is no multiple-definition guard for struct in_addr and other
definitions:
In file included from include/net.h:5,
from net/proto-ip-raw.c:2:
/usr/include/netinet/in.h:31:8: error: redefinition of ‘struct in_addr’
31 | struct in_addr
| ^~~~~~~
In file included from /usr/include/linux/icmp.h:23,
from net/proto-ip-raw.c:1:
/usr/include/linux/in.h:89:8: note: originally defined here
89 | struct in_addr {
| ^~~~~~~
In file included from /usr/include/netinet/in.h:37,
from include/net.h:5,
from net/proto-ip-raw.c:2:
/usr/include/bits/in.h:150:8: error: redefinition of ‘struct ip_mreqn’
150 | struct ip_mreqn
| ^~~~~~~~
In file included from /usr/include/linux/icmp.h:23,
from net/proto-ip-raw.c:1:
/usr/include/linux/in.h:178:8: note: originally defined here
178 | struct ip_mreqn {
| ^~~~~~~~
(More conflicts appear to follow.)
I do not know what the correct way forward is. Adding the
multiple-definition guards is quite a bit of work and requires updates
in glibc and the kernel to work properly.
Thanks,
Florian
We have received a report that this breaks compiliation of trinity
because it includes <netinet/in.h> and <linux/icmp.h> at the same
time,
and there is no multiple-definition guard for struct in_addr and
other
definitions:
In file included from include/net.h:5,
from net/proto-ip-raw.c:2:
/usr/include/netinet/in.h:31:8: error: redefinition of ‘struct
in_addr’
31 | struct in_addr
| ^~~~~~~
In file included from /usr/include/linux/icmp.h:23,
from net/proto-ip-raw.c:1:
/usr/include/linux/in.h:89:8: note: originally defined here
89 | struct in_addr {
| ^~~~~~~
In file included from /usr/include/netinet/in.h:37,
from include/net.h:5,
from net/proto-ip-raw.c:2:
/usr/include/bits/in.h:150:8: error: redefinition of ‘struct
ip_mreqn’
150 | struct ip_mreqn
| ^~~~~~~~
In file included from /usr/include/linux/icmp.h:23,
from net/proto-ip-raw.c:1:
/usr/include/linux/in.h:178:8: note: originally defined here
178 | struct ip_mreqn {
| ^~~~~~~~
(More conflicts appear to follow.)
I do not know what the correct way forward is. Adding the
multiple-definition guards is quite a bit of work and requires
updates
in glibc and the kernel to work properly.
Thanks,
Florian
Are <netinet/in.h> and <linux/in.h> the only conflicting files?
<linux/in.h> is only included to gain use of the in_addr struct, but
that can be easily substituted out of the code in favor of __be32.
Therefore we would no longer need to include <linux/in.h> and would
remove the conflict.
Are <netinet/in.h> and <linux/in.h> the only conflicting files?
<linux/in.h> is only included to gain use of the in_addr struct, but
that can be easily substituted out of the code in favor of __be32.
Therefore we would no longer need to include <linux/in.h> and would
remove the conflict.
I'm not 100% sure, but it looks this way. I can include <netinet/in.h>
and both <linux/in6.h> and <linux/if.h> in the same translation unit.
Thanks,
Florian