Hi Joe, On Mon, May 2, 2016 at 10:38 PM, Joe Touch <[email protected]> wrote: > > > On 5/1/2016 9:30 PM, Yoshifumi Nishida wrote: > > Hi, > > I am thinking about dividing encrypting a TCP segment into the two parts: > > A) encrypt arbitrary part of a TCP segment and B) determine which > > parts of a TCP segment should be encrypted. > > Because I might want to think them separately if possible. > > > > From my point of view, when we encrypt TCP payload, we just mask the > > header part of the TCP segment before encryption. > > That would mean that encryption would depend on the length of the header > part. Middleboxes are known to insert, delete, fold, spindle, and > otherwise mutilate options, which means that you would be encrypting > over a different length of zero-content prefix. > > At a minimum, you need to know where the TCP payload is and start there, > not merely mask out the header. That currently involves parsing only the > TCP base header, but in the future may also involve parsing one of the > TCP options (TCP-EDO) (which would further complicate the notion of > encrypting options or even a portion thereof) >
We'll need to know where the encryption part is. If it's payload, it will be easy as we can get the starting point from the header. But, I am guessing it doesn't have to be payload. We cannot control the behavior of middleboxes. They might do some unknown things whether the segment is encrypted or not. All we can do is to detect if the encrypted parts are tampered (which should be possible) and react to it (discard the segment, fallback to normal TCP or reset the connection, etc) based on some policies. > I am naively thinking that it's not very difficult to change masking > > areas. > > AFAICT, it would defeat encryption (or should). > > Hmm.. Sorry, I couldn't catch this. Could you elaborate? Thanks, -- Yoshi
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
