28 Apr
2017
28 Apr
'17
9:16 a.m.
No, I disagree.
Only his encapped packet has the wrong size and DF bit set in it; the
outer IP header is correct. So only AMPR decapsulating routers will
see it. No Internet routers will look inside the inbound outer packet
and be in any way affected. Amprgw drops the decapsulated packet and
doesn't forward it back to the Internet. And there are only a few
such packets per hour. It's not a Martian: the inner source address
is correct for his subnet. These packets are replies to incoming TCP
connection requests that are being rejected.
Yes, he should fix it when he can but I don't think it's a big enough problem
to warrant shutting down the gateway.
Interestingly enough, as I was writing this reply, his gateway sent
an encapped packet that had a size mismatch and the TOS set to 0xb8
but no DF bit. First one of those I've seen. It was dropped.
Apr 27 19:00:21 <local0.info> amprgw ipipd[23186]: kernsend: len=440, ver=4 hl*4=20
tos=b8 len=8186 id=e790 off=0000 ttl=63 proto=17 cksum=dcc4 [UDP] 44.4.39.8:123 ->
184.105.139.112:48048
There's definitely something weird going on.
- Brian
On Thu, Apr 27, 2017 at 09:56:01PM -0400, lleachii--- via 44Net wrote:
You do agree that:
- a packet stating it's x large in size
- traverses multiple routers over the Internet - with a DO NOT FRAGMENT BIT
- and is received and responded upon
- even thought the packet is bona facie: bogus, invalid and Martian
- and is proven to be magnitudes smaller than x size
- and how the packet was successful in receiving a reply is unknown
...I think he should block it.
- KB3VWG