[VIPR] Minutes for 2011/09/30 conference call

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

VIPR Design Team conference call on Friday September 30th, from 9:05am to 9:55am
PST.

o Attendees:
  Mary Barnes
  Hakim Mehmood
  Muthu Arul Mozhi Perumal
  Jon Peterson
  Marc Petit-Huguenin
  John Ward
  Dean Willis

o Regrets:
  Daryl Malas
  Michael Procter

o Agenda

- - Security section of -overview (5 min)
- - SIP Intermediaries (10 min)
- - Capabilities (10 min)
- - RELOAD registration (5 min)
- - PVP privacy (10 min)
- - PVP method priority and registration (10 min)
- - PVP method entropy (10 min)
- - Replacement ticket by client certificate (10 min)
- - Ticket renewal (10 min)
- - Infrastructure overlays (5 min)

o Action items

- - Mary will send an improved text for the -overview Security Considerations
section to the mailing-list.
- - Marc will send an email describing the problem and use cases for SIP
intermediaries.

o Minutes

- - Security section of -overview

Marc: Mary published a new version of the -overview document.  Security section
still need some work.

Mary: My impression is that it's 80% there.  Not sure what it's in there will
get us past AD security review.

Hakim: Any concern on the test of phone numbers?

Mary: The idea of the attacker claiming phone numbers as its own was part of the
concerns that Richard Shockey brought forward.

Dean: There is potential for denial of service by claiming a lot of numbers.

Hakim: The idea with VIPR is that you bring your own resources.  There should be
a way for the overlay to reject excessive requests.

Mary: Does RELOAD handle that?

Dean: The fundamental problem with RELOAD is that someone can dedicate 10000's
CPU to mess up the overlay.  But that's a RELOAD problem, not a VIPR problem

Hakim: DHTs perform better as more nodes are added.

Dean: Only if those nodes are performing correctly.

Hakim: It's an attack on performance.

Jon: In the security section we must be careful to enumerate the limitations of
the system. One thing that is missing is the property of the token that is
carried in SIP. What are the protocols that are securing the actual network
interaction, e.g. TLS. Should list the counter-measures, for example for the
phone number mechanism it would be a combination of the overlay validation
mechanism and the generation of the SIP token.

Marc: The methods that are described in -pvp are just examples, and the security
of these should be deferred to the document where they are defined.

Mary: It's OK to point solution in other documents but we need to be sure that
we have a comprehensive security overview.

Jon: Is there an authentication problem, is there an integrity problem?  Then
saying that there is a token in this other draft.

Marc: So who want to contribute?

Mary: I can make a pass at the modifications suggested and send it to the
mailing-list.

- - SIP Intermediaries

Marc: We agreed on the previous call that SIP intermediaries should not be only
for toll bypass, but to improve the SIP situation.  I put a proposal together
and this proposal is to carry both the SDP to the PSTN gateway (aka SIPconnect
profile) and the SDP with SIP enhanced feature (aka SIPbeyond, which could be
defined in collaboration with RTCWEB) in a multipart/alternative body.

Jon: I am not initially a huge fan of this.  We want to keep VIPR as close as
possible to standard SIP.  As said in the previous call, the high level solution
is to be clear that VIPR is intended to provide feature transparency.  If you
just provide a great PSTN service, then you should not be doing this.

Marc: I agree 100%, but what VIPR domains who want to participate should do?

Hakim: I agree with Jon, the original intent of VIPR was to use SIP has is. I am
not sure there is a good solution. One of the approach is to collect all the
routes you can and then use a policy to choose one, a policy could be to choose
the route that have the best features, or your policy could be to choose the
least cost.

Marc: It's a different topic.  It is not about choosing the best route, but for
intermediate VIPR domains on an outgoing call.  We all agree that a domain that
is not improving SIP should not participate.  The question is what do we do when
an intermediate want to do the right thing.

Jon: Same answer that I gave last time, if we do that, we completely missed what
we want to do with VIPR.  Any entity that is advertizing a route to an endpoint
should doing so only if it is a route to the features of the endpoint.

Dean: It's almost a denial of service on the intent of VIPR.

Jon: We want to have a story to how VIPR is gonna work with federations, but I
see that as a distant goal for us.  I am not saying that intermediaries should
not participate, but we need to understand how to work with this kind of systems.

Marc: We all agree on this, but we are not proposing a solution.  I think that
we should not exclude intermediaries, and I disagree that we should do this
later.  If we exclude them then we will not have enough participants.

[The next 15 minutes of audio recording are lost.  Next call will have one more
recording point to prevent this to happen again.  Sorry for that]

Jon: ...we should not give up on the idea that we can have one route per phone
number provisioned in your VIPR entity.

John: We should definitively talk more about this.  For us to know as a
provider, a carrier, the capabilities of a given endpoint is something that will
be more and more possible.  So having a route to an endpoint at this capability
level is something that we really want support.

Jon:  If it is desirable for an endpoint to defer to an upstream entity, it's
perhaps possible to have a kind of negotiation.  There is other ways than
forcing this complexity.

John: Your issue is that it is the endpoint that should decide based on all the
entities that reported back.

Jon: I am trying to deal with the issue which is how do you deal with sending a
SIP INVITE that there is multiple places it could land and how do you build the
richest connection features.  How does an INVITE will reach the entity with the
richest feature, which is not a trivial problem to solve.

John: Unless each of these routes are reporting their supported feature set.

Hakim: But intermediaries will not really know.

John: I am not convinced that's a valid assumption. Suppose that a provider
knows the features supported by the devices.  Why shouldn’t this provider been
able to participate in VIPR?

Hakim: OK, but what about an entity one step further?

John: They shouldn't be advertizing it.

Hakim: Then how do you prevent it?

John: If you do not allow the proxy, then you can never, ever, have non-VIPR
players play with VIPR federations.

Hakim: I am not suggesting that. Everybody should publish, but we need to have a
way to pick the right route.

Marc:  Sorry to interrupt, but we are running out of time.  I will send another
email only describing the problem, and use cases. But we need discussion on the
mailing-list to accelerate decisions.

- -- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6JzewACgkQ9RoMZyVa61euoQCeIKs3wfKt18UGiSzGIKs87LVU
lfUAnR6eihekvGGixAumXYF82kr9jKJ0
=G+WT
-----END PGP SIGNATURE-----