On 3/17/2015 4:12 AM, Tero Kivinen wrote: ... > Protecting shutdown functionality, can be done either by protecting > the TCP header bits in the TCP header, or some other method, just like > I explained above. They do provide protectiong against same > functionality, but are done on different layers.
It MUST be in the TCP layer or above. If you put the protection in the transport payload, you won't see that data until AFTER the TCP header has been processed. >> You can't do that with conventional TLS - TLS is carried over TCP, and >> TCP would have processed the FIN before TLS knew about it. > > Yes, which would be the benefit for tcpinc TLS compared to the plain > TLS inside TCP... In tcpinc we can do that. You can decide to do that with any solution, but it is protecting the TCP header at that point, which is exactly what you said we agreed NOT to do (even by the subject line of this message). > >> If this is header-based TLS, then that TLS *is* protecting the header. > > What do you mean by header-based TLS? The tcpinc TLS proposal. > Thats why I wanted people to express the list of functionalities they > wanted to protect, not actual TCP header bits. FIN and RST are TCP header bits. > We can provide > protection to the functionalities in different layers even when we do > not care about the actual TCP header bits. You cannot. If you don't protect the bits of the TCP header, you're dead before the next layer gets to react. ... >>> On the other hand if that is >>> important thing to protect against we can make that keepalive not to >>> be TCP keepalive, but inner layer protocol frame, i.e. in TLS case it >>> could be some kind of heartbeat extension packet or similar. >> >> Yes, but that would be outside the scope of solutions here, no? > > Why? I thought the scope here was TCP - by the name of the WG. > If we consider the protecting cleaning up state messages > important functionality enough to protect it, we can protect it. We > can do the protection on multiple different ways. You can call it what you want, but if it blocks interpretation of TCP header bits before confirming the message security, you ARE protecting the TCP header, and then you are NOT "going forward without protecting the TCP headers". Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
