Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 13 Jul 2006 12:00:55 -0400

Inline... 

> -----Original Message-----
> From: David Schwartz [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 10:05 AM
> To: Uzelac, Adam; [email-masked]
> Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate
> 
> So here are my two cents (just repeating what I said at the session)
> 
> My claim which was not directly rebuffed is why 
> authentication is any different than any other policy issue. 
> As far as I can tell there are 2 not 3 issues that need to be 
> resolved for peering to occur.
> 
> 1. Where is the other side
> 2. Can we communicate
> 
> If we focus on the second issue it includes things like
>  
> * Will the other side even accept a call from me
> * Assuming other side will accept my calls
> *    Which authentication mechanism do I use for this 
> communication- if
> any
> * what are the ground rules for communication (e.g. specific codecs)
> * etc.
> 
> I think of federations as shared namespace NOT policy. 

I disagree.  My view of federation is having a shared policy, ie. rules
of engagement some of the most important ones center around security and
trust, and independent of namespaces.

The policy is about having a common denominator, such that you are
guaranteed that you share at least one code, share at least one security
mechanism, in order to assure that the communication will go through.

> Federations are comprised of one namespace and multiple 
> policy federations describing the relationships between the 
> members. This is why for the life of me I cannot understand 
> why it is not ok with me to peer with A via TLS and with B 
> with IPSec and with 3 with no authentication at all.
> Authentication is just a policy decision and should NOT be mandated.

If more than one mechanism is agreed to be supported, there is not
reason that you couldn't do that.

> I know everybody will yell at this but to me making ANY 
> security mechanism mandatory is tantamount to making a 
> minimal codec set mandatory and we know how this list reacted 
> when that was proposed. 

Mandatory to support, not necessarily use.

> If any member is dumb enough not to implement TLS or IPSec or 
> some other security mechanism he will soon find that no one 
> will accept traffic from him and implement it then.

Even if A did only TLS and B did only IPSEC, what would be the point of
them being in a federation together?

> We do not have to mandate not being STUPID. 

But, we do need to mandate certain things so that we don't do something
stupid.  :)

Mike

> 
> Cheers,
> 
> David
> 
> -----Original Message-----
> From: Uzelac, Adam [mailto:[email-masked]]
> Sent: Wednesday, July 12, 2006 9:44 PM
> To: [email-masked]
> Subject: [Speermint] TLS, etc - Local-policy versus WG mandate
> 
> Pertaining to the "To TLS or not TLS" discussion in the WG 
> sessions, time didn't permit a proper tomato tossing session 
> at the WG session - but one comment was made about mandating 
> such things as TLS, etc - to which a rebuttal was made that 
> the type of authentication and authorization used and 
> implemented is an issue of local policy and therefore 
> shouldn't be mandated.  
> 
> For fear of starting a "great taste" versus "less filling" 
> argument - Let me start this way....I agree with what 
> appeared to be consensus in the WG session that there needs 
> to be first a Discovery procedure, then an Authentication 
> procedure, and finally connecting the call.  The methods upon 
> which each step along the way is done should not to so narrow 
> as to exclude popular and in some cases widely adopted methods.
> Speermint should provide the BCP - but does that really need 
> to exclude other plausible and practical models?  It's 
> important to note that I believe TLS is the most appropriate, 
> practical and logical approach.  I also believe the there are 
> valid reasons for other approaches to authenticate.  The same 
> holds true for methods of discovery. 
> 
> So the question for the group and possibly some guidance from 
> the chairs here?!?!? - Should an undertaking to determine 
> what should be determined via local policy versus mandated 
> via 'MUSTs' be done?  Is this a section for the requirements doc?
> 
> I would like to thank Rohan for bringing this issue to the 
> forefront in a lightning-rod manner!! ;)
> 
> Regards,
> 
> Adam
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Jul 2006 12:08:16 -0400

inline

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Thursday, July 13, 2006 9:01 AM
> To: David Schwartz; Uzelac, Adam; [email-masked]
[[Reinaldo]] 

For this very reason you stated. A can be reached by TLS directly or
through B for those that implement IPSec. 

In other words, a federation does not need only to provide a common
denominator but can also provide more choices as the sum of the parts.

Wouldn't that be valuable?

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 18:21:17 +0200

>Wouldn't that be valuable?

maybe, but we also should obey KISS

Richard

________________________________

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Do 13.07.2006 18:08
An: Michael Hammer (mhammer); David Schwartz; Uzelac, Adam; [email-masked]
Betreff: RE: [Speermint] TLS, etc - Local-policy versus WG mandate

inline

[[Reinaldo]]

---

From: "David Schwartz" <[email-masked]>
Date: Mon, 17 Jul 2006 13:05:43 +0300

I seem to be getting a lot of heat for suggesting the independence of
namespace resolution and policy (including security). What I keep
hearing is that there needs to be a minimal set of requirements (a.k.a.
Prime Directives :-) ) for communication (hence the security
requirements) for "what is the point of knowing where the other party is
it cannot be reached".

By extension this model MUST assume that communication in a federation
MUST be symmetric. Both parties MUST be able to initiate communication
to each other. If not, than the one who cannot initiate, in essence
"knows" where the other party is but cannot communicate, hence violating
one of the prime directives of federations.

This is downright silly. As you will see in the "use case" I am in the
process of writing there are complete valid models of federations where
this is not the case. Take for example the case of a "closed" club where
all members want to RECEIVE traffic only from members of this closed
club. One or more of these members may want to additionally SEND traffic
to a wider audience while still receiving traffic from only the closed
club (why this would happen is discussed in my use case draft). The
closed members would need to know where the "open" members are to
initiate this communication. By sharing namespace this can be
accomplished since all numbers (closed and open) can be known to all
members (closed and open) and yet calls originating in closed network
would be allowed out based on receiving member policy and calls
originating in open network would not be allowed into closed club,
again, based on receiving party policy.

While you may argue that this is a case of peering between two
federations the underlying model still mandates asymmetric signaling
capabilities and hence my preference for a federation definition
comprised only of a single shared namespace with provisions for
sharing/informing/negotiating policy.

Cheers,

David

---

From: Daryl Malas <[email-masked]>
Date: Mon, 17 Jul 2006 17:28:35 -0600

Comments in-line...

> requirements) for "what is the point of knowing where the other party is
I'm not sure I'm following you here...We have already defined these
independently in the peering architecture draft.  These have been
defined as the Location Function and Operation Function (providing
policy).

> one of the prime directives of federations.

This is not necessarily true.  Although, it may take place in this
manner, policy and routing can take place at varying levels.  It may
take place within the peers network, the federation, or some undefined
hierarchical level.  In other words, if a LF within the peers network
identifies the routing of a specific call goes beyond the federation,
then it will send it to that signaling function beyond the federation.
Why would it depend on the federation to deal with all of its
routing...this architecture does not assume the peer (operator, vsp,
etc.) relinquishes all policy and routing functions.  This architecture
provides only routing and policy information for the federation and
perhaps peering between the federations.  If the peer sends all calls
(essentially relinquishing its own policy and routing) to the federation
LF and OF, then it very well may end up with many 404's, 401's, 503's,
etc...failed call attempts.

> again, based on receiving party policy.
This describes the ability for a peer to be a member of multiple
federations, right?!  In this case, you would likely access varying
LF's, SF's, and OF's, relative to the varying federations to communicate
as has been defined.  We have not ever said an operator may only be a
member of one federation.

> sharing/informing/negotiating policy.
My primary rebuttal is this can be solved in many ways...should we
define all of these, which would simply take away an operator's own
routing creativity and flexibility?  ...or, should we define principle
functions, which may be implemented to enable peering in manners that
enable greater creativity and flexibility in peering?

My two cents...thanks!