Re: [rtcweb] NAT behavior heuristics

Cameron Byrne <cb.list6@gmail.com> Tue, 07 August 2012 16:08 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C0521F8652 for <rtcweb@ietfa.amsl.com>; Tue, 7 Aug 2012 09:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.47
X-Spam-Level:
X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq+UWJuSNQBV for <rtcweb@ietfa.amsl.com>; Tue, 7 Aug 2012 09:08:41 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04F3D21F8716 for <rtcweb@ietf.org>; Tue, 7 Aug 2012 09:08:40 -0700 (PDT)
Received: by lbbgg6 with SMTP id gg6so1204961lbb.31 for <rtcweb@ietf.org>; Tue, 07 Aug 2012 09:08:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Tt7wqVPl3jQsHxbCkrxVfdn5KPX+EEeTzhAhHsvw2Vs=; b=TBcEY7ZEuHqyZikHADcYbkoljKmNuLD6XC9x85kaQNjaybTqdYcNDbSsFISYJxQRZ7 OWN/+bRQHOcWsaMfTU2w3/4KrIInQ3+3wdtHhZOxLyN7HpHeY89pYRcA+E4OxNC6fsKp VV03v45Rd5oC0EXBQacVmExdgxyACBraBnD0HAebU7GiDvPVhw8BidnouUBN68LpWEoo b7aRAV/VGFG0YOs4o1LAhsII7KsJduGgwNHLcVSx3iXWykGFZQ2bUxtBRTd3d9aZWyqt hziK5fTC/Aj2pNMfH/AdVlzSpstpxqik8U+LaSCsW84GD6pZnSLEVRUxAEY1uo3ONgtr sbxg==
MIME-Version: 1.0
Received: by 10.112.84.39 with SMTP id v7mr6610057lby.15.1344355719565; Tue, 07 Aug 2012 09:08:39 -0700 (PDT)
Received: by 10.112.3.196 with HTTP; Tue, 7 Aug 2012 09:08:39 -0700 (PDT)
In-Reply-To: <913383AAA69FF945B8F946018B75898A1477E4F7@xmb-rcd-x10.cisco.com>
References: <038b01cd70d6$8c5bc870$a5135950$@com> <CABkgnnW+pCnDZuYHDj6=7xdqRwM6AO48RrC1xhMrvFZbUBgtyw@mail.gmail.com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <CAD6AjGTrd0d9dm5HC2xr=ZAU2DmU55Sdkm6rH8NO4sJMMuLScA@mail.gmail.com> <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> <CAD6AjGTEH+12WfKavx7H_xpfeynEL6W33L9nD98_vztVodGTuA@mail.gmail.com> <E44893DD4E290745BB608EB23FDDB76228412C@008-AM1MPN1-042.mgdnok.nokia.com> <CAD6AjGQyMjK0paM6v3m_DTxBk7AEpQQYaqo8NkZKxUd6eJ_YKg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A1477E4F7@xmb-rcd-x10.cisco.com>
Date: Tue, 07 Aug 2012 09:08:39 -0700
Message-ID: <CAD6AjGToC86QjCaRNxFCcJS3cdb-j4grsuEaZkqKBrchhJLvow@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "randell-ietf@jesup.org" <randell-ietf@jesup.org>, "phdgang@gmail.com" <phdgang@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] NAT behavior heuristics
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 16:08:43 -0000

