Your network is setup wrong... if you are relying on a router to enforce ttl decrement for security. You can more easily prevent IP spoofing on the local net (or at the router) and then just verify the IP network portion is correct. Easier with a simple IP table rather than doing it in user space.
> On Jul 22, 2020, at 11:59 AM, Matthew Walster <matt...@walster.org> wrote: > > > One of the projects I'm playing with at the moment is going to have > long-lived low-traffic streaming sessions with GRPC, having both the client > and the server on the same subnet. > > To prevent an attacker from sending spurious TCP RSTs etc from across the > internet, there is a mechanism called GTSM where the underlying IP connection > has the TTL field set to the maximum value (255) and the receiver ensures > that the value seen in the IP header is the same value. Any hops through > routers would decrement the TTL so it's impossible to hijack the connection > unless you happen to be connected with an address in the same broadcast > domain. > > Now, I realise the operating system is the one that handles these incoming > packets and therefore it's not easy for Go to see what the TTL is on each > packet (without using a RawConn or similar) so it is a lot easier to just > filter out these packets using a local firewall (iptables or pf etc) and I > could just rewrite outgoing packets to have a this higher TTL, but I'm unsure > how to go about making the outbound connection set the higher TTL in the Go > code itself. > > Is there any established best practice for modifying these kinds of practices > on connections, especially in regard to using GRPC? I know I can use > golang.org/x/net/ipv4 and use SetTTL(ttl), then hook that in with a > "WithDialer" DialOption, but that seems a little too hacky and I'm not sure > how cross-platform that is. > > I considered using something like the TCP AO (RFC5925) instead, but > considering that GRPC (via MTLS) gives me all the authentication I need for > the data, that seems overkill and prone to opaque issues. I'm essentially > only worried about spoofed packets coming in trying to reset the TCP > connection. > > Open to any suggestions, many thanks in advance! > > Matthew Walster > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CADLW2vyWMJ-qty-UnH%3D00fKkiK%3DtNA8BtRfBCVNxfdrVaNLd0g%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/06ACD605-F8CF-4D68-8619-7B11AA4F01C4%40ix.netcom.com.
