Hi Joe, On Wed, May 4, 2016 at 12:58 PM, Joe Touch <[email protected]> wrote:
> 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]> 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. > OK. I'm not very sure how it is complicated to take care of masking and to follow linked lists in memory. But, anyway, I still think it's at least worth for discussion as an optional feature. Thanks, -- Yoshi
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
