On 8/26/2018 4:16 PM, Tom Herbert wrote:
> On Sun, Aug 26, 2018 at 2:55 PM, Toerless Eckert <t...@cs.fau.de> 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
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
