> On Jul 30, 2018, at 12:33 AM, Ole Troan <otr...@employees.org> wrote:
>
> Joe,
>
>>> However much money you throw at it, you can't reassemble fragments
>>> travelling on different paths, nor can you trivially make network layer
>>> reassembly not be an attack vector on those boxes.
>>
>> Agreed, but here’s the other point:
>>
>> Any device that inspects L4 content can do so ONLY as a proxy for the
>> destination endpoint.
>>
>> I.e., I know vendors WANT to sell devices they say can be deployed anywhere
>> in the network, and operators believe that, but it’s wrong.
>>
>> Basically, if you’re not at a place in the network where you represent that
>> endpoint, you have no business acting as that endpoint - “full stop”.
>
> I understand you want it to fit in your model, but it doesn’t.
My model describes the rules under which translation devices can operate
correctly and predictably in the Internet model.
There are only a few alternatives for devices not explained by either model:
1- the Internet and my model are incomplete
in that case, you’re welcome to provide one for the new device
2- the Internet and/or my model are incorrect
in that case, you’re welcome to explain why
3- the device should be considered incorrect and itself corrected
Un-doing fragmentation at IP is an attempt to jump to a solution for #1 without
explaining WHY, other than “we need to do this to fix the Internet to support
these new devices”.
I don’t think we should break known models to adapt to devices whose behavior
might never be correctly accommodated.
> Take A+P (RFC6346), and it's instantiations through e.g. MAP-E (RFC7597).
> That's essentially normal longest match forwarding on addresses and ports.
So? Any device that sources packets with addresses it owns IS an endpoint on
the Internet. Nothing changes based on how it translates those devices to the
private side.
>
> With regards to your point about reassembly at higher layers, crypto is the
> answer to that.
Crypto will just end up putting a halt to all this nonsense - but not quickly
enough, IMO.
Then again, I would not be surprised to be back here discussing a doc on
“transport crypto considered fragile” in a decade...
Joe
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
