Subject: [EME] Requirements

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Jun 2007 21:48:57 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/eme

---

From: Paul Francis <[email-masked]>
Date: Mon, 18 Jun 2007 17:28:32 -0400

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:[email-masked]] 
> Sent: Monday, June 18, 2007 3:49 PM
> To: [email-masked]
> Subject: [EME] Requirements
> 
> Hi all,
> 
> 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).
> 
> 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?
> 
> [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?
> 
> [hannes] Why does an end point want to control the routes 
> through a network? Why do I care?
> 
> [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
> 
>