On Wed, Aug 29, 2018 at 10:10 AM, Joe Touch <to...@strayalpha.com> wrote: > Tom, > > > > > On 2018-08-29 09:53, tom wrote: > > On Wed, Aug 29, 2018 at 8:11 AM, Joe Touch <to...@strayalpha.com> wrote: > > > > > > On 2018-08-28 17:24, Toerless Eckert wrote: > > ...Sure, i meant to imply that port-numbers are useful pragmatically, > but other context identifiers would long term be better. > Demux-Identifiers at the granualarity of a subscriber or > application wold be a lot more scalable than flow identifiers. > > > There are many problems with this issue. > > First, the reason that port numbers would be needed is that they are > *currently* how NATs demux, firewalls enforce policy, and routers manage > > > There is no requirement in IP that all packets have a transport layer > header that with port numbers. ... > > > Yes, we agree. It's not the only way they SHOULD or COULD work, but it is > how they DO work. > > > > > > Ultimately, we have to admit that a device that acts on behalf of a host IS > a host and costs what a host costs. > > > That in turn breaks the the end-to-end model. > > > > Acting like what you are doesn't break anything; it lets you act to the > fullest extent possible. > > Relaying info through hosts inside a network path is what breaks the E2E > model - agreed. > > All I am saying is that: > - IF you deploy a middle box, THEN it MUST act as a host and reassemble (or > do the equivalent) > > I wasn't endorsing the IF.
I don't think you need the part about acting as a host, that would have other implications. Also, the reassembly requirement might be specific to NAT and not other middlebox functionality. For instance, it would be sufficient for a firewall that is dropping UDP packets to some port to only drop the first fragment that has UDP port numbers and let the other fragments pass. Without the first fragment reassembly at the destination will simply timeout and the whole packet is dropped. > > > > > Middleboxes that attempt > to participate transport protocols, like a host, inevitably break > things and hence is another source of ossification. This is readily > evident apparent in that they can't participate in end-to-end crypto. > > > They can* participate in crypto, but then the definition of E2E ends where > it should - at the middlebox. > > * = only if they somehow are given the key, of course > > > > Of course they have tried to insert themselves into that realm, but > then we get abominations such as the forced MITM attacks of SSL > inspection. IMO, real end-to-end security is a core requirement that > outweighs any tradeoffs we might make for the security benefits of > firewalls. > > > I would argue that it is OK to give a middlebox the key if that's OK for a > given trust model, e.g., it would make sense inside an enterprise to offload > security to the ingress of that enterprise. But not elsewhere; > Sure enterprises can do that. But I'm more worried about the five billion mobile devices that may connect to random WIFI or mobile networks over the course of a day. For them there is simply no concept that the network will provide any level of security. Tom > > > > > We can't keep believing there is magic dust that can establish a solution > otherwise. > > As they say, the answer to ossification is encryption. > > > It's not an answer; it renders the question irrelevant, as it should. > > Not all questions necessarily have answers. As Rocket will tell you (ref: > end scenes, Guardians of the Galaxy), wanting something does not make it so. > > Joe _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
