Hi Derek,
Yes you have captured the exposure correctly.
The question is: what is he trust model between neighbors? If the model
is
high enough then the only way for a!=b is a mistake. If the trust model
is
not high enough then a!=b could be malicious. If there is a security hole
*between* neighbors, b may be modified in transit such that a!=b.
I think that in a cooperative singaling protocol we have to assume that
there is trust between neighbors once identities have been established.
RSVP-TE provides such identity confirmation and also secures the traffic
between neighbors.
This leaves us with only the mistake, and generally we don't make
extensive
protocol changes to handle the potential for broken implementations.
Thanks,
Adrian
----- Original Message -----
From: "Derek Atkins" <derek@ihtfp.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>; <ccamp-chairs@tools.ietf.org>;
<asatyana@cisco.com>; <rrahman@cisco.com>; <lberger@labn.net>;
<dimitri.papadimitriou@alcatel.be>; <ancaz@cisco.com>;
<jisrar@cisco.com>;
<iesg@ietf.org>; <secdir@MIT.EDU>
Sent: Monday, January 15, 2007 2:56 PM
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06
Adrian,
The fact that the exchange is secured only means that you've
verified the endpoint, not the data. For example, let's say
that you and I are endpoints. I send you "a" and then I restart.
I ask for for my data, we secure the exchange (so I know that
it's you I'm talking to), and then you send me "b".
The RSVP-TE assures me that YOU sent me "b", but it doesn't
assure me that "b" == "a", what I sent originally.
Now, one way to solve this problem would be for the originating node
to put their own MAC on their data with a private key known only to
the originating node. This way when you send me "b" it wouldn't
have my own MAC on it (or the MAC would be invalid, or a timestamp
would be too old).
Maybe overkill, but if I'm trying to abuse resources I could use
the restart method to backfill my requests.
Thanks,
-derek
"Adrian Farrel" <adrian@olddog.co.uk> writes:
Hi Derek,
I think this is a good question so I am bringing it to the CCAMP list.
The bottom line would appear to be:
- The exchange between neighbors before restart was
secured by normal RSVP-TE means
- The exchange after restart is secured by the same means.
- This provides a degree of protection that the restarting
node is receiving information that it originally sent to
its neighbor.
The obvious question is, should the restarting node have some
(private) way
of authenticating that the information received on restart
originated with
it? This would presumably be some sort of cookie manufactured from
a mock-up
of the restart message that the restarting node expects to receive and
handed to the neighbor for use in the event of a restart.
Seems like overkill to me, but I'd appreciate views from the WG.
Adrian
----- Original Message -----
From: "Derek Atkins" <derek@ihtfp.com>
To: <iesg@ietf.org>; <secdir@MIT.EDU>
Cc: <ccamp-chairs@tools.ietf.org>; <asatyana@cisco.com>;
<rrahman@cisco.com>; <lberger@labn.net>;
<dimitri.papadimitriou@alcatel.be>;
<ancaz@cisco.com>; <jisrar@cisco.com>
Sent: Friday, January 12, 2007 10:59 PM
Subject: draft-ietf-ccamp-rsvp-restart-ext-06
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
I don't see any issues in this document beyond those already stated
in the Security Considerations.
My only question to the authors would be how does a recovering node
verify that the data it gets from a peer node really came from the
recovering node? Right now it just seems to have to trust that the
peer returns valid data.
-derek