Joe Touch writes: > > No. I said we can ignore FINs, I didn't say RST. If the other end has > > properly implemented TCPINC and TCPINC is using TLS and the text says > > it MUST do close notify before FIN is accpeted, then we can ignore > > FINs for TCPINC sessions which have not yet received close notify from > > other end (note, this is again just an example of one way to solve > > some parts of this problems using the information we have inside the > > tcp stream, without explictly protecting TCP flags). > > You do realize that having a mechanism that tells you when to accept or > ignore FINs *is* header protection, the very protection you just decided > you don't want or need?
As I said in my email there are some functionalities that people do want to protect, but we do not want to protect TCP header in general. Everybody things we need to protect against replay, reordering and data dropping attacks. This could be interpreted to mean that we protect sequence number. 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. > 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. > If this is header-based TLS, then that TLS *is* protecting the header. What do you mean by header-based TLS? > So which is it? I was talking about the base version shown in draft-rescorla-tcpinc-tls-option and explaining that if that protocol wants to protect shutdown functionality, it can do that (currently it does not do that, and I am not sure if it is something that needs to be done). Thats why I wanted people to express the list of functionalities they wanted to protect, not actual 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. On the other hand people did not consider shutdown functionality important enough to list is as one of those they wanted to protect, so it can be so that we do not need / want to protect it. > > 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? 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. -- [email protected] _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
