Hi, Yoshifumi, On 5/3/2016 7:47 PM, Yoshifumi Nishida wrote: > Hi Joe, > > On Mon, May 2, 2016 at 10:38 PM, Joe Touch <[email protected] > <mailto:[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. ... > > > 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?
It's just a comment on using "masking" rather than an offset to start encryption. I.e., encrypting over "0abc" yields a different result than "abc". It's not sufficient to just mask-out the prefix area if that area could vary in length. A side note: some implementations put TCP headers and payloads in different places, so "just backing up to include the options" can require more complicated code than it may first appear as well. Joe
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
