Subject: [MSEC] RE: MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla-02.txt)

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Mon, 29 Nov 2004 15:58:06 +0100

Bob,
I would personally read the MAY that you propose in the 
sentence as if the checking of the safety condition could 
be skipped completely. 
I feel comfortable only with a MUST.
If the rx's policy wants to do something else, well 
the protocol cannot force him otherwise (as it is local 
matter), as you say.

/E

>-----Original Message-----
>From: Bob Briscoe [mailto:[email-masked]]
>Sent: den 29 november 2004 00:00
>To: Mark Baugher; Elisabetta Carrara (KI/EAB)
>Cc: [email-masked]; [email-masked]; Dondeti,
>Lakshminath
>Subject: MUST/MAY discard unverifiable
>(draft-ietf-msec-srtp-tesla-02.txt)
>
>
>Mark, Elisabetta,
>
>Returning to this subject after a long break (purely my fault)...
>
>At 19:24 14/09/2004, Mark Baugher wrote:
>
>>On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote:
>>
>>>On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote:
>>>>>5/ Discard if a packet cannot be authenticated should be optional
>>>>= Agreed
>>>
>>>I did not sign up for this one - or at least I did not mean to.  I'd
>>>like to discuss this some more.  Personally, I want to limit options
>>>wherever possible and this is the second option (including making the
>>>group [MAC] optional)
>>>that you have proposed.  I don't think we necessarily want 
>to add this
>>>particular option and would like to hear what others have to say on
>>>the matter.
>>>
>>>thanks, Mark
>
>If a packet cannot be authenticated, whether to drop it or not can be 
>chosen unilaterally by the receiver. It isn't a *protocol* 
>option. It is a 
>receiver choice. If it cannot be verified, it doesn't complicate the 
>protocol to say the receiver MAY rather than MUST drop a packet.
>
>My view remains that it is over-prescriptive to tell a 
>receiver it MUST 
>drop a packet. Indeed, whatever we say in the RFC, 
>applications will be 
>free to do what they like. The balance between the value of 
>rendering-quality and authenticity is up to the application, not us.
>
>Quoting the RFC Editor's policy:
>"...Imperatives ... MUST only be used where it is actually 
>required for 
>interoperation or to limit behavior which has potential for 
>causing harm 
>(e.g., limiting retransmissions). For example, they must not 
>be used to try 
>to impose a particular method on implementors where the method is not 
>required for interoperability."
>
>                                 ---
>
>But there *is* a potential protocol issue here (which applies to all 
>authentication protocols, IPsec as much as TESLA). 
>Application(s) 'above' 
>verification in the stack (e.g. rendering, congestion control, 
>intrustion 
>detection) may need to distinguish the difference between 
>discard due to:
>- congestion/corruption
>- proven malicious attack
>- indeterminate authentication (in TESLA due to network delay 
>*or* an attack)
>
>For intrustion detection, these can be distinguished by 
>logging different 
>types of security event, as specified in the srtp-tesla draft.
>
>But, congestion control usually works purely on packet 
>delivery (I don't 
>think SRTP says anything about whether verification is done 
>before or after 
>congestion control).
>
>Yes, proven attack packets should be discarded (after 
>logging), because 
>they aren't part of the stream sent by the genuine sender. But 
>if packets 
>can't be verified they shouldn't necessarily just be discarded:
>- If they were genuine packets, congestion control will 
>respond wrongly if 
>they *are* discarded
>- If they were attack packets, congestion control will respond 
>wrongly if 
>they *aren't* discarded.
>
>Of course, the same is true of rendering:
>- If they were genuine packets, rendering will respond wrongly if they 
>*are* discarded
>- If they were attack packets, rendering will respond wrongly if they 
>*aren't* discarded.
>
>So, in order not to complicate the spec, I still maintain we 
>should say (in 
>section 4.4)
>
>
>"...If the safe condition does not hold, the packet MAY [not MUST] be
>    discarded, and the event SHOULD be logged."
>
>
>
>In these cases, it is up to the receiving system to decide 
>whether such 
>packets are more likely to be genuine or malicious, choosing 
>whether to use 
>or discard the packet. With consequent consistent effects on 
>congestion 
>control, rendering etc.
>
>There is a natural tendency for security people to be 
>conservative under 
>uncertainty. But we have to remember security must be balanced 
>by usability.
>
>Bob
>
>_______________________________________________________________
>_____________
>Bob Briscoe, <[email-masked]>      Networks Research 
>Centre, BT Research
>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   
>+44 1473 645196 
>
>
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec