RE: Last call feedback: draft-mm-wg-effect-encrypt

<Badri.Subramanyan@ril.com> Wed, 15 March 2017 11:20 UTC

Return-Path: <prvs=240434f47=Badri.Subramanyan@ril.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4293A129BBB; Wed, 15 Mar 2017 04:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 k1FTI_iZjwsj; Wed, 15 Mar 2017 04:20:22 -0700 (PDT)
Received: from gwsmtp010.ril.com (unknown [203.199.41.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866FB129BAB; Wed, 15 Mar 2017 04:20:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.36,168,1486405800"; d="scan'208";a="378324604"
From: Badri.Subramanyan@ril.com
To: acmorton@att.com, kathleen.moriarty.ietf@gmail.com, saag@ietf.org, ietf@ietf.org
Subject: RE: Last call feedback: draft-mm-wg-effect-encrypt
Thread-Topic: Last call feedback: draft-mm-wg-effect-encrypt
Thread-Index: AQHSmEkdymufh+be8EG0ggEJbV3WwqGMUL1AgAD0g4CAB0r5AIABOrxA
Date: Wed, 15 Mar 2017 11:20:11 +0000
Message-ID: <0d728d3f894c4d0a9f16bd6a21088818@SIDC1EXMBX24.in.ril.com>
References: <CAHbuEH4+bd=0PJa1rWDQN6tbeRK5vXKdbcUwsj2=zf9V8ejeDg@mail.gmail.com> <c056c07568974f37aa0366bbe8a93422@SIDC1EXMBX24.in.ril.com> <4D7F4AD313D3FC43A053B309F97543CF25F3252D@njmtexg5.research.att.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F3252D@njmtexg5.research.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/VHn8iu_kF-m6Wt_wRRHZRUAQCTg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 11:20:24 -0000

Al,

	In my experience, protocol has been the 5th tuple along with Source and Destination IP address and ports.

Thanks,
Badri

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] 
Sent: Tuesday, March 14, 2017 5:01 PM
To: Badri Subramanyan <Badri.Subramanyan@ril.com>; kathleen.moriarty.ietf@gmail.com; saag@ietf.org; ietf@ietf.org
Cc: stephen.farrell@cs.tcd.ie
Subject: RE: Last call feedback: draft-mm-wg-effect-encrypt

Hi Badri,
one follow-up question below:

> -----Original Message-----
> From: Badri.Subramanyan@ril.com [mailto:Badri.Subramanyan@ril.com]
> Sent: Friday, March 10, 2017 2:35 AM

<snip>

> > If the streams are encrypted, then the ALG feature would be rendered
> 
> > useless. This would limit the capability of any network element to
> 
> > make smart policing and routing decisions based on application layer
> attributes.
> 
> 
> Kathleen wrote:
> Do you know if these can work with a 2-tuple or 5-tuple?  Is there an 
> impact from encryption via TLS for instance?  If so, what is that 
> impact?
> 
> [Badri] The rules in most of the cases is 5-tuple to accurately depict 
> a flow. Yes, there is an impact from encryption via TLS as most of the 
> implementations of ALG get information regarding supporting protocols 
> by parsing data. With TLS encryption, the ALG loses the ability to 
> parse, hence get information on the supporting protocols.
> 
> 
> Kathleen wrote:
> What is used by ALG to correlate streams?  This would be helpful to 
> understand if this particular method for ALGs does become 'useless'
> and also to figure out if other options may exist to perform the 
> functions needed.
> 
> [Badri] RFC 2663, Section 2.9 gives information about ALG. There isn’t 
> one defined method to implement it and some of the methods used by 
> vendors are included below.
> 
> 1.  Parse the content of the primary stream and identify the 5-tuple 
> of the supporting streams as it is being negotiated.
> 
> 2. Intercept and modify the 5-tuple information of the supporting 
> stream as the it is being negotiated on the primary stream. This is a 
> little more intrusive in nature.
> 
> 
[ACM]
After Src&Dst Address and Port, what is the 5th Element of the 5-tuple in your experience?

Protocol number and Packet Priority Marking (DSCP) are two candidates...

let us know, thanks!
Al

"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."