Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Joe Touch <[e-mail]>]

On 8/26/2018 4:16 PM, Tom Herbert wrote:
> On Sun, Aug 26, 2018 at 2:55 PM, Toerless Eckert <[e-mail]> wrote:
>> On Sun, Aug 26, 2018 at 11:38:57AM -0700, Joe Touch wrote:
>>> NATs already have what they need to do the proper job - they need to reassemble and defragment using unique IDs (or cache the first fragment when it arrives and use it as context for later - or earlier cached - fragments). There???s no rule that IP packets that are fragmented MUST have a transport header both visible (not encrypted) and immediately following the IP header.
>> Reassmbly/refragment and MTU discovery puts NAT out of the realm of many
>> cost effective HW acceleration methods. Simple address rewrite does not.
>>
>>> Firewalls are just delusions; [1]
>>> the context they think they???re enforcing has no meaning except at the endpoints; it never did. [2]
>> I completely agree with [2], but my conclusion is not [1], but
>> rathat its highly valuable and necessary.
>>
>> The ability of firewalls to open 5-tuple bidirectional pinholes because
>> of trigger traffic from the inside is IMHO the most important feature
>> to keep Internet hosts protected. I wish host stacks would be built securely,
>> but after a few decdaces i have given up on that for most hosts. Which is
>> why its so irritating when host stack pundits continue telling network device
>> stack builders what they should and should not do.
>>
> When the host stack pundits are asking network device stack builders
> to conform to the standard protocols then I believe that is
> reasonable. If firewalls were standard and ubiquitous, and standards
> were adhered to, then host stacks would have no problem. But alas
> they're not, so we're forced to implement the host stack per the least
> common denominator functionality of network devices.
Seriously, we cannot be wasting time making new rules for devices that
don't follow rules. What's the point?

>
>> Firewalls inspecting unencrypted higher layer message elements where a fairly
>> well working security model based on having a separate security administration
>> from the application administration. Now the applications promise to
>> provide all the security themselves, but they primarily just prohibit visibility
>> of what they do, so its a lot harder to figure out when they are insecure.
>>
>> Would you ever put all type of in-home "iot" gear thats not a Windows/MacOS
>> system with a GUI you can control on the Internet without a firewall ?
>>
> Conversely, do you allow your smartphone to connect to a network
> before you've verified that a firewall is being run in the network,
> what vendor provided it, and what the configured rules are?

Nope. That's why I run a firewall *on the device*.

Joe