Re: [Dime] Draft minutes available

[Ben Campbell <[e-mail]>]

On Mar 16, 2013, at 9:50 PM, Jouni Korhonen <[e-mail]> wrote:

> Folks,
> 
> Please verify the draft minutes from the meeting:
> http://www.ietf.org/proceedings/86/minutes/minutes-86-dime
> 
> There are few missing parts there and it would be nice that
> those who said something during the meeting on mic would
> check if everything has been captured.
> 
> - Jouni & Lionel
> 
> ps: a huge thank to (again) Jean for taking minutes!!

Hi,

I have a few minor comments and corrections for the draft minutes:

-- in the overload-reqs discussion:

> Keith - This is a requirements doc, thus no one will implement this. The MUST constrains the working group on the solution doc. There is no problem with text here. MUST vs SHOULD - we want to say MUST here. If there's problem with the MUST, you should constrain it the following text. 
> 
> Lionel - I don't understand. There's no way to do this without a new application ID. You would need to go through dedicated proxies to do this. 

I thought Lionel was commenting that the "new application" approach for moving overload control info around wouldn't be able to solve the Req 35 (crossing non-supporting intermediaries) use case. Did I misunderstand the comment?

[...]

> Janet - The SIP overload specification has, "If it uses such-n-such, it MUST …". In the SIP solution docs, they have appendix saying how they are meeting the requirements. 
> 
> Ben - I hope we do appendices like that, too. We haven't done the engineering to see if not technically feasible. I'm ok on the SHOULD and the MUST UNLESS. However, the implementers can't implement unless its a MUST. 
> 
> ACTION: Add appendices. 
> 

I meant the my appendix comment to apply to the solution(s). That is, I hope those documents have appendixes that state how they meet the requirements.


-- overload data analysis discussion:

> slide 4 - Fundamental Differences
> 
> Hannes - The requirements doc was only a kindness. Looking at the solutions, it isn't clear what the common cases are. The scopes introduce lots of complexity. Where do you stop? What are the deployment cases for them?
> 
> Ben - Some of the scopes are required. There are also requirements on making things better, like requirement 3. 
> 
> Hannes - I'm worried about the complexity of the implementation. How to combine scopes? SDOs reuse application ids. We should extend scope to specific AVPs.
> 

Did Hannes say we "should" extend scopes to cover specific AVPs, or that we "could"? I thought his concern is that our scopes may be too complex, not that we need to add further complexity.

-- e2e security requirements, slide 3:

> Glen - we have an underlying infrastructure that is trusted. You don't really need to know where it came from, that the route is correct. We want to protect against a compromised node. If you use TLS and DTLS, don't have to worry about […]
> 
> Hannes - the threat model is an intermediary. Authentication tells you that you received from the right element. You have multiple keys would give you authentication functionality. 
> 
> Glen - I don't see a secret key flying. In theory we're using TLS, DTLS, IPSEC and public keys. In theory. We should use them instead of going to all the trouble of configuring secret keys in an N-squared environment.
> 
> Hannes - we disagree on core crypto principles. 
> 
> Ben - I'm confused by trusting a node but could be compromised.

 I further mentioned that, with integrity protection but no authentication, a compromised node could still allow untrusted 3rd parties to insert messages 

> Hannes - TLS won't get you anywhere, goes through compromised node. CRC check provides integrity by detecting errors […] You want to avoid […] You want to tie to a specific entity. Do it with integrity protection and authentication by applying key only known by both parties. 
> 

The exchange above (between Glen, Hannes, and me) was in the context of whether integrity protection is useful without authentication.