Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 30 Aug 2010 15:40:44 -0500

Kevin Fleming said:

" I can sympathize with the desire to have a simpler mechanism for doing
*only* v4/v6 path selection, but since either method will require
implementers of media endpoints to develop the required support, I'd rather
push them towards implementing STUN. The SHA-1 overhead for a few packets at
the beginning of a session seems (to me, anyway) to be far less CPU burden
than the low bitrate codec (or modem) that the gateway will eventually be
operating on that channel anyway."

[BA]  The first question to ask is whether the general topic (Migration of
SIP to IPv6 Media) is worth focusing on.  I believe that it is.  ICE has
substantial deployment today on IPv4 (several million hosts now run it on a
regular basis),  and I agree with Kevin that some
simplifications/adjustments are probably needed for v4/v6 path selection, if
only to update the thinking based on our current knowledge of potential IPv6
transition scenarios and routing/performance issues.  I also agree with
Kevin that SHA-1 overhead is not really much of an issue.  

As for the proposed solution, it's not clear to me how well it will work in
some of the IPv6 transition scenarios now under discussion (such as an
IPv6-only smartphone attempting to communicate with an IPv4-only device via
NAT64).

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 30 Aug 2010 17:17:26 -0400

Think of this from the perspective of a PSTN Gateway.  PSTN Gateways handle thousands or tens of thousands of calls or more.  Sure, if they happen to have SRTP hardware, and their architecture/implementation happens to be able to use that hardware for SHA-1 in STUN checks, then they may be able to do it without impact.  Or they can burn DSP cycles, if they happen to have DSPs that can do it. 

And then there are all the vendors who make B2BUAs that try to avoid using DSPs for calls but would be the media IP relay (like transcoder-free MSCs, SBCs, BGFs, etc.).

And what great benefit does the operator of such gateways/b2bua's get that they didn't have before?  It doesn't suddenly secure the media - only real SRTP does that.  It doesn't allow them to suddenly support both IPv4 and IPv6 - they can already do that, by simply using the same transport family for the media as they did the signaling. (i.e., pick one before the INVITE is sent/answered)  No, what we're trying to do is let them figure out which transport is actually working for the media plane, because we're worried IPv6 will have issues.  Cool.  So why do we need SHA-1 to do that, exactly?  It's like saying to do HTTP over IPv6 you need to do TLS.

-hadriel

On Aug 30, 2010, at 4:40 PM, Bernard Aboba wrote:

> Kevin Fleming said:
>  
> " I can sympathize with the desire to have a simpler mechanism for doing *only* v4/v6 path selection, but since either method will require implementers of media endpoints to develop the required support, I'd rather push them towards implementing STUN. The SHA-1 overhead for a few packets at the beginning of a session seems (to me, anyway) to be far less CPU burden than the low bitrate codec (or modem) that the gateway will eventually be operating on that channel anyway."
>  
> [BA]  The first question to ask is whether the general topic (Migration of SIP to IPv6 Media) is worth focusing on.  I believe that it is.  ICE has substantial deployment today on IPv4 (several million hosts now run it on a regular basis),  and I agree with Kevin that some simplifications/adjustments are probably needed for v4/v6 path selection, if only to update the thinking based on our current knowledge of potential IPv6 transition scenarios and routing/performance issues.  I also agree with Kevin that SHA-1 overhead is not really much of an issue. 
>  
> As for the proposed solution, it's not clear to me how well it will work in some of the IPv6 transition scenarios now under discussion (such as an IPv6-only smartphone attempting to communicate with an IPv4-only device via NAT64). 
>  
> <ATT00001.c>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 30 Aug 2010 17:07:49 -0500

> And what great benefit does the operator of such gateways/b2bua's get that they didn't have before?  It doesn't suddenly secure the media - only real SRTP does that.  It doesn't allow them to sudde…

Just to be clear; I was not proposing that SHA-1 was a part of the
solution to the problem here, just that STUN can be the solution and ICE
usage of it happens to employ SHA-1 because it uses message integrity
checking. For this application, STUN could be used without message
integrity checking, because the application itself is already subject to
various forms of well known attacks (any RTP implementation that
supports media latching is subject to them).

My concern is really based on those exact PSTN gateways that you
mention... unless we aren't expecting the massive installed base of them
to upgrade to IPv6 at all, it would be surprising to me if the media
transport stacks on those gateways could handle generating and receiving
duplicate media streams for the same session without significant
redesign. Using STUN as a mechanism for a connectivity check seems to be
a simpler route, as it is done prior to the media stream even being
established, and doesn't even have to involve the DSPs in the gateway at
all, since the number of packets involved is so low (so the general
purpose processor in the gateway can use a presumably less efficient
mechanism to transmit and receive packets on the selected ports for a
session).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 30 Aug 2010 15:49:43 -0700

As you said, SHA-1 isn't required the media connectivity test, but comes in
as part of STUN support.
 
My problem is that the document appears to only consider "pure" IPv6
scenarios where STUN might not be needed, but doesn't consider more complex
transition scenarios like NAT64, DSLITE, etc.  It seems to me that the
scenario discussion is an important one to have upfront.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, August 30, 2010 2:17 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity
Checks

Think of this from the perspective of a PSTN Gateway.  PSTN Gateways handle
thousands or tens of thousands of calls or more.  Sure, if they happen to
have SRTP hardware, and their architecture/implementation happens to be able
to use that hardware for SHA-1 in STUN checks, then they may be able to do
it without impact.  Or they can burn DSP cycles, if they happen to have DSPs
that can do it. 

And then there are all the vendors who make B2BUAs that try to avoid using
DSPs for calls but would be the media IP relay (like transcoder-free MSCs,
SBCs, BGFs, etc.).

And what great benefit does the operator of such gateways/b2bua's get that
they didn't have before?  It doesn't suddenly secure the media - only real
SRTP does that.  It doesn't allow them to suddenly support both IPv4 and
IPv6 - they can already do that, by simply using the same transport family
for the media as they did the signaling. (i.e., pick one before the INVITE
is sent/answered)  No, what we're trying to do is let them figure out which
transport is actually working for the media plane, because we're worried
IPv6 will have issues.  Cool.  So why do we need SHA-1 to do that, exactly?
It's like saying to do HTTP over IPv6 you need to do TLS.

-hadriel

>  
> As for the proposed solution, it's not clear to me how well it will work
in some of the IPv6 transition scenarios now under discussion (such as an
IPv6-only smartphone attempting to communicate with an IPv4-only device via
NAT64).

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Aug 2010 09:43:11 -0400

Yeah, I was only responding in reference to the SHA-1 work for the STUN checks.  I can't figure out if Dan's draft is any better/worse than just STUN connectivity checks without SHA-1.

-hadriel

On Aug 30, 2010, at 6:07 PM, Kevin P. Fleming wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch