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
--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available