RE: [EME] Requirements

Paul Francis <francis@cs.cornell.edu> Mon, 18 June 2007 21:28 UTC

Return-path: <eme-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OmB-0006gt-Ge; Mon, 18 Jun 2007 17:28:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OmA-0006gj-Jw for eme@irtf.org; Mon, 18 Jun 2007 17:28:42 -0400
Received: from mail-hub-2.cs.cornell.edu ([128.84.103.139] helo=exch-hub2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Om9-00033j-9b for eme@irtf.org; Mon, 18 Jun 2007 17:28:42 -0400
Received: from exchfe2.cs.cornell.edu (128.84.97.34) by mail-hub.cs.cornell.edu (128.84.103.140) with Microsoft SMTP Server id 8.0.700.0; Mon, 18 Jun 2007 17:28:40 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 17:28:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [EME] Requirements
Date: Mon, 18 Jun 2007 17:28:32 -0400
Message-ID: <E6F7A586E0A3F94D921755964F6BE006C9806C@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <4676E1A9.3080701@gmx.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [EME] Requirements
Thread-Index: Acex4cbo+IwTZZZ9QMekpki5p3TU8gADWn4Q
From: Paul Francis <francis@cs.cornell.edu>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, <eme@irtf.org>
X-OriginalArrivalTime: 18 Jun 2007 21:28:35.0703 (UTC) FILETIME=[A0D60870:01C7B1EF]
Received-SPF: None (mail-hub.cs.cornell.edu: francis@cs.cornell.edu does not designate permitted sender hosts)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc:
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Errors-To: eme-bounces@irtf.org

These are good comments.  Will go through them carefully and respond.  Will
try to have an updated version by the July 9 cutoff.

PF 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Monday, June 18, 2007 3:49 PM
> To: eme@irtf.org
> Subject: [EME] Requirements
> 
> Hi all,
> 
> I went through the requirements document and here are some comments:
> 
> REQ-2: Middleboxes MUST be able to authenticate endpoints, 
> and endpoints MUST be able to authenticate middleboxes that 
> they are aware of.
> 
> [hannes] It may be sufficient to authorize the end point 
> without authenticating it.
> 
> REQ-4: The Internet MUST allow anonymous communications 
> (policy permitting).
> 
> [hannes]  This requirement is in conflict with REQ-2.
> 
> REQ-5: The Internet MUST allow endpoints and middleboxes to 
> protect confidential information, and reveal it only to 
> trusted parties when necessary. Confidential information may 
> include endpoint names, network addresses, authentication 
> tokens, encryption keys etc.
> 
> Endpoints must not be required to reveal their network 
> address to untrusted middleboxes and endpoints. Network 
> addresses must be made available after authentication and 
> authorization as the address can be used to direct a DoS 
> attack to a bottleneck link.
> 
> [hannes] I guess the confidentiality protection refers to an 
> adversary model with a middlebox being trusted and evil guy 
> being somewhere in the middle. Right?
> The two paragraphs don't fit together. How would I prevent my 
> network address from revealing to the middlebox?
> 
> 3.6.  Protocol Negotiation
> 
>    REQ-8:  Endpoints MUST be able to negotiate the protocol 
> stack for a
>            flow subject to application requirements and relevant
>            endpoint and middlebox policy.
> 
>    Endpoints may require or prefer datagram delivery (UDP, DCCP) or
>    reliable stream delivery (TCP, SCTP), with or without encryption
>    (TLS, IPSec), with or without compression etc.  Not all 
> endpoints may
>    have support for all protocols.  New protocols may be implemented
>    that endpoints would like to negotiate.
> 
> [hannes] If I want to use TLS with a web server then I don't 
> want todo a protocol negotiation with a middlebox that tells 
> me not to use it. The firewall can reject a firewall pinhole 
> to be created. Is that what you want to accomplish?
> 
>    REQ-9:  Multi-homed endpoints and middleboxes MUST be allowed to to
>            specify the route(s) to use for a flow.  The Internet MUST
>            allow multiple routes to be used simultaneously.
> 
> [hannes] Why does an end point want to control the routes 
> through a network? Why do I care?
> 
> 3.5.  Steering, Anycast, and Mobility
> 
>    REQ-7:  Endpoints and middleboxes MUST be able to redirect flows to
>            alternate endpoints, addresses or through alternate routes.
> 
> [hannes] This functionality may be provided by a NAT 
> automatically when you are able to install NAT bindings. I 
> read through the section and I wasn't quite sure what you todo.
> 
> Sections 3.9 and 3.10 contain only requirements that don't 
> provide too much insight. Every requirements document contain 
> them but they provide very little help for the protocol designer.
> 
> Please try to avoid writing "The Internet MUST ..." when the 
> document is about requirements for a protocol.
> 
> 
> Ciao
> Hannes
> 
> 
> _______________________________________________
> EME mailing list
> EME@irtf.org
> https://www1.ietf.org/mailman/listinfo/eme
> 

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme