Subject: RE: [UM] SNAP - next steps

From: Shapira Noam <[email-masked]>
Date: Thu, 6 Mar 2003 19:37:04 +0200

Eric,

What you are basically saying is that if we do a complete security
definition in the draft - it will be suitable as an internet protocol?

NS

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]] 
> Sent: Friday, February 28, 2003 9:47 PM
> To: Shapira Noam
> Cc: [email-masked]
> Subject: RE: [UM] SNAP - next steps
> 
> 
> Here is the key issue that I am stuck on:
> 
> Original Message From: Shapira Noam 
> [mailto:[email-masked]] Sent: Tuesday, February 
> 25, 2003 9:22 AM [snip]
> > 2. Where the Messaging server and the Notification server 
> are provided 
> > by the same service provider but not necessarily the same 
> manufacture 
> > (e.g. both servers are held by service-provider.com  but the email 
> > server is from Email-SW-Vendor1 and the notification server is from 
> > Notification-SW-Vendor2
> >
> > The difference is clear. The first option probably needs to handle 
> > more issues like: 1. Security / Privacy
> > 2. Provisioning / Subscription 
> > 3. User Profile (user identification) 
> > Etc. 
> 
> I would offer that situation 2 is explicitly not the kind of 
> protocol the IETF publishes.  The issues listed for situation 
> 1 ARE the issues listed that a real Internet solution needs 
> to address.  I would liken this situation to the one raised 
> by the Security Considerations draft from the IAB 
> <http://www.ietf.org/internet-drafts/draft-iab-sec-cons-03.txt
>.  From the draft:

   Internet protocol designers cannot safely assume
   that their protocols will be deployed in such an
   environment [a walled garden], for three reasons.
   First, protocols which were originally designed
   to be deployed in closed environments often are
   later deployed on the Internet, thus creating
   serious vulnerabilities.

   Second, networks which appear to be topologically
   disconnected may not be. One reason may be that
   the network has been reconfigured to allow access
   by the outside world. Moreover, firewalls are
   increasingly passing generic application layer
   protocols such as [SOAP] or [HTTP].  Network
   protocols which are based on these generic
   protocols cannot in general assume that a firewall
   will protect them.

Although the second paragraph is speaking specifically about firewalls, I
would offer the issues are identical for notification protocols.  Protocol
proposals, to be an IETF protocol, must address INTERNET requirements.

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 14 Mar 2003 10:08:48 -0500

In mathematical terms, that would be "necessary, but not sufficient."

The protocol must fully address security.  In addition, it needs to scale, work through firewalls and NATs, work over IPv6, and not choke on IDN (to name just a few).  That said, you get almost all of that from using http.

It is very important to NOT make simplifying assumptions about the connectivity between servers that will break the "works in all situations" nature of Internet protocols.

-----Original Message-----
From: Shapira Noam [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 12:37 PM
To: Eric Burger
Cc: UM list
Subject: RE: [UM] SNAP - next steps

Eric, 
What you are basically saying is that if we do a complete security definition in the draft - it will be suitable as an internet protocol?
NS 
   Internet protocol designers cannot safely assume 
   that their protocols will be deployed in such an 
   environment [a walled garden], for three reasons. 
   First, protocols which were originally designed 
   to be deployed in closed environments often are 
   later deployed on the Internet, thus creating 
   serious vulnerabilities. 
   Second, networks which appear to be topologically 
   disconnected may not be. One reason may be that 
   the network has been reconfigured to allow access 
   by the outside world. Moreover, firewalls are 
   increasingly passing generic application layer 
   protocols such as [SOAP] or [HTTP].  Network 
   protocols which are based on these generic 
   protocols cannot in general assume that a firewall 
   will protect them. 
Although the second paragraph is speaking specifically about firewalls, I would offer the issues are identical for notification protocols.  Protocol proposals, to be an IETF protocol, must address INTERNET requirements.
-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/um_archive/maillist.html