Re: [Aeon] Collaborative network proposal
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Fri, 21 March 2014 16:19 UTC
Return-Path: <eckelcu@cisco.com>
X-Original-To: aeon@ietfa.amsl.com
Delivered-To: aeon@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com
(Postfix) with ESMTP id 91C811A08CB for <aeon@ietfa.amsl.com>;
Fri, 21 Mar 2014 09:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.047
X-Spam-Level:
X-Spam-Status: No,
score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001,
USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzDRZF_tYhZ5 for
<aeon@ietfa.amsl.com>; Fri, 21 Mar 2014 09:19:10 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76])
by ietfa.amsl.com (Postfix) with ESMTP id AC62B1A0772 for <aeon@ietf.org>;
Fri, 21 Mar 2014 09:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com;
l=17336; q=dns/txt; s=iport; t=1395418740; x=1396628340;
h=from:to:subject:date:message-id:references:in-reply-to: mime-version;
bh=uFRvIk4/vucvSzCks5lwZixF8w6cauuxQD+xdGHNS+I=;
b=UswGnAQxZwIoejhL8B95Zd9x/qMj6O+qFRLKjVp2vFFMxKVJaRH4i6FD
5/Z9AbhxWV1RsdPTJxJJGtRTcEoCV6tpL0RM0XFPoTwXhRfgc6vegr2BV
ixKwvkfjr4DbCy3K6l00GmsEj/RjNuxAym4k2JnS/stg84Lt5JWeQXLXS E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiQGALllLFOtJV2Y/2dsb2JhbABPCoJCRDtXuWiId4EVFnSCJQEBAQQtXAIBCBEDAQEBKAchERQJCAEBBAESCRKHSgMQAQ3ISg2HCheMUoE8OBMXAQKENgSWXIFtgTKLNoVJgy2CKw
X-IronPort-AV: E=Sophos; i="4.97,704,1389744000"; d="scan'208,217";
a="311974763"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by
rcdn-iport-5.cisco.com with ESMTP; 21 Mar 2014 16:18:59 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by
rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2LGIxIa001010
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
Fri, 21 Mar 2014 16:19:00 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by
xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003;
Fri, 21 Mar 2014 11:18:59 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, "Fan,
Peng" <fanpeng@chinamobile.com>, "'Hui Deng'" <denghui02@gmail.com>,
"aeon@ietf.org" <aeon@ietf.org>, "'Ted Lemon'" <Ted.Lemon@nominum.com>
Thread-Topic: [Aeon] Collaborative network proposal
Thread-Index: Ac9E/e2F9LxhCAqLRE6sXsjuwdf/NwAEpNIA
Date: Fri, 21 Mar 2014 16:18:59 +0000
Message-ID: <CF51B2E4.234F4%eckelcu@cisco.com>
References: <913383AAA69FF945B8F946018B75898A242D9B09@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A242D9B09@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [171.68.20.16]
Content-Type: multipart/alternative;
boundary="_000_CF51B2E4234F4eckelcuciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/sAD2zYL3m8VDerhtY8lbuOTK8Dg
Subject: Re: [Aeon] Collaborative network proposal
X-BeenThere: aeon@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Enabled Open Networking \(AEON\)" <aeon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aeon>,
<mailto:aeon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aeon/>
List-Post: <mailto:aeon@ietf.org>
List-Help: <mailto:aeon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aeon>,
<mailto:aeon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 16:19:12 -0000
I agree. Network operators need ways to categorize and provide differentiated services for traffic, but relying on DPI is error prone, cumbersome, and potentially done at the expense of user privacy and application security (e.g. shared keys made available to DPI enabled middle boxes or HTTP proxies ). In the end, much more information about the user and the application are revealed than was actually needed by the network operator to achieve their goals. By eliminating reliance on DPI we reduce the incentive and justification for such practices. Cheers, Charles From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com<mailto:tireddy@cisco.com>> Date: Friday, March 21, 2014 at 5:06 AM To: "Fan, Peng" <fanpeng@chinamobile.com<mailto:fanpeng@chinamobile.com>>, 'Hui Deng' <denghui02@gmail.com<mailto:denghui02@gmail.com>>, "aeon@ietf.org<mailto:aeon@ietf.org>" <aeon@ietf.org<mailto:aeon@ietf.org>>, 'Ted Lemon' <Ted.Lemon@nominum.com<mailto:Ted.Lemon@nominum.com>> Subject: Re: [Aeon] Collaborative network proposal Hi Peng, I think DPI should be retired. In addition to the below problems you had mentioned in the draft, it’s the same problem with WebRTC where DPI would fail for signaling traffic. WebRTC framework allows any proprietary signaling to be used, so DPI/ALG will not be able to understand the control traffic (Even if middle boxes somehow magically figure to act as TLS proxy). Both home and access network will not be able to identify and prioritize the media streams. Cheers, -Tiru From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Thursday, March 20, 2014 5:20 PM To: Tirumaleswar Reddy (tireddy); 'Hui Deng'; aeon@ietf.org<mailto:aeon@ietf.org>; 'Ted Lemon' Subject: RE: [Aeon] Collaborative network proposal Hi Tiru, Yes, encrypted traffic is another supporting point. I guess it is time we consider finding a way to retire or simplify DPI functions. Regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Thursday, March 20, 2014 3:03 PM To: Hui Deng; aeon@ietf.org<mailto:aeon@ietf.org>; Ted Lemon Subject: Re: [Aeon] Collaborative network proposal Hi Hui, The other problem is that when content providers and clients move to TLS for privacy reasons, the current DPI mechanisms used by middle boxes will fail. You may want to look into http://tools.ietf.org/html/draft-eckel-aeon-use-cases-00#section-2.5.1 which discusses similar problems with CDN and possible solutions. Thanks and Regards, -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Hui Deng Sent: Thursday, March 20, 2014 7:09 AM To: aeon@ietf.org<mailto:aeon@ietf.org>; Ted Lemon Subject: [Aeon] Collaborative network proposal Hello all. We just submitted a draft to propose the concept of the collaborative network as below link: http://www.ietf.org/id/draft-fan-intarea-conet-ps-uc-00.txt Our basic ideal is that there are many similar use cases as AEON, so we post here to seek for more comments whether we could work together Here we cc to Int Area AD Ted. Thanks a lot -Hui
- [Aeon] Collaborative network proposal Hui Deng
- Re: [Aeon] Collaborative network proposal Tirumaleswar Reddy (tireddy)
- Re: [Aeon] Collaborative network proposal Fan, Peng
- Re: [Aeon] Collaborative network proposal Tirumaleswar Reddy (tireddy)
- Re: [Aeon] Collaborative network proposal Charles Eckel (eckelcu)
- Re: [Aeon] Collaborative network proposal Anton Smith
- Re: [Aeon] Collaborative network proposal Charles Eckel (eckelcu)
- Re: [Aeon] Collaborative network proposal Fan, Peng