Discussion:
[P2PSIP] Stephen Farrell's No Objection on
Stephen Farrell
2016-04-19 21:05:36 UTC
Permalink
Stephen Farrell has entered the following ballot position for
draft-ietf-p2psip-sip-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- 5.1: I guess it's too late to ask, but I'll ask
anyway, just in case this hasn't yet been implemented
and it's not too late... I can see why you want to
support SIP URIs and can't e.g. only support SIPS URIs
here. But in supporting SIP URIs couldn't you have
taken an opportunistic security approach to using TLS
and e.g. maybe treated a SIP URI as if it's a SIPS URI
except for the certificate validation step? I do get
that that might restrict re-use of unmodified SIPS
stacks but maybe that'd be ok in this context. Any
chance of considering that or is it too late or a case
where there's not enough energy/interest? (EIther form
of "no" is a very reasonable answer.)

- Just out of curiosity, are folks deploying this
anywhere?
Thomas C. Schmidt
2016-04-19 21:43:26 UTC
Permalink
Hi Stephen,
Post by Stephen Farrell
----------------------------------------------------------------------
----------------------------------------------------------------------
- 5.1: I guess it's too late to ask, but I'll ask
anyway, just in case this hasn't yet been implemented
and it's not too late... I can see why you want to
support SIP URIs and can't e.g. only support SIPS URIs
here. But in supporting SIP URIs couldn't you have
taken an opportunistic security approach to using TLS
and e.g. maybe treated a SIP URI as if it's a SIPS URI
except for the certificate validation step? I do get
that that might restrict re-use of unmodified SIPS
stacks but maybe that'd be ok in this context. Any
chance of considering that or is it too late or a case
where there's not enough energy/interest? (EIther form
of "no" is a very reasonable answer.)
I guess, something similar to opportunistic security is actually
happening on the RELOAD overlay. All links are (D)TLS encrypted. Further
security additives are out of scope for the moment, I would be tempted
to say.
Post by Stephen Farrell
- Just out of curiosity, are folks deploying this
anywhere?
The whole P2PSIP story is suffering from a much delayed standards
process (it started in 2006). For example, we had a joint implementation
with Deutsche Telekom and quite a number of others had efforts, too. All
this seems quite a while ago. Currently, we are more on finishing the
work that unfortunately had circulated way too long in the WG.

Cheers,
Thomas
--
Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °
Stephen Farrell
2016-04-20 09:53:30 UTC
Permalink
Hi Thomas,
Post by Thomas C. Schmidt
Hi Stephen,
Post by Stephen Farrell
----------------------------------------------------------------------
----------------------------------------------------------------------
- 5.1: I guess it's too late to ask, but I'll ask
anyway, just in case this hasn't yet been implemented
and it's not too late... I can see why you want to
support SIP URIs and can't e.g. only support SIPS URIs
here. But in supporting SIP URIs couldn't you have
taken an opportunistic security approach to using TLS
and e.g. maybe treated a SIP URI as if it's a SIPS URI
except for the certificate validation step? I do get
that that might restrict re-use of unmodified SIPS
stacks but maybe that'd be ok in this context. Any
chance of considering that or is it too late or a case
where there's not enough energy/interest? (EIther form
of "no" is a very reasonable answer.)
I guess, something similar to opportunistic security is actually
happening on the RELOAD overlay. All links are (D)TLS encrypted. Further
security additives are out of scope for the moment, I would be tempted
to say.
Post by Stephen Farrell
- Just out of curiosity, are folks deploying this
anywhere?
The whole P2PSIP story is suffering from a much delayed standards
process (it started in 2006). For example, we had a joint implementation
with Deutsche Telekom and quite a number of others had efforts, too. All
this seems quite a while ago. Currently, we are more on finishing the
work that unfortunately had circulated way too long in the WG.
Understood. In that case, I'm fine with you not trying to polish
it more.

Cheers,
S.
Post by Thomas C. Schmidt
Cheers,
Thomas
Loading...