On Tue, Aug 7, 2012 at 8:37 AM, Tirumaleswar Reddy (tireddy)
<tireddy@cisco.com> wrote:
>> I know of one large USA mobile operator that is not SPI firewalling or tracking state for ipv6 mobiels, so this is not a problem for them.
>> If operators choose to statefully inspect user traffic, those cost and limitations are assumed as part of the cost and service definition from the mobile
>> operator.
>> IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks.
>
> http://www.bluecoat.com/sites/default/files/documents/files/Content_Filtering_for_Mobile_Operators.pdf
> offers URL filtering based on user profile, claims to block Skype if sent over port 80/443  (http://www.bluecoat.com/sites/default/files/documents/files/How_Mobile_Operators_Can_Control_Skype.1.pdf), block viruses/worm. This product is targeted for Mobile Operators.
>

Since you just sent URLs without an explanation, i am not sure the
intent of your email.

If you are suggesting that mobile operators should buy this product to
block Skype, you are probably on the wrong mailing list.

If you are suggesting mobile operators should buy this product to
block Skype and then use PCP to allow Skype, ....  Not sure that will
get much traction either.

CB

> --Tiru.
>
>
> From: Cameron Byrne [mailto:cb.list6@gmail.com]
> Sent: Tuesday, August 07, 2012 8:41 PM
> To: Markus.Isomaki@nokia.com
> Cc: rtcweb@ietf.org; Tirumaleswar Reddy (tireddy); phdgang@gmail.com; randell-ietf@jesup.org
> Subject: RE: [rtcweb] NAT behavior heuristics
>
>
> On Aug 7, 2012 7:13 AM, <Markus.Isomaki@nokia.com> wrote:
>>
>> Hi Cameron,
>>
>> Cameron Byrne wrote:
>> >
>> >I asked around in Vancouver about PCP, and all the operators i spoke to said
>> >no-plans, no motivation.  But, that was a small sample.
>>
>> This is probably a fair assessment about the concrete plans. Most mobile operators don't even follow IETF much, so I doubt that they have even heard about PCP so far. There are however a few operators, where at least the research and standardization people have been interested in PCP (as witnessed by http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment/). I think some operators are also proposing PCP to be included in the 3GPP specs (release 12). It is hard to say how much that means in the real world, but at least I'd expect we could find a few operators willing to do real-network trials withing the next 12 months.
>>
>> Personally I see PCP as a very useful tool in the cellular access environment, for probing the NAT/FW timers and in the best case even setting them. It will be a major chicken-and-egg situation between apps, mobile OS's and the networks, to get anything into use. I think we should still do our best to overcome it. I agree that RTCWeb or anyone else should not rely on PCP (or any similar mechanim), but have the ability to make use of it if it happens to be available.
>>
>> I'm unconvinced IPv6 will help at all in this case. How do you know how long the FW on the path will keep its state up without keepalives? It will probably be the same as for NATs: In some networks timeout is 2 minutes, while in others 60 minutes. Having something like PCP to check out that it indeed is 60 min. would be extremely helpful. While most app developers might not be willing/able to optimize for battery/mobile, there are already some that are doing a good job. So there is hope that the new mechanisms would get some traction.
>>
> I know of one large USA mobile operator that is not SPI firewalling or tracking state for ipv6 mobiels, so this is not a problem for them.
> If operators choose to statefully inspect user traffic, those cost and limitations are assumed as part of the cost and service definition from the mobile operator.
> IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks.
> CB
>> Markus
>>
>>
>> >-----Original Message-----
>> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>> >Of ext Cameron Byrne
>> >Sent: 06 August, 2012 01:22
>> >To: Tirumaleswar Reddy (tireddy)
>> >Cc: Randell Jesup; rtcweb@ietf.org; phdgang@gmail.com
>> >Subject: Re: [rtcweb] NAT behavior heuristics
>> >
>> >On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy)
>> ><tireddy@cisco.com> wrote:
>> >>> Fyi. I have not seen any traction for pcp anywhere in the mobile space.
>> >>
>> >> http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 describes
>> >usage of PCP in Mobile Deployments.
>> >>
>> >> --Tiru.
>> >>
>> >
>> >Yep, that's  an I-D.
>> >
>> >And, it says things like "Without
>> >   the particular considerations , PCP may not provide desirable
>> >   outcomes.  Some default behaviours may even cause negative impacts or
>> >   system failures in a mobile environment.  "
>> >
>> >Got an operators with a timeline on supporting it?  How about a mobile OS
>> >that plans to support PCP, because you will need both.  And, that would be
>> >interesting information.
>> >
>> >I asked around in Vancouver about PCP, and all the operators i spoke to said
>> >no-plans, no motivation.  But, that was a small sample.
>> >
>> >In any event, my only point is that RTCWEB should NOT be counting on PCP.  If
>> >PCP is a tool you have, use it.  My point: it is not a tool you have.
>> >
>> >CB
>> >_______________________________________________
>> >rtcweb mailing list
>> >rtcweb@ietf.org
>> >https://www.ietf.org/mailman/listinfo/rtcweb