Subject: [ANCP] Handling of Transaction ID sequence errors in the base protocol

From: Tom Taylor <[email-masked]>
Date: Wed, 1 Dec 2010 21:41:13 -0500

I have been creating updated text presenting fuller descriptions of 
Result Code handling than currently exist in the -12 version. I am using 
the following template:

Code value:
One-line description:
Where condition detected: (control application or ANCP protocol layer)
Further description (if any):
Required additional information in the response message:
Target: (control application or ANCP protocol layer at the peer that 
sent the original request)
Action required by the receiving ANCP protocol layer:

For a couple of errors, like wrong Partition ID or Transaction ID out of 
sequence, I had renegotiation of the adjacency as a remedy. However, 
this seems a little drastic and is a nice point of leverage for denial 
of service attacks.

For Transaction ID sequence errors in particular: the primary purpose is 
to correlate requests and responses. Security comes into the discussion 
if we want to prevent blind injection attacks or replay attacks. We can 
probably rule out blind injection attacks by requiring source 
authentication for each message, so that just leaves replay attacks.

If the end receiving a request encounters a Transaction ID sequence 
error, the sensible thing is to inform the sender of the request so the 
sender can verify that it was the one that sent the request.

So far so good -- that's what happens with the current text. But what if 
the problem is a state mismatch between the sender and the receiver of 
the request? We need a graceful way of updating state at the receiver. 
Should this take the form of some sort of housekeeping message, a new 
TLV in a regular message whose semantics are "I really mean this 
Transaction ID, please believe me", or what?

Suggestions anyone?

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Fri, 3 Dec 2010 15:31:54 -0500

Thinking about this and doing a little research, I've realized that:

  - RFC 5713 discusses threats, attacks, and security requirements, but 
we haven't presented a security solution. Without this the document will 
never be accepted by the IESG. An obvious solution is to require 
transport over TLS. What do others say?

  - It probably isn't reasonable to make the receiver monitor 
Transaction ID values as part of the security solution. There are 
cheaper ways to protect against replay attacks. Hence I propose dropping 
the "Transaction ID out of sequence" error.

  - As a result, the text describing the Transaction ID in section 4.6 
can be simplified, but text has to be added saying what to do if a 
response with an unknown Transaction ID is received.

On 01/12/2010 9:41 PM, Tom Taylor wrote:
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp
>
>