Eric Rescorla wrote this message on Tue, Oct 07, 2014 at 02:14 -0400:
> On Tue, Oct 7, 2014 at 2:04 AM, John-Mark Gurney <[email protected]> wrote:
>
> > marcelo bagnulo braun wrote this message on Mon, Oct 06, 2014 at 19:01
> > +0200:
> > > The options we can identify are the following ones:
> > > - Protect only the payload (don't include any of the TCP header fields
> > > in the MAC calculation)
> >
> > If this does not include the sequence number, then how can we possibly
> > prevent replay attacks? As you discuss later, preventing replay
> > attack IMO should be done as it isn't that much more difficult...
>
> You can protect replay attacks on the payload by incorporating a sequence
> number into the integrity check. This is how TLS works ordinarily.
Yes, I did think of a framing protocol (see comments on MAC in
payload), but any framing protocal does immediately increase the
complexity of the protocol...
It also prevents the elimination of unnecessary MACs in the case of
retransmits... i.e. person typing on lossy link... Each key press
gets sent, but significant packet loss and have to be retransmitted..
W/ a framing protocol, you must transmit the MAC for EACH key press
instead of combining them all together in a later packet...
This is part of the problem of discussing what a solution should
contain vs what solution to pick... Each solution may choose a
different method, and each one has their trade offs... No framing
protocol was mentioned, nor was replay attacks in the last email,
hence my concern...
Yes, if a framing protocol is used, and properly protected, then I'll
agree sequence numbers don't need to be protected, but we already have
a framing protocal and it's called TCP/IP..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
