Fragment questions
Hello, I noticed two questionable things in the fragmentation code: - in ip_fragment, we do not copy the flowid from the original mbuf to the fragmented mbuf. Therefore we may output very desynchronized fragments (first fragment emitted far later the second fragment, etc.) - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use randomized id. In multi core systems, we may emit successive packets with the same id. Both problems combined lead to bad packet reassembly on the remote host. What do you think? Emeric ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Fragment questions
Hello, Yes indeed, it has already been fixed! However, the second point seems to be still here... Regards, Emeric - Mail original - De: "Hans Petter Selasky" À: "Emeric POUPON" , "freebsd-net" Envoyé: Jeudi 19 Mars 2015 13:54:33 Objet: Re: Fragment questions On 03/19/15 12:38, Emeric POUPON wrote: > Hello, > > I noticed two questionable things in the fragmentation code: > - in ip_fragment, we do not copy the flowid from the original mbuf to the > fragmented mbuf. Therefore we may output very desynchronized fragments (first > fragment emitted far later the second fragment, etc.) > - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use > randomized id. In multi core systems, we may emit successive packets with the > same id. > > Both problems combined lead to bad packet reassembly on the remote host. > > What do you think? > Hi, I think this issue is already fixed: https://svnweb.freebsd.org/base/head/sys/netinet/ip_output.c?revision=278103&view=markup --HPS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Fragment questions
Hello,
Please find attached a proposal using atomic_fetchadd.
Best Regards,
Emeric
- Mail original -
De: "Adrian Chadd"
À: "Hans Petter Selasky"
Cc: "Emeric POUPON" , "freebsd-net"
Envoyé: Vendredi 20 Mars 2015 20:04:44
Objet: Re: Fragment questions
On 20 March 2015 at 11:56, Hans Petter Selasky wrote:
> On 03/20/15 19:02, Adrian Chadd wrote:
>>
>> On 20 March 2015 at 10:58, Hans Petter Selasky wrote:
>>>
>>> On 03/20/15 14:31, Emeric POUPON wrote:
>>>>
>>>>
>>>> - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use
>>>> randomized id.
>>>
>>>
>>>> In multi core systems, we may emit successive packets with the same id.
>>>
>>>
>>> Will using a mutex or an atomic macro fix this issue when incrementing
>>> the
>>> V_ip_id ?
>>
>>
>> It will, but it'll ping-pong between multiple cores and slow things
>> down at high pps.
>>
>
> Hi,
>
> Maybe we can have the V_ip_id per CPU and use the lower 8-bits as random CPU
> core number?
Hm, someone with more cycles to spend on analysing the repercussions
from this should investigate it.
I think in the short term using an atomic is fine, as it's no worse
than what is currently there. But as we get more PPS unlocked and
happening we may need to fix it.
-adrian
--- sys/netinet/ip_var.h.orig 2015-03-23 17:57:40.601072200 +0100
+++ sys/netinet/ip_var.h 2015-03-23 17:58:31.093715177 +0100
@@ -174,7 +174,7 @@ struct inpcb;
struct route;
struct sockopt;
-VNET_DECLARE(u_short, ip_id); /* ip packet ctr, for ids */
+VNET_DECLARE(u_int32_t, ip_id); /* ip packet ctr, for ids */
VNET_DECLARE(int, ip_defttl); /* default IP ttl */
VNET_DECLARE(int, ipforwarding); /* ip forwarding */
#ifdef IPSTEALTH
@@ -306,7 +306,7 @@ extern int (*ip_dn_io_ptr)(struct mbuf *
VNET_DECLARE(int, ip_do_randomid);
#define V_ip_do_randomid VNET(ip_do_randomid)
#define ip_newid() ((V_ip_do_randomid != 0) ? ip_randomid() : \
- htons(V_ip_id++))
+ htons(atomic_fetchadd_32(&V_ip_id, 1) & 0x))
#endif /* _KERNEL */
--- sys/netinet/ip_output.c.orig 2015-03-23 17:57:46.514498846 +0100
+++ sys/netinet/ip_output.c 2015-03-23 17:58:52.124426760 +0100
@@ -91,7 +91,7 @@ __FBSDID("$FreeBSD: head/sys/netinet/ip_
#include
-VNET_DEFINE(u_short, ip_id);
+VNET_DEFINE(u_int32_t, ip_id);
#ifdef MBUF_STRESS_TEST
static int mbuf_frag_size = 0;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Fragment questions
Ok for the function. Please find the review here: https://reviews.freebsd.org/D2141 Regards, Emeric - Mail original - De: "Hans Petter Selasky" À: "Emeric POUPON" , "Adrian Chadd" Cc: "freebsd-net" Envoyé: Mercredi 25 Mars 2015 14:41:46 Objet: Re: Fragment questions On 03/24/15 10:26, Emeric POUPON wrote: > Hello, > > Please find attached a proposal using atomic_fetchadd. > > Best Regards, > > Emeric Hi, Your proposal using atomic_fetchadd() looks fine to me. I think however we should define the code like a function, because the htons() might be a macro, referring the input argument multiple times ... What do you think? --HPS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Patch to reduce use of global IP ID value(s) to avoid leaking information
> I'm talking about sampling the IP ID value you get in return from a PING > response. A firewall typically has multiple ports. If pinging the > gateway from any of these ports cause an increment of a shared IP ID > value, then anyone that can ping the common firewall will see the IP ID > updates the other parties are doing. > > --HPS Hello, I known this is not exactly the "attack" you described (RX/TX communication using IP ID), but our random implementation of IP ID does not completely prevents somebody from guessing the traffic made by the gateway. By default we use a parameter (N=8192) in order not to reuse a given amount of previously used IP IDs. If you ping the gateway and if there is no traffic, you are sure not to get the N previously received IP ID. This is a kind of hint of the load of the gateway. Emeric ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Multicast routing questions
Hello, I'm testing multicast routing on FreeBSD 9.3 and I have a question: In packet reception, it seems the packet is received locally as many times the packet is rerouted + 1: ip_input -> ip_mforward -> ip_output (as many times there are dst interfaces in the route cache entry) -> ip_mloopback -> if_simloop (rcvif becomes the ifp of the output interface) -> ip_input -> ip_mforward -> ... In ip_input, after each ip_mforward call, the packet is processed locally (using the goto "ours:") Futhermore it seems this infinite loop is actually broken thanks to a test in ip_mforward that checks the ifp is the same as the registered one in the cache entry. Maybe I missed something, but it does not seem to be working as expected. What do you think? Emeric ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Multicast routing questions
Hi, Actually, I don't really understand why imo.imo_multicast_loop is set to 1 in send_packet, ip_mroute.c It seems we don't need to loop the packet once it is mrouted? If the packet is emitted locally, the imo_multicast_loop set by the socket option makes the packet loop back if necessary. Emeric - Mail original - De: "Emeric POUPON" À: freebsd-net@freebsd.org Envoyé: Mercredi 24 Juin 2015 10:22:45 Objet: Multicast routing questions Hello, I'm testing multicast routing on FreeBSD 9.3 and I have a question: In packet reception, it seems the packet is received locally as many times the packet is rerouted + 1: ip_input -> ip_mforward -> ip_output (as many times there are dst interfaces in the route cache entry) -> ip_mloopback -> if_simloop (rcvif becomes the ifp of the output interface) -> ip_input -> ip_mforward -> ... In ip_input, after each ip_mforward call, the packet is processed locally (using the goto "ours:") Futhermore it seems this infinite loop is actually broken thanks to a test in ip_mforward that checks the ifp is the same as the registered one in the cache entry. Maybe I missed something, but it does not seem to be working as expected. What do you think? Emeric ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Multicast routing questions
Ok thanks, I understand this case. But the problem is that we perform a lot of unnecessary mforward calls from ip_input. The mrt route cache lookup is performed thanks to the src/dst addresse couple. The interface of the cached route does not match the current interface and that is what prevents "infinite" loops. Is that really how it is meant to be done? Emeric - Mail original - De: "Andrey V. Elsukov" À: "Emeric POUPON" , freebsd-net@freebsd.org Envoyé: Jeudi 25 Juin 2015 07:48:44 Objet: Re: Multicast routing questions On 24.06.2015 18:13, Emeric POUPON wrote: > Hi, > > Actually, I don't really understand why imo.imo_multicast_loop is set > to 1 in send_packet, ip_mroute.c > > It seems we don't need to loop the packet once it is mrouted? I think this can be used for the case, when on the router some app has been joined to multicast group on the specific interface used as outgoing in send_packet. -- WBR, Andrey V. Elsukov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPsec: question on the sysctl preferred_oldsa
Hello, I have some questions about the sysctl "net.key.preferred_oldsa": https://svnweb.freebsd.org/base/head/sys/netipsec/key.c?view=markup#l971 When I set the net.key.preferred_oldsa to 0 (similar to Linux's behavior, according to what I have read so far): - why does the kernel delete itself the old SA ? Why not just selecting the newest one? - why does it delete the old SA only if it has been created in another "second" of time? strongSwan does not expect that behavior and I can see a lot of errors in its logs: the SA has been deleted but it does not know about that (strongSwan wants to control the SA installation/deletion itself). Two pairs of SA may be negotiated and installed at the same time due to high load, bidirectional traffic. It seems to be quite questionable to delete the old one in that case. What do you think? Emeric ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPsec: question on the sysctl preferred_oldsa
Hello, No idea on this question? To sum up the potential problems: - strongSwan does not expect the kernel to destroy a SA, and produces errors after that (it cannot find the expected SA in the kernel since it has been deleted) - racoon uses the "delete" event from the kernel and creates a ISAKMP DELETE message to the remote host, with the relevant SPI. In some situations, both endpoints negotiate a pair of SA at the same time, and keep deleting their old SA and renegotiate. I suspect this behavior to be related to this sysctl. What do you think? Emeric - Mail original - De: "Emeric POUPON" À: "FreeBSD Net" Envoyé: Lundi 17 Août 2015 10:07:45 Objet: IPsec: question on the sysctl preferred_oldsa Hello, I have some questions about the sysctl "net.key.preferred_oldsa": https://svnweb.freebsd.org/base/head/sys/netipsec/key.c?view=markup#l971 When I set the net.key.preferred_oldsa to 0 (similar to Linux's behavior, according to what I have read so far): - why does the kernel delete itself the old SA ? Why not just selecting the newest one? - why does it delete the old SA only if it has been created in another "second" of time? strongSwan does not expect that behavior and I can see a lot of errors in its logs: the SA has been deleted but it does not know about that (strongSwan wants to control the SA installation/deletion itself). Two pairs of SA may be negotiated and installed at the same time due to high load, bidirectional traffic. It seems to be quite questionable to delete the old one in that case. What do you think? Emeric ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPSec and large replay window support
Hello,
We plan to support large replay windows in the IPsec stack.
Currently, the replay window size is limited due to the size of the field used
in the sadb_sa_replay structure.
https://www.ietf.org/rfc/rfc2367.txt :
struct sadb_sa {
uint16_t sadb_sa_len;
uint16_t sadb_sa_exttype;
uint32_t sadb_sa_spi;
uint8_t sadb_sa_replay;
uint8_t sadb_sa_state;
uint8_t sadb_sa_auth;
uint8_t sadb_sa_encrypt;
uint32_t sadb_sa_flags;
};
=> max is 255*8 = 2040 packets wide.
Some time ago we already patched our kernel in order to use a 16bits field.
This does the job but we are facing two problems:
- the current algorithm is inefficient with large window sizes (bit shifting).
- we are still limited in size (65535*8 = 524280 packets)
Here are the ideas:
- implement RFC 6479 : https://tools.ietf.org/html/rfc6479
- replace the 8bit field with a 32bits field
I am not very comfortable with the idea to change a field that is described in
the RFC 2367.
Is there any other acceptable solution? Adding a new extension?
What do you think ?
Emeric
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Vlan offloaded checksums
Hello,
I have a network driver that supports hardware checksums.
Thanks to offset parameters, it also supports VLAN checksums.
However, it does not handle hardware tagging (not sure the underlying network
adapter can actually do it)
Unfortunately, the VLAN hardware checksums seem to be done only if
IFCAP_VLAN_HWTAGGING is set [1]
I do not understand this assertion: if I force the propagation of the hardware
checksuming only based on the IFCAP_VLAN_HWCSUM, it works fine with my driver.
What do you think?
Emeric
[1]:
In ./net/if_vlan.c, function vlan_capabilities :
/*
* If the parent interface can do checksum offloading
* on VLANs, then propagate its hardware-assisted
* checksumming flags. Also assert that checksum
* offloading requires hardware VLAN tagging.
*/
if (p->if_capabilities & IFCAP_VLAN_HWCSUM)
ifp->if_capabilities = p->if_capabilities & IFCAP_HWCSUM;
if (p->if_capenable & IFCAP_VLAN_HWCSUM &&
p->if_capenable & IFCAP_VLAN_HWTAGGING) {
ifp->if_capenable = p->if_capenable & IFCAP_HWCSUM;
ifp->if_hwassist = p->if_hwassist & (CSUM_IP | CSUM_TCP |
CSUM_UDP | CSUM_SCTP);
} else {
ifp->if_capenable = 0;
ifp->if_hwassist = 0;
}
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPSec and large replay window support
Hello,
Here is what we did for this: https://reviews.freebsd.org/D8468
Regards
- Original Message -
> From: "Emeric POUPON"
> To: "FreeBSD Net"
> Cc: j...@freebsd.org, g...@freebsd.org
> Sent: Wednesday, 8 June, 2016 14:12:48
> Subject: IPSec and large replay window support
> Hello,
>
> We plan to support large replay windows in the IPsec stack.
>
> Currently, the replay window size is limited due to the size of the field used
> in the sadb_sa_replay structure.
> https://www.ietf.org/rfc/rfc2367.txt :
>
> struct sadb_sa {
> uint16_t sadb_sa_len;
> uint16_t sadb_sa_exttype;
> uint32_t sadb_sa_spi;
> uint8_t sadb_sa_replay;
> uint8_t sadb_sa_state;
> uint8_t sadb_sa_auth;
> uint8_t sadb_sa_encrypt;
> uint32_t sadb_sa_flags;
> };
>
> => max is 255*8 = 2040 packets wide.
>
> Some time ago we already patched our kernel in order to use a 16bits field.
> This does the job but we are facing two problems:
> - the current algorithm is inefficient with large window sizes (bit shifting).
> - we are still limited in size (65535*8 = 524280 packets)
>
>
> Here are the ideas:
> - implement RFC 6479 : https://tools.ietf.org/html/rfc6479
> - replace the 8bit field with a 32bits field
>
> I am not very comfortable with the idea to change a field that is described in
> the RFC 2367.
> Is there any other acceptable solution? Adding a new extension?
>
> What do you think ?
>
> Emeric
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
