Subject: RE: Comments (RE: [speermint] requirements draft submitted)

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 27 Jun 2006 14:05:23 -0600

Hi Reinaldo,

You wrote:
> 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 agree. How about URI reachability based on the current txt?

> 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.
Not necessarily true. 
While global DNS may have some lag, it is dynamic. It is part of common
DNS operations to actually reduce TTL in some DNS records just before
doing maintenance work on target servers to limit reachability issues
due to DNS caching, then do the maintenance and crank the TTLs back up
once the network is "more stable".

> 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. 
Me neither.

> 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).
This sentence in 2.4 is taken from the original draft and should be
clarified. I understood it as follows:
Publishing local configuration choices is highly desirable and
preferable over per-service provider opt-in without consultation of a
centralized 'peering registry'.

But even then, it is not clear to me what is meant... more work &
refinements are needed here.

> "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.
Agreed. 
Proposed new text: 
s/system/session peering 
   at least for now and until we have a function name from the
archictecture doc?
   Session peering SHOULD be independent of lower layers and the
technologies used to route the call...

> "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
-> security consideration section: add txt on the implications of
caching?

> "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?

It seems to me that VoIP interconnect is ultimately about exchanging rtp
packets (be it audio payloads or comfort noise).

> 
> 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?

This goes back to a problem in the current draft: requirements apply to
several types of entities.

> 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 tend to differ on this: it is not because you have lower layer
security (presumably hop by hop security associations) that you should
relax the end-to-end transport security requirements. 
Rohan's well written draft is also in favor of mandatory support of TLS,
and so is the SIP Forum's IP PBX to VSP (here is a working link:
http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_Inte
rop-sibley-final.pdf).
May be the requirement should be rewritten to put the MUST on SIP
entities involved in L5 peering. 

How do others feel on this?

Thanks for your comments.
Jean-Francois.

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Jun 2006 17:12:04 -0400

segregation,

<brian>I'm in favor of requiring TLS.  I'd say MUST in a heartbeat.

Brian

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 27 Jun 2006 20:27:00 -0400

TLS for _all_ scenarios? Even in private peerings, physically secure
peerings, etc? 

Isn't that the same as requiring IPsec for all layer 3 peering? But
since Layer 5 peering might be more distributed, the number of TLS
sessions would be huge.

It would be good to hear the provider's opinion on this...

Thanks,

Reinaldo

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, June 27, 2006 2:12 PM
> To: 'Jean-Francois Mule'; Reinaldo Penno
> Cc: [email-masked]
> Subject: RE: Comments (RE: [speermint] requirements draft submitted)
> 
> >

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 27 Jun 2006 20:44:28 -0400

I am not a provider yet, but I think we dont need to mess with
TLS/TCP. As I understand one of the goals is to prevent the calls from
failing due to "peering only" reasons. This means that things like
codecs which are not negotiated by the peers need to be mandated at a
minimal level. TCP/TLS can be negotiated between the peers themselves
so it is a non-issue. Also as I still understand doing a high volume
calls with TLS is still expensive. Mandating TLS in cases where the
caller or callee dont require it doesnt seem to add any value.

-Medhavi.

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 27 Jun 2006 21:47:37 -0400

TLS is becoming more and more a subject when the topic of SIP
interconnections arises for me professionally.  This shows growing
momentum indeed.  With that said, I can not agree with TLS as a
steadfast requirement.  Economics and scale are my major concerns.  TLS
adds cost, server load, and there are fail-over issues to consider as
well.  For the person that designs an interconnect, I believe weighing
the cost against the benefit of the different models a useful exercise.
Mandating TLS, even if all parties involved in a peering arrangement
feel somehow "safe and secure" due to underlying security mechanisms
(L2/L3VPNs, etc), seems a little harsh.  

Adam

-----Original Message-----
From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 8:44 PM
To: Reinaldo Penno
Cc: [email-masked]
Subject: Re: TLS for peering (was RE: Comments (RE: [speermint]
requirementsdraft submitted))

I am not a provider yet, but I think we dont need to mess with TLS/TCP.
As I understand one of the goals is to prevent the calls from failing
due to "peering only" reasons. This means that things like codecs which
are not negotiated by the peers need to be mandated at a minimal level.
TCP/TLS can be negotiated between the peers themselves so it is a
non-issue. Also as I still understand doing a high volume calls with TLS
is still expensive. Mandating TLS in cases where the caller or callee
dont require it doesnt seem to add any value.

-Medhavi.

On 6/27/06, Reinaldo Penno <[email-masked]> wrote:
> > security (presumably hop by hop security associations) that you 
> > should relax the end-to-end transport security requirements.

---

From: Daryl Malas <[email-masked]>
Date: Wed, 28 Jun 2006 09:28:03 -0600

I agree with Adam's assessment.  Requiring TLS is simply not realistic
at this point.  I believe it has the potential of becoming a more common
practice in the future, but not right now.

--Daryl

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 29 Jun 2006 10:09:15 -0400

<apologies for sporadic replies, I'm traveling with intermittent access>
This us a PEERING system with federations.  The likelihood of a persistent
TLS connection being maintained is high, and the cost of establishing a new
one is relatively low, especially if, as on another thread, one of the
things a federation means is a CA signing certs for use by the federation.
The number of peers is going to be relatively low, improving the probability
of the persistent TLS connection being available.

Brian

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 9:48 PM
To: Medhavi Bhatia; Reinaldo Penno
Cc: [email-masked]
Subject: RE: TLS for peering (was RE: Comments (RE:
[speermint]requirementsdraft submitted))

Adam

-----Original Message-----
From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 8:44 PM
To: Reinaldo Penno
Cc: [email-masked]
Subject: Re: TLS for peering (was RE: Comments (RE: [speermint]

-Medhavi.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 29 Jun 2006 12:34:48 -0400

Hummm....I'm not sure about that. It depends on many factors.

First and foremost it depends on which model you embrace: p2p/email or
federations. In the email model the number of TLS connection will be
considerable. 

In the federations model it depends on the scale of the federations.
I've been told that there are some 3000 carriers in the US and 8000
public traded companies alone

This does not count the million of end users that might get their own
domain and run a Sip Proxy. 

Regards,

Reinaldo

> Sent: Thursday, June 29, 2006 7:09 AM
> To: 'Uzelac, Adam'; 'Medhavi Bhatia'; Reinaldo Penno
> Cc: [email-masked]
> TLS connection being maintained is high, and the cost of establishing
a
> new
TLS/TCP.
> > > Rohan's well written draft is also in favor of mandatory support
of
> > TLS,
http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_In
> > te