Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-srtp-03.txt - Questions and Comments

From: "Martin Euchner" <[email-masked]>
Date: Sun, 17 Mar 2002 22:08:10

David,

let me thank you for your explanations for the considerations around FEC and SRTP.

I now understand, that your decision on placing the FEC within SRTP is based primarily to minimize denial of service attacks. After some thinking, I agree that the three variants pointed out appear useful.

I agree that option 3 (first encrypt, then FEC and afterwards auth at sender) is best if denial of service criterion is the only objective. As an additional bonus, the SRTP authentication is able to protect the SRTP instance as well as to protect the FEC against denial of service attacks. As you described, the FEC at the SRTP layer would separate the two security operations encryption and authentication.

However, I believe that the other two variants as pointed out have their value as well.

Option 1 (1st encryption, then auth and finally FEC) has the benefit that the security operations may be realized atomic and may be closely together. The scenario covered could be such that the FEC be placed at the lower protocol layer underneath SRTP (e.g. FEC at the link level as in wireless systems). Yet, there is the risk of denial of service attacks against the FEC algorithm. Nevertheless, I consider countermeasures against such risks & threats not the primary goal of SRTP. This should actually be the task of a secure FEC.

Option 2 (1st FEC, then encrypt and finally auth) would be resistant against denial of service attacks similar as option 3. Architecturally, the FEC mechanism could be on top of the SRTP at some higher layer, while leaving the SRTP security atomic together. It is my understanding that the ULP or UXP error correction mechanisms could be viewed like such an FEC, as they introduce their own packetization format. While the FEC introduces more redundancy and make the payload longer, this should not result in any particular weakness assuming the encryption algorithm is secure.

To conclude, I see use cases for all three placements of FEC relative to the SRTP security function. I question therefore, whether there is any benefit for SRTP to restrict the number of variants and to mandate only option 3.

As a resolution, I think it is appropriate that SRTP recommends (but not mandates) option 3 when denial of service countermeasure is the concern and FEC be realized at the same layer as SRTP.

Options 1 and 2 have usage cases and their usage may be of value as well.

Finally, key management should be able to negotiate the relative placement of FEC in the protocol stack.

With kind regards,

Martin Euchner

+---------------------------------

+

+ email: [email-masked]

+

+---------------------------------

To: "Euchner Martin ICN M SR 3" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-srtp-03.txt - Questions and Comments

From: "David A. Mcgrew" <[email-masked]>

Date: Mon, 11 Mar 2002 10:46:10 -0800

Importance: Normal

In-Reply-To: <DA6599EBFD6CF042B0B77964CFF62095530100@MCHH162E>

List-Id: Audio/Video Transport Working Group <avt.ietf.org>

Sender: [email-masked]

Martin,

many thanks for your detailed comments. Below is an explanation of our
reasoning about the relative ordering of security processing and
packet-level forward error correction, and some discussion on the same.
(Mats and others will be replying to your other points separately).

> Q.20) Reference: section 11 >> The optimal order would be the
> following: -
> on the sender side, first encrypt the packet, then perform the FEC
> processing, finally authenticate <<
>
> A different order (1st authenticate packet, 2nd FEC and then
> encrypt) on the sender side would have the benefit that
> authentication/integrity could be preserved in case of FEC-correctable bit
> errors. However, this mode might expand the packet size for
> encryption. The
> trade-off might not be that significant for "short" payloads but the DoS
> risk is increased and slight redundancy is added to the plaintext.
>
> I'm not quite certain whether the order (1st authenticate,
> 2nd encrypt, and then FEC) might have a case as well (for burst errors
> perhaps?). At least this mode has the benefit of co-locating the security
> functions (authentication and encryption) together and having the FEC
> directly operate on the data portion; thus being able to re-cover
> destroyed
> RTP header fragments as well.
>
> By FEC I assume that actually a scheme is meant that applies
> error correction codes to the payload or packet but not ARQ.
>
> Further, I do not understand the notion of "optimal" since
> it does not state any constraints or criteria. I could better
> live with the
> word "suggested order" instead.
>
> Thus, all three FEC placements might occur (theoretically).
> I consider the FEC placement an issue that perhaps the external key
> management would negotiate and signal or even some other out-of-band
> signaling. A parameter might be added to the crypto context,
> stating default
> or one of the non-default orders.
>

The short answer is: we specified only one ordering of SRTP and FEC for
simplicity's sake, and our choice of orderings was perhaps somewhat
arbitrary but probably reasonable. The long answer is below.

For completeness, Let's consider all the possible orderings of
encryption/decryption (enc/dec), authentication (auth), and forward error
correction (fec) encoding/decoding. There are eight possibilities, but we
can reject options which would cause decryption to precede auth verification
on the receiver side. This is because authentication is cheaper than
decryption by as much as an order of magnitude, and we want to order the
operations in order to protect against DoS attacks. That leaves three
options, which I've listed below:

Sender Receiver
1. enc auth fec fec auth dec
2. fec enc auth auth dec fec
3. enc fec auth auth fec dec

Option #1 is vulnerable to DoS attacks against the receiver's FEC buffers.
The other options don't have this problem.

Option #2 essentially provides the attacker with lots and lots of known
plaintext, due to the linear equations used in the FEC. The other options
don't have this problem. Also, this option expands the amount of data that
needs to be cryptographically processed, increasing the computational load.

Option #3 expands the amount of data that needs to be authenticated, but not
the amount of data that needs to be encrypted. Another problem with Option
#3 is that it doesn't make the security processing atomic. The security
subsystem would need to pass data to the FEC subsystem which would then need
to return that data to the security subsystem, or the two systems would need
to be integrated.

With AES or a similarly strong cipher, the known plaintext issue of Option
#2 isn't really a problem. This leaves the tradeoffs of the FEC DoS
vulnerability versus the increased computational load. We chose Option #1
to minimize the computational load (and apparently didn't discuss the issue
well enough in the rationale). Option #2 is also perfectly reasonable. We
chose to mandate the SRTP/FEC ordering in order to reduce the complexity of
implementations, and not because Option #2 would be a poor choice.

Option #3 can be viewed as an optimization of #2. I favor not allowing this
option, as complexity and security are incompatible and this option would
add considerable complexity to an implementation, whereas the other options
can be implemented without any changes to the SRTP packet processing
definition.

If we do allow more than one option, then we'd need to provide a way to
signal which option would be in use. I suppose that SRTP could add
parameter to those passed by key management which indicated which option was
in use, though I can't vouch that this method would work with any and all
FEC mechanisms. Also, if we were to allow only Options #1 and #2, then the
changes to the existing SRTP spec would be minimal. If we were to allow
Option #3, then the changes would be much more involved; we would have to
change the packet processing algorithm to accommodate a way to send/recv
packets to and from a FEC mechanism.

I'd be glad to hear your thoughts.

thanks,

dam

David A. McGrew, Ph.D.
Manager, Strategic Crypto Development
IOS Technologies Division
Cisco Systems, Inc.
(301) 349 5815

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

Send and receive Hotmail on your mobile device: Click Here

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt