IETF Logo Mail Archive

Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 18 July 2013 19:58 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBA411E81CE for <int-area@ietfa.amsl.com>; Thu, 18 Jul 2013 12:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.489
X-Spam-Level:
X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 iswl0INefKMw for <int-area@ietfa.amsl.com>; Thu, 18 Jul 2013 12:58:39 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE3C21F9EF2 for <int-area@ietf.org>; Thu, 18 Jul 2013 12:58:39 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id bg2so7067pad.32 for <int-area@ietf.org>; Thu, 18 Jul 2013 12:58:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gUNqelaCiaqSFFPFrZpXrC9CiHZd7aVIeOHhrH64J88=; b=faqAqYGxbb27mBMo+Xuk5yJOJp2ywbkvp4BushhWGATIZkziPdUVw3dLwZkAABbnVV midj2Zhtin0iKIDcTE7X1oDw9y73rtBT1wUujaxa+mTL2ht2dkZ4WHBsyxYBwKcb7x2l W+0cFYKkPUdxlc2QxpG2JsfY2pUSgR5qDfr3SniEcvaucZAycNM2ghlz0hE1aiZX90ao 8FM6Igz5RMA57SOIER9C7BzkrD+ZJfwiiIU7IUHTi0pgs484PribOzW48kKwkA218zrY Ds0TNr7tWEwkqb1fCNi1avpRFSUc+DoR2k6CP0CDvRg0DwUBQnltQBPd1FBBKPlj9909 JXSA==
X-Received: by 10.68.171.99 with SMTP id at3mr13871721pbc.64.1374177519048; Thu, 18 Jul 2013 12:58:39 -0700 (PDT)
Received: from [192.168.178.23] (127.199.69.111.dynamic.snap.net.nz. [111.69.199.127]) by mx.google.com with ESMTPSA id is3sm9130280pbc.25.2013.07.18.12.58.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 12:58:38 -0700 (PDT)
Message-ID: <51E848F4.9010003@gmail.com>
Date: Fri, 19 Jul 2013 07:58:44 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <94C682931C08B048B7A8645303FDC9F36EE2DDB4FE@PUEXCB1B.nanterre.francetelecom.fr> <45A697A8FFD7CF48BCF2BE7E106F0604090C8510@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE2DDB59F@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE2DDB59F@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2013 19:58:40 -0000

On 19/07/2013 00:11, mohamed.boucadair@orange.com wrote:
...
>>> How to trust the data sent by an application? These are examples of
>>> points which should be further discussed in the document.
>>
>> [RP] I think this depends on the transport. Some transports like PCP or
>> STUN have some built-in authentication.
> [Med] The question is not whether a secure transport is used or not but to what extent the flow description is accurate (e.g., send fake flow description, systematically request treatment with higher priority, etc.).

This of course is why the diffserv model assumes that traffic will
be reclassified at domain boundaries, since you can't trust what your
neighbour tells you about QoS requirements. This proposal would be no
different in the general case; flow metadata needs to be trustworthy.
If not it will be a recipe for theft of service or DoS.

Why is this an intarea topic? To my mind it fits in tsvwg, which is
currently discussing things like QoS for rtcweb.

   Brian

v2.23.0 | Report a Bug | By Email