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

From: Bob Briscoe <[email-masked]>
Date: Sun, 28 Nov 2004 23:00:28 +0000

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

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Tue, 30 Nov 2004 11:23:12 -0500

I would use - as you also mention - IPsec RFCs as a guideline.  RFC2402 
says "MUST discard" if the ICV test fails.  In the same spirit, if 
'TESLA verifications' fail, the MSEC-SRTP-TESLA spec should say that the 
receiver MUST discard packets.

The other guideline I would cite is from Section 4.4 of RFC 2401,

"compliant implementations need not match details of this model as 
presented, but the external behavior of such implementations must be 
mappable to the externally observable characteristics of this model."

Given all that, and if the TESLA spec says "MAY" then some receivers 
might end up with a different copy of the stream than others, with all 
implementations being "RFC-compliant"; and that is unacceptable!

regards,
Lakshminath