Nils Ohlmeier's notes on Session 2

Agenda Bash

Chairs

• Majority wants to publish connect-reuse somehow
• Mr. Rosenberg is against it because it is not usefull and we should not publish non-useful standards
• Referred discussion between Mr. Rosenberg and Vijay to the mailing list

Fork Loop

Led by Robert Sparks

Even with the proposed solution you can still launch an attack when you have enough resources on the server

Proposed solution:

1. max-breath
2. limit total number of messages

• enough people care about the problem
• only a small number of people favours option 1
• even a smaller number is in favour of option 2
• Alan: only option 2 limits the number of options

Conclusion: we will try option 1 and it if refused option 2 will be tried

Essential Corrections

led by Robert Sparks

There is a Wiki with essential corrections of the basic standards

Open question: what is the format?

• write down that paragraphs should be replaced for normative changes
• non-normative text which explains the motivation
• Cristian: replace chapters
• Robert: but chapters are very long
• Jonathan: do it like with extensions; do not make a list of several small corrections
  • Robert: another proposal: cite the text which was changed
  • Jonathan: wants to get a complete document which is easily readbale and implementable by readers
  • Cullen: then we need a new 3261 document
  • Jonathan: invite fix is actually hard to read
  • Francois: a diff is too hard to read
  • Eric: wants to have an automatic way to get a final document
  • Scott: how to order the diffs
  • Robert: there will be only one diff
  • Scott: it is not mechanical soveable, the reader needs to use his brain

SAML

Led by Jeff Hodges

• ???
  • Peterson: the URIs should not be limited to HTTP+HTTPS only
  • Peterson: the proposed solution is good enough
• no by-value delivery, contravening RFC4484
  • Hannes: an end host should be able to add a SAML assertion
  • Cullen: we need to be able to deliver by refence and by value
• the WG is mostly confused
• redirection rather than proxy mode
  • Jiri: redirect is not specified enough
  • still more work on the draft is needed

eTags For Notification

Led by Aki Niemi

After adding the two presented changes release a new version 01 which should be ready for WGLC

• Jonathan: is missing the usage
• Jonathan: you dont need an option tag for this - the presence of the header should be enough
• Aki agrees and can not remember why the option tag was added
• Jonathan: why do we need a new reply code 204?
• Aki/Robert: you do not rely on the NOTIFY any more
• Jonathan: then this should be clearified
• Aki will verify that
• Rohan: surpressing the NOTIFYS is just a hartbeat, or is there another use case?
• Jonathan: could it confuse middel elements if they see only SUBCRIBE and no NOTIFYs?
• Jonathan: what happens to the state if it is not synchronzied via NOTIFYs?
• Adam: this is similar like NOTIF pause, but we should work on both
• this should be carefully verified before WGLC

UA-Driven Privacy

Led by Mayumi Munakata

GRUU and TURN should hide informations

Additionnaly the UA needs to inform proxies about privacy wish

Issue 1: what should be the privacy flag?

• Privacy: id alone is not sufficient

Issue 2: is it problematic that the proxy-inserted headers besides P-A-ID are disclosed?

• Via, Record-Route, History-Info reveal network informations

Issue 3: TURN for signaling

• this issue is no longer a problem

• Rohan: issue 1: we can not re-use the id tag - a new option tag would be helpfull
• John: proxy-require can not be used like described by Rohan - what happens if nobody in the middle follows the new tag?
• Jonathan: you can not prevent proxies add additional informations - the only solution would be proxy-require - the best is to use a new privacy-id
• Peterson: if a message has been anonymomized how can a hop later add informations

Conclusions:

• The majority sees a problem which the WG needs to work on
• The WG wants to work on UA initiated privacy
• The WG will adopt the draft for future work

Domain Certs

led by Scott Lawrence

• Rohan: according to Stephen Kents comment it seems all certificates today are broken (CN usage)
• Eker: right
• the authors believes besides some minor comments/issues this work should be ready to become a working group agenda item

Conclusion: WG consensus for solving the problem from the draft

Certificate Authentication

Led by Steve Dotson

• Rohan: split the work into smaller packets, solve them and get the results back
• Jonathan: we do not need end-to-end certificate auth - because we would re-invent TLS - what are the actuall problem we want to solve here?
• Cullen: this is about device authentication and not user authentication
• Hannes: this related to old work about device auth?!
• Dean: please bring the discussion to the mailing list

INFO Considered Harmful

Led by Eric Burger

• Adam: either provide a framework for INFO or tell them stop it
• Jonathan: first find out why people do not use the existing solutions
• Spencer: INFO is the UDP of SIP signlaing, simple but wrong
• Rohan: we do not need a document which says stop using INFO, nobody would respect it
• Francois: we need a document like this
• Roni: people use INFO because the IETF does not provide solutions for their problems
• ???: the damage is done, the mechanism which you are using with INFO are bad, stop using the mechanism - but do not state "stop using INFO"

Consensus: the WG needs to do something about INFO

• Dave: how about using new methods for new usages/scenarios without an existing solutions?
• referred to mailing list
• we do not have a consensus how to proceed

Media identity

Led by Dan Wing

• Cisco claimed IPR on this
• Cullen: how does 1234@cisco.com have a meaning at the destination? E164 number is understood; the use cases make no sense
• Peterson: interesting idea; i dont like the problem that it tries to solve;
• Francois: it is trying to address a corner case because an enterprise relies on a SBC to do its NAT traversal - the proposed solution is to drastic

Back to SIP Notes and Minutes at IETF 69

Back to notes