Hi John, I personally think your conclusions are correct. One comment I have is regarding From and To headers. It's possible that the comment is a bit ahead of time as this draft is not yet aimed at the solutions, but I believe that when we come to a solution, the endpoints themselves should enforce some rules on the From and To headers if they want to support end-to-end identity. For example, the endpoints should not (or MUST not) place an IP address in these fields if they request end-to-end identity to be enabled. Making this a requirement on the endpoint behalf would help coping with the dilemma of the intermediate device as to whether or not it should break the identity.
Thanks, Gilad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Elwell, John Sent: Tuesday, March 03, 2009 6:47 PM To: SIP List; Cullen Jennings; Jon Peterson Subject: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important Draft 03: http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 includes for the first time an analysis of changes to SIP requests by B2BUAs (section 8). Also the Conclusions (section 9) have been extended. I and a number of people who have assisted in revising this draft would like to seek consensus on a number of the points. We aim to ask these questions in San Francisco, but obviously it would help to get opinions from the list in advance. 1. Tolerance to changes of certain elements as a SIP request is forwarded through intermediate domains. Section 8 analyses a number of elements of SIP messages that are signed by the present RFC 4474 solution to end-to-end (or near end-to-end) authenticated identification. For some elements it claims that any solution for end-to-end authenticated identification needs to be tolerant of changes by intermediate domains, since there appear to be valid reasons why B2BUAs (including but not limited to SBCs) change these elements. Picking on some of these: A) Is there agreement that a solution needs to be tolerant of changes to IP addresses and ports in c- and m-lines in SDP? In other words, that intermediate domains can legitimately modify these fields (e.g., for media steering) and a solution is needed for end-to-end authenticated identification in such circumstances? B) Is there agreement that a solution needs to be tolerant of changes to Contact (addr-spec), Call-Id (call-id) and CSeq (digit) header fields? In other words, that intermediate domains can legitimately modify these fields (e.g., for topology hiding) and a solution is needed for end-to-end authenticated identification in such circumstances? C) Is there agreement that a solution does not need to be tolerant of changes to the addr-spec of From and To header fields? In other words, that intermediate domains should not modify these fields and can expect to break end-to-end authenticated identification if they do so? 2. Are people in broad agreement with the conclusions in section 9 concerning the importance of end-to-end identification and in particular end-to-end authenticated identification? John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
