On 08/18/2014 06:42 PM, John-Mark Gurney wrote:
Brandon Williams wrote this message on Mon, Aug 18, 2014 at 09:10 -0400:
On 08/16/2014 02:18 PM, John-Mark Gurney wrote:
Brandon Williams wrote this message on Fri, Aug 15, 2014 at 17:59 -0400:
On 08/15/2014 01:37 PM, John-Mark Gurney wrote:
Brandon Williams wrote this message on Fri, Aug 15, 2014 at 10:36 -0400:
On 08/08/2014 12:47 PM, Nico Williams wrote:
On Fri, Aug 08, 2014 at 12:09:37PM -0400, Brandon Williams wrote:
And by terminate TCP connection, I assume you mean to deframe and
sequence the session? Why does an optimizing proxy need to do this
work?
So, why can't the optimizing proxy just queue up the frames and resend
them unmodified back out? Yes, it'll be more work, but an optimizing
TCP proxy is already doing extra work (like it shouldn't be acking data
till the other side ack's it, etc)...
btw, I do realize people want to make these optimizing proxies, but
I think that at least for tcpcrypt, storing frames and retransmitting
them would be the easiest way, and keep the MAC's intact w/o having
to modify the protocol significantly to support these...
I can certainly see that a whole different architecture for the proxy
could make it easier to support tcpcrypt, but that's just as much a
result of how tcpcrypt is designed as it is the design of the proxy. A
proposal that doesn't integrity check the TCP header and the data stream
as a single unit would not have this problem.
what about RST? Also, I don't see a way to have a protected data stream
if you don't at least protect the sequence numbers... If you don't, then
you have replay and injection attacks, or its harder to reject invalid
packets, etc...
If you belive that it is possible to do this, then please, put forward
a proposal along w/ security proof and description of attack senarioes..
I'm definitely not suggesting that it's a bad idea to authenticate TCP
headers. I'm simply suggesting that combining TCP header authentication
with data stream authentication could break a specific existing type of
middleware.
I see the question of why a proxy might be designed this way as a
rathole for the list. The fact of the matter is that there are a broad
range of such middle boxes, and I don't think that this WG's efforts are
going to drive middleware vendors to completely redesign their
technology (at least not in the near term), regardless of whether some
WG participants think that the vendors have made bad design choices. On
the other hand, middleware vendors might go to the trouble of supporting
tcpinc if it is not designed in a way that prevents them from doing so.
Currently, only one of the four proposals does not protect the TCP
header, and that one TLS... Not protecting the header makes it
extermely easy to DoS the connection, since it specificly states that
any invalid payload will cause the connection to be torn down... This
is because it can't reject fake incoming data, and once the data has
been received, it can't know where to rewind state to (well, it could,
but I'd hate to think about what that would do to the TCP state
machine)...
IIRC, the TLS proposal doesn't ignore this entirely. It simply states
that tcp-ao can be used for this purpose and that tcpinc doesn't have to
provide the capability.
So, from the looks of it, the TCP header will likely be protected in
one of the chosen solutions...
I haven't seen this clear consensus from the WG so far, which is part of
what drove the "why not just TLS?" thread to begin with. That said, I'm
not arguing that the protocol should or shouldn't authenticate the
header. I'm focused only on what I see as the implications of the
proposed methods for providing such authentication.
And remeber, the IETF is proposing TCP in UDP because of these
middleware boxes... I can't wait till the day we do TCP in UDP in UDP
(turtles all the way down) because the middleware boxes become aware
of TCP in UDP, etc. etc. The IETF needs to address the broken
middleware box issue, but obviously, not in this forum...
This leads me to the question of what our goal is relative to such
middleware. Do we want to positively influence adoption by ensuring
interoperability with these types of boxes? Or do we want to declare
these boxes to be part of the problem and explicitly not support them,
despite the fact that it may slow adoption of the protocol?
This is a very good question to have answered.
We cannot make any compromises to support middleware boxes that would
prevent us from providing the security stated by the charter... That
includes various bits about not authenicating parts of the header... If
we do that, then we might as well never produce a standard...
I was concerned about supporting middleware boxes, but now that I
thought of the store and forward idea, I don't have any worries... Yes,
it might be a bit more work for the middleware boxes, but supporting
any new protocol/option (which they rarely do, so, no loss there)
requires work... If they are interested in this discussion, they'll
join and add their insight, but breaking the charter doesn't make
sense...
My goal in engaging in this discussion is exactly that, to bring the
perspective of a middleware vendor who desires to support the protocol
that comes out of this WG's efforts. I'm definitely not asking for the
charter to be compromised. I'm just trying to figure out whether it will
be possible for my system to support the resulting protocol without
sacrificing my customers' security requirements. It's not clear to me
that separating TCP header integrity checks from encrypted data stream
integrity checks would necessarily compromise the charter, but I also
understand that the eventual WG consensus might not be with me.
--Brandon
--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
