RE: [EME] Requirements

[Paul Francis <[e-mail]>]

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:[e-mail]] 
> Sent: Monday, June 18, 2007 3:49 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/eme
> 

_______________________________________________
EME mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/eme