Subject: [speermint] requirements draft submitted

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 22 Jun 2006 07:09:54 -0600

An initial draft of the speermint wg requirements is now available at:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00
.txt

Jean-Francois.
[email-masked]

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 22 Jun 2006 14:24:37 -0400

Hello Francois,

Comments on your draft

"2.3.  No blocked calls"

I think the title of this subsection should be changed to something else
since blocked calls (just like normal IP packets) can always happen due
to call limits, QoS, white/black lists, etc, etc

I think there is a distinction on what can be achieved in terms of
static vs. dynamic data available. The data is DNS is static and does
not reflect that state of the network. Actually since DNS is an out of
band mechanism, it does not even guarantee that your layer 3 peering
connections are up.

"Per-service provider opt-in
   without consultation of a centralized 'peering registry', but rather
   by publishing local configuration choices only is highly desirable."

Not sure I understand the connection between the first and second
phrases. Did you mean "Instead of a per-service...., providers should
publish"? 

Or is the first option acceptable?  Personally I think that tackling the
(N^2) problem is very important but there will certainly be deployments
where providers prefer a centralized registry (intra federation calls
could be an example).

"2.5.  Independence of lower layers

   The system needs to be independent of details on what technologies
   are used route"

Which "system" do you refer here? I think independence is very important
but not sure it is totally achievable. I guess it depends how it is
worded. For example, see my comments to the no blocked calls above.

"2.7.  Minimal additional cost on call initiation

   Since each call setup implies execution of any proposed algorithm, it
   should incur minimal overhead and delay, and employ caching wherever
   possible to avoid extra protocol round trips."

We should mention that caching brings with it security problems. I can
foresee similar attacks like "SIP/URI" cache poisoning, etc

"2.8.  Look beyond SIP"

Good point. Although SMTP and SIP have different needs in terms of delay
and security.

"3.3.  Media-related requirements"

It seems to me media related requirements as you stated come into play
_if_ somebody is using a media relay. Otherwise the decision is between
the endpoints and we do not care/it is out of scope right?

For example,

"   o  the support of the VoIP metric block as defined in RTP Control
      Protocol Extended Reports [RFC3611] MAY be supported."

Between which entities? I'm assuming you mean between media relays since
if it is between the endpoints we really do not care/it is out of scope,
right? 

I think media requirements strictly related to speermint could be QoS
across the fabric and discussed in the list and stated in the message
flows draft and maybe some requirements in terms of control vs data
routing.

"3.4.  Security requirements

   All SIP messages MUST be sent over TLS [RFC3546] to provide
   transport-layer security as defined in RFC 3261,"

Giving the fact that we can have security through physical segregation,
intra-federation/provider calls, etc, the "MUST" here seems too generic.

I think we should say something like "in the case of public on-demand
peering SIP messages...."

Good draft.

Thanks,

Reinaldo

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Thursday, June 22, 2006 6:10 AM
> To: [email-masked]
> Subject: [speermint] requirements draft submitted
> 
>

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 23 Jun 2006 15:56:13 +0200

> Comments on your draft

Some comments from me as well.

> to call limits, QoS, white/black lists, etc, etc

I agree with you on call limits and QoS as these are dynamic variables
which are hard to avoid. On the other hand white/black lists are
configuration issues and in that case I think we should try to avoid
sending INVITES to someone who per configuration does not want to talk
to us.

> band mechanism, it does not even guarantee that your layer 3 peering

Wait a second. We're talking about requirements here. The DNS may be 
part of the solution but need not be. The requirement just states
that you should not blindly try to send SIP invites without having
good reasons to think that the call will get through.

If you do your peering using special layer 3 connections, then
this requirement means that you should synchronize your SIP stack
with your layer 3 state. I.e.: don't bother generating SIP
packets if the IPSEC tunnels are down.

Or if you do some sort of SUBSCRIBE/NOTIFY to establish peerings, then
you shouldn't send INVITES unless the last notify you received 
gave you a green light.

> phrases. Did you mean "Instead of a per-service...., providers should

Yes, that sentence is broken.

What about:

"A VSP opt-in by publishing local configuration choices is preferrable
to a centralized 'peering registry'."

> where providers prefer a centralized registry (intra federation calls

Agreed, within federations such registries could be fine. I doubt that
such registries can scale to the inter-federation (that is: global
reachability) case.

Such a global registry might be possible on technical grounds, but
in terms of politics and economics this is not feasible. 

Who would every VSP trust to run that global registry?

> worded. For example, see my comments to the no blocked calls above.

"system" here stands for the world-wide peer discovery system.

The algorithm to find peers should be independent of how you
talk to that peer. 

> foresee similar attacks like "SIP/URI" cache poisoning, etc

What about some generic security requirement? (independently of caching)

> Good point. Although SMTP and SIP have different needs in terms of delay

Yes. If you look e.g. at MMS which are transmitted via SMTP you might
find similar requirements in terms of security.

[...]
> peering SIP messages...."

Agreed.

IMHO the Speermint work falls into two separate areas:

* Federation discovery & routing

  This needs to be a global standard.

* Intra-federation peering rules

  In theory each federation could write its own rules. 
  Speermint should provide a best practice document for that.

> Good draft.

yes.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >