3401 and highjacking

Stephen Kent wrote:
> At 3:28 PM -0800 2/23/06, Joe Touch wrote:
>> ...
>> Channel binding isn't a motivation for BTNS. BTNS
is a place where we
>> are exploring it.
> 
> Sorry. I though it was one of the cited motivations. 
I'll have to read
> the latest problem statement I-D.

I saw Nico's post on this; I'll recheck the latest PS doc
to see whether
this needs to be updated on this.

>> ...
>> That's what I'd like to avoid by encouraging
using a cross-transport
>> solution, e.g., at the network layer.
> 
> The reasons that they chose to not use Ipsec are based
on per-packet
> overhead, for the very small RTP packets. Nothing we do
in BTNS is going
> to address that concern.

Their per-packet processing overhead can't be all that
different; they
use AES and HMAC-SHA1. The key difference is that SRTP
allows "good
enough" key lengths that are less than full-sized,
which helps keep the
bandwidth overhead down and packet expansion constrained,
but which
forces the session keys to have a shorter lifetime. That
logic is
equally valid for IPsec.

>> ...
>> We have been talking about BTNS use cases; as I
noted before, one (the
>> original one, and at least one of the current ones)
is to protect the
>> transport layer.
> 
> The original one you cited, yes, but that has not been
the primary focus
> of most of the more recent discussion, I think.

Many of those discussions were raised in the context of
connection
binding; while BTNS is a place where that issue is being
raised, it is
not unique to BTNS.

>> I *fully* agree with the fact that TCP/MD5 doesn't
offer the same
>> protection as IPsec, but it does protect the
transport layer. That
>> differentiates it from TLS.
> 
> it offers some protection, but to say that it
"protects" the layer might
> surprise folks who think confidentiality is important
.

The same is true for an IPsec SA based on MD5. The point
wasn't privacy
vs. authentication; it's transport vs. non-transport.

Joe
_______________________________________________

At 9:50 PM -0800 3/1/06, Joe Touch wrote:
>...
>  > The reasons that they chose to not use Ipsec are
based on per-packet
>>  overhead, for the very small RTP packets. Nothing
we do in BTNS is going
>>  to address that concern.
>
>Their per-packet processing overhead can't be all that
different; they
>use AES and HMAC-SHA1. The key difference is that SRTP
allows "good
>enough" key lengths that are less than full-sized,
which helps keep the
>bandwidth overhead down and packet expansion
constrained, but which
>forces the session keys to have a shorter lifetime. That
logic is
>equally valid for IPsec.

It's communication overhead, not processing overhead, that
motivates 
use of SRTP. the headers for SRTP are very small, even
compared to 
transport mode ESP.

>
>...
>
>>>  I *fully* agree with the fact that TCP/MD5
doesn't offer the same
>>>  protection as IPsec, but it does protect the
transport layer. That
>>>  differentiates it from TLS.
>>
>>  it offers some protection, but to say that it
"protects" the layer might
>>  surprise folks who think confidentiality is
important .
>
>The same is true for an IPsec SA based on MD5. The point
wasn't privacy
>vs. authentication; it's transport vs. non-transport.

First, there are no SAs that are protected via MD5, per se,
although 
we can have SAs that make use of HMAC-MD5. But, ESP (which
is a more 
efficient way to offer integrity and authentication that
AH), also 
offers confidentiality, if desired. Thus it can
"protect" a 
connection to whatever extent a user wishes, depending on
selection 
of appropriate options, unlike the limited forms of
protection 
offered by the TCP-MD5 checksum option.

Steve
_______________________________________________