Notes for SIP WG session, IETF 66, 1300 10.7.2006

Reported by Bruce Lowekamp

Blue sheets distributed

Dean announces note takers, finds a reluctant Jabber user

standard note-well announcement

Rohan Mahy removes lens cap

Discussion of aboreal rodents ensues upon presentation of the agenda

discussions of GRUU review.  Only two confirmed via email that they

had read it and are currently looking for more to review.

Henning raises question about number of drafts awaiting WGLC, number

of drafts not at that point, and whether there is a prospective

completion date.

James Polk: reviewing milestones, can location be earlier than

December?  Yes, as long as it can be adequately reviewed.

Dean: Chair polls

Does Certs have any actual issues:

confirm presence of a squirrel (conclusion from list poll)

open question to room: does anyone have issues

Jonathan Rosenberg: who plans on implementing?  four or five separate

implementations, no one arguing against

connection reuse:

generally favorable, but two who thought it had no value, then one

changed their mind and said it was good.

Jonathan Rosenberg: reviewed connection reuse and can't see how it solves a

problem.  purports CPU overhead benefit, which he doubts, and doesn't

work in a lot of circumstances.

Outbound:

Has a squirrel, but it looks stuck (discussion of picture of

dead-looking squirrel).  There are apparently open issues, so we will

discuss.

Gonzalo presentation on problem with compression and record-route

presentation:

Rohan Mahy: outbound-04 open issues

Jonathan Rosenberg: 3489bis mentions issue with forged STUN binding response

messages.   Is this really an amplification attack?  Especially

compared to problems with multiple responses to a single request

already needed by SIP.

Jonathan: can't do it faster than the registration rate

Rohan: according to current outbound draft, can be done as fast as CPU

allows

Cullen: don't care if we reapply the existing timer mechanism but

don't introduce new ones.  There are better attacks.

Rohan: offers beer for a better attack

ekr: http://www.usenix.org/events/sec03/tech/bellardo.html

next issue: dhcp unable to configure outbound properly

Sparks: add option to solve with proxy-require

Rohan: doesn't allow you to discover, allows to validate

Francois: go forward

Bob Pennfield: will eventually fix with register response, anyway

next issue: validating stun support

Sparks: proxy-require outbound would solve this problem

Hirsham: agree with proposal

Jennings: any objections must explain why different than LR problem

Jonathan Rosenberg: no opposing combatants are here.  this will have to go to

the mailing list.  we should ask for positive assents.

Jennings: how will the chairs ask to call for consensus on this?

Hadriel Kaplan: every other extension has a way to reject, this one

doesn't.

discovery:

Dean: for those who have read the relevant portions of the draft and

believe that it should proceed with no changes, please raise hand.

about 20:4 in favor of proceeding without changes

Bob Pennfield: if put keepalive=stun into service route in the

response, will be happy

Jonathan: agrees with mechanism, but thinks will be complicated enough

to not want to hold up document at this point

validating:

Dale Worley: third option on validating slide would render discovery

moot (don't send stun until validated OK through parameter in

reflected path)

Rohan: group question:

first option: is the existence of a keepalive=stun in UA configuration

sufficient to allow transmission of stun without further validation and progress

document with that assumption?

no clear consesus with very few responses

alternatively: require validation beyond keepalive=stun

third: hold up document

Bob Pennfield: it's the service providers, not the implementers who

have a problem with this.

general discussion

Rohan: key problem is you shouldn't configure a phone with

keep-alive=stun and then assume that will work anywhere

Jonathan: add words of caution and admonition, but then let document

go forward

Hisham: will this break the UAS?

Rohan: biggest problem is the misconfigured device DOSing itself when

using TCP

Sparks: this draft was much clearer than the last and enough people

are getting into it that we will have substantive discussions and need

to focus on getting this out.

Rohan:  do we now have rough consesus to go forward?

chairs: no

how many flows:

Jonathan Rosenberg: SHOULD must have caveat that violation can kill reliability

Dale: fine, but can't say "does no harm"  because single flow causes

more aggressive reregistration avalanche problems

how to verify edge proxy support:

Sparks: what happens when edge proxy supports outbound but registrar

does not

Rohan: no need for changes

re-registering vs replacing flows:

Adam Roach: keeping flows is very bad with amplification

Rohan: do people who feel they understand this issue still feel

uncomfortable with the registrar being allowed to replace flows?

no voice of support for having MUST NOT replace flows

all hands in support for SHOULD replace flows

SHOULD vs MUST:

SHOULD: some

MUST: more

OBJECT TO MUST: one

OBJECT TO SHOULD: more

Dean: rough consensus on MUST

Presentation:

Miguel Garcia on outbound discovery

Jonathan Rosenberg: concerned that getting k of N from a DNS starts to fail with

the DNS design.  Proper choices can't be expressed in DNS (choose one

of first two and one of second two).  DNS is too static.

Jonathan: concerned on impact on mid-dialog

Miguel: should this ID be adopted?

Dean: should take question to mailing list

Sumanth Channabasappa

mid-dialog request routing with outbound

Jonathan and Rohan discuss that GRUU may be a further complication

Dean: there is consensus that mid-dialog routing is an issue, but no

consensus on what the solution is.  individuals should continue

working

Vijay Gurbani

Connect-Reuse

Vijay: Dean's facial hair is good

ekr: is Dean from the evil alternate universe?

Vijay Gurbani

Certs

ekr: TLS is designed to work with specific names, stop with

wildcard certificates

ekr: in TLS all servers MUST use same name.

Jon Peterson: Not a wildcard issue.  The certificate must match whatever

is in the address.  Must provide the domainname for which it actually

has credentials.

Derek MacDonald: multiple names/two certificates solves this nicely

Jennings: unless we have a use-case for subordination, let's not worry

about it

ekr: as a matter of security, the name you're connecting too much

match the security.  If you want to steer to a specific proxy, then

you need to have a second name in the cert or a wildcard.  Or the

route can specify the domain to be authenticated with.

Jon Peterson: if you're contacting alice@atlanta.com the host should have

the atlanta.com certificate.  if it's alice@downtown.atlanta.com it

should be downtown.atlanta.com

Brian Rosen: conversation should end since wildcards *.example.com can

be issued.  the problem is already solved

chairs: we still have the question of whether connect-reuse solves any

real-world problem if we solve the cert problem

Jonathan Rosenberg: solves no real-world problems

Jennings: have never received a response to his statement that it

doesn't work in terms of virtual servers.  want to see the text.