[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Security considerations with draft-ietf-ccamp-rsvp-restart-ext-07
Hi,
As requested here is a summary of the email exchanges with regard to
security issues in this I-D as raised in Security Directorate review and
picked up on in IESG review by Sam Hartman.
The email thread is presented in time order, oldest email first. I trust
that the originators of the emails will not feel that their conversations
are being put into the public domain egregiously.
If anyone can contribute to this debate to make suggestions on how we could
resolve this issue then that would be most welcome.
Thanks,
Adrian
====
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
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.
===
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Derek Atkins" <derek@ihtfp.com>; <ccamp@ops.ietf.org>
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>; <iesg@ietf.org>; <secdir@MIT.EDU>
Sent: Saturday, January 13, 2007 11:39 AM
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.
===
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: Tuesday, January 16, 2007 6:49 PM
True, an attacker that sits between the peers shouldn't be able to
inject messages because the endpoints are authenticated (and I
presume that the transaction itself has integrity protection).
You're correct that it is a question of the threat model, and that
if you DO have a fully trusted set of peers then you don't have to
worry about this attack. But if that's the case I'd like to see
a sentence or three in the Security Considerations section that
explicitly states this threat model. Then at least this attack
would be clearly out of scope. :)
===
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Derek Atkins" <derek@ihtfp.com>
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: Tuesday, January 16, 2007 7:36 PM
OK
We can write that sentence or three and close the issue.
Thanks for engaging.
===
From: "Sandy Murphy" <sandy@tislabs.com>
To: <adrian@olddog.co.uk>
Cc: <ancaz@cisco.com>; <asatyana@cisco.com>; <ccamp@ops.ietf.org>;
<dimitri.papadimitriou@alcatel.be>; <iesg@ietf.org>; <lberger@labn.net>;
<secdir@mit.edu>
Sent: Tuesday, January 16, 2007 4:35 PM
This leaves us with only the mistake, and generally we don't make
extensive
protocol changes to handle the potential for broken implementations.
Yes, we will always have errors, in implementation, in configuration,
in operation, we can't hope to protect against all of those, etc.
However, it is prudent to spend some time analyzing how much damage to
the protocol operation could result from a misconfigured or faulty
participant. This is important because there are also subverted
and deliberately malicious participants to worry about. You might be
willing to live with the chance of a random one-in-a-billion error
bringing
down your network, but subverted and malicious participants aren't random.
===
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Sandy Murphy" <sandy@tislabs.com>
Sent: Wednesday, January 17, 2007 12:16 AM
Hi Sandy,
Going off-list simply because it takes my emails a while to get approved
on
the SecDir list.
I agree with you completely. My question is now about how easy it is to
subvert, for example, a router. Yes, it may be possible to hack a router
and
induce odd configuration, but is it possible to subvert it? The nasty
thought of someone writing their own version of IOS and downloading it
onto
a router!
This probably brings us to a wider concern than simply MPLS-TE. What
happens
if any router running any routing protocol is subverted. Seems to me that
we
don't have an answer to this question within the IETF.
With one hat on I say: let's not hold up this I-D because of a much wider
problem.
With a different hat on I say: this is probably something that the SecDir
and RtgDir might want to sit down and thrash out.
===
From: "Sandy Murphy" <sandy@tislabs.com>
To: <adrian@olddog.co.uk>
Cc: <sandy@tislabs.com>
Sent: Wednesday, January 17, 2007 5:06 PM
I agree with you completely. My question is now about how easy it is to
subvert, for example, a router. Yes, it may be possible to hack a router
and induce odd configuration, but is it possible to subvert it?
My definition of "subverted" includes hacking into a router and changing
the configuration. It is taken over and no longer obeying the
instructions of its rightful owner, so I call it subverted.
This probably brings us to a wider concern than simply MPLS-TE. What
happens if any router running any routing protocol is subverted. Seems to
me that we don't have an answer to this question within the IETF.
Yes, the whole Byzantine participants problem gets little attention -
partly because it is really hard to address.
A protocol robust against such failures can be much "heavier", but the
approaches to adding Byzantine robustness are not generic - you don't
just add a "Byzantine robustness" layer.
But that is why I said that it would be prudent to analyze just how
bad things can get if one participant (and for extra points, more than
one participant) is faulty/misconfigured/subverted/malicious.
Until we all get smarter about protocols, doing the worst cast scenario
study at least lets you know where you have to apply administrative
controls, monitoring and alarms, etc.
===
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Sandy Murphy" <sandy@tislabs.com>
Sent: Wednesday, January 17, 2007 8:00 PM
OK, Thanks.
I am going to feed this to the MPLS Security design team, and finger you
(tee, hee, that will teach you ;-) as someone they can poll for a good
discussion.
===
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <rcallon@juniper.net>
Cc: <ccamp@ops.ietf.org>; "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Sent: Wednesday, January 17, 2007 9:14 PM
Subject: Re: New Version Notification -
draft-ietf-ccamp-rsvp-restart-ext-07.txt
Hi Ross,
This new revisions handles some issues raised during SecDir review and
copied to the CCAMP mailing list.
The changes are:
- Minor editorial clarification of the Abstract
- Repagination
- Insertion of a paragraph in Section 6
Note that the procedures assume a full trust model between RSVP
neighbors. That is, although the protocol exchanges before and after
restart can be secured, and although it is possible to authenticate
the identity of the neighbors, no mechanism is provided to verify
that the restart information is correctly mapped from the protocol
information exchanged before the restart. This is considered
acceptable because a similar trust model is required for normal
operation of the protocol.
- Addition to the Acknowledgements section
===
From: "Sam Hartman" <hartmans-ietf@mit.edu>
To: "Sandy Murphy" <sandy@tislabs.com>
Cc: <adrian@olddog.co.uk>; <asatyana@cisco.com>; <secdir@mit.edu>;
<ccamp@ops.ietf.org>; <dimitri.papadimitriou@alcatel.be>; <iesg@ietf.org>;
<lberger@labn.net>; <ancaz@cisco.com>
Sent: Tuesday, January 23, 2007 2:44 AM
"Sandy" == Sandy Murphy <sandy@tislabs.com> writes:
Sandy> asatyana@cisco.com, secdir@mit.edu, lberger@labn.net,
Sandy> ancaz@cisco.com, iesg@ietf.org
>> This leaves us with only the mistake, and generally we don't
>> make extensive protocol changes to handle the potential for
>> broken implementations.
Sandy> Yes, we will always have errors, in implementation, in
Sandy> configuration, in operation, we can't hope to protect
Sandy> against all of those, etc.
Sandy> However, it is prudent to spend some time analyzing how
Sandy> much damage to the protocol operation could result from a
I agree with Sandy here. I think that analysis of what damage can be
done by a malicious peer so that we can understand whether the
proposed trust model is justified.
===
From: "Sam Hartman" <hartmans-ietf@mit.edu>
To: <iesg@ietf.org>
Cc: <ccamp-chairs@tools.ietf.org>
Sent: Tuesday, January 23, 2007 2:47 AM
Discuss:
Based on a security review by Derek Atkins and comments from Sandy
Murphy, please help me understand why the trust model of this spec and
normal operation of RSVP is the same. In particular, what damage can
be done by a malicious peer sending back altered contents of path
messages? How could the same damage be done in the normal protocol?
It may well be that writing text to cover these issues is too
expensive. If the authors would like to discuss with me offline that
could work too. Text is of course preferred if it is relatively easy
to write because then the entire world can review our findings.
===
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <iesg@ietf.org>; "Sam Hartman" <hartmans-ietf@mit.edu>
Cc: <ccamp-chairs@tools.ietf.org>
Sent: Tuesday, January 23, 2007 10:49 AM
Hi Sam,
So the paragraph we included to help with Derek's comments is...
Note that the procedures assume a full trust model between RSVP
neighbors. That is, although the protocol exchanges before and after
restart can be secured, and although it is possible to authenticate
the identity of the neighbors, no mechanism is provided to verify
that the restart information is correctly mapped from the protocol
information exchanged before the restart. This is considered
acceptable because a similar trust model is required for normal
operation of the protocol.
You can see this in the 07 revision.
Simply put, the trust model between peers (once they are identified and
authenticated) must be full for RSVP-TE. Otherwise there are many ways
that
a malicious neighbor can really mess with its peer. For example, a
malicious
upstream LSR could pretend that it had received an LSP setup request from
somewhere further upstream and could send a Path message to its peer -
this
could cause network resources to be squandered on all downstream LSRs.
If you think about it, this hop-by-hop trust is necessary because
otherwise
every network node must have a security relationship with every potential
LSP ingress, and that cannot scale.
Again, I would prefer not to use an RSVP-TE extensions draft to document
normal RSVP-TE behavior, although I do understand that this behavior
*does*
need to be documented. It is our hope that an effort recently started in
the
MPLS working group to document MPLS security will cover all of these
bases,
if somewhat belatedly.
===
From: "Sam Hartman" <hartmans-ietf@mit.edu>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <iesg@ietf.org>; <ccamp-chairs@tools.ietf.org>
Sent: Tuesday, January 23, 2007 2:59 PM
"Adrian" == Adrian Farrel <adrian@olddog.co.uk> writes:
Adrian> Hi Sam, So the paragraph we included to help with Derek's
Adrian> comments is...
Adrian> Note that the procedures assume a full trust model
Adrian> between RSVP neighbors. That is, although the protocol
Adrian> exchanges before and after restart can be secured, and
Adrian> although it is possible to authenticate the identity of
Adrian> the neighbors, no mechanism is provided to verify that the
Adrian> restart information is correctly mapped from the protocol
Adrian> information exchanged before the restart. This is
Adrian> considered acceptable because a similar trust model is
Adrian> required for normal operation of the protocol.
This paragraph is the source of my discuss.
It makes an assertion that the damage that could be caused by changing
state
in a restart is the same as the damage that could be caused under normal
operation.
I'm asking you to validate that assertion so I can evaluate the document.
Adrian> You can see this in the 07 revision.
Yes.
Adrian> Simply put, the trust model between peers (once they are
Adrian> identified and authenticated) must be full for
Adrian> RSVP-TE. Otherwise there are many ways that a malicious
Adrian> neighbor can really mess with its peer. For example, a
Adrian> malicious upstream LSR could pretend that it had received
Adrian> an LSP setup request from somewhere further upstream and
Adrian> could send a Path message to its peer - this could cause
Adrian> network resources to be squandered on all downstream LSRs.
I agree that there needs to be some level of trust between peers in
the current protocol.
Adrian> If you think about it, this hop-by-hop trust is necessary
Adrian> because otherwise every network node must have a security
Adrian> relationship with every potential LSP ingress, and that
Adrian> cannot scale.
Mor like every network node must be able to have data origin
authentication with every potential ingress, which is a much weaker
statement. But that's not a matter of discussion for today: we're not
redesigning RSVP so we're not redesigning the hop-by-hop trust model.
We're simply trying to validate that we have not changed it.
Adrian> Again, I would prefer not to use an RSVP-TE extensions
Adrian> draft to document normal RSVP-TE behavior, although I do
Adrian> understand that this behavior *does* need to be
Adrian> documented. It is our hope that an effort recently started
Adrian> in the MPLS working group to document MPLS security will
Adrian> cover all of these bases, if somewhat belatedly.
As I said, my discuss can be resolved without text changes; I just
need to be convinced of the answer to my question. And again, I'm not
asking you to document normal RSVP procedures only to show you have
not changed them.
===
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Sam Hartman" <hartmans-ietf@mit.edu>
Cc: <iesg@ietf.org>; <ccamp-chairs@tools.ietf.org>
Sent: Tuesday, January 23, 2007 3:35 PM
Hi Sam,
Adrian> Note that the procedures assume a full trust model
Adrian> between RSVP neighbors. That is, although the protocol
Adrian> exchanges before and after restart can be secured, and
Adrian> although it is possible to authenticate the identity of
Adrian> the neighbors, no mechanism is provided to verify that the
Adrian> restart information is correctly mapped from the protocol
Adrian> information exchanged before the restart. This is
Adrian> considered acceptable because a similar trust model is
Adrian> required for normal operation of the protocol.
This paragraph is the source of my discuss.
It makes an assertion that the damage that could
be caused by changing state in a restart is the same
as the damage that could be caused under normal
operation.
No it doesn't.
It says that the trust model is unchanged.
In fact, the damage that could be done by a malicious router (not one with
subverted configuration, but one with subverted software implementation)
is
subtly different because of the different direction of the information
exchange.
I'm asking you to validate that assertion so I can
evaluate the document.
I can certainly validate the assertion made in the I-D.
When an upstream neighbor sends a Path message, its downstream neighbor
acts
on that message to establish state and cause downstream behavior that
ultimately leads to resource allocations on the downstream negihbor and
the
establishment of an LSP toward a specific destination. The downstream
negihbor trusts that the upstream neighbor has passed it a genuine Path
message for a real LSP.
When an upstream neighbor sends a Path message to its downstream neighbor
it
trusts that the downstream neighbor will not change the destination of the
LSP, but will continue to forward the essential objects of the Path
message
unchanged.
When an upstream neighbor receives a Resv message from its downstream
neighbor it trusts that message is a true reflection of the LSP that has
been established downstream and contains accurate and true instructions on
what the upstream neighbor should do.
When a downstream neighbor sends a Resv message to its upstream neighbor
it
trusts that the upstream negihbor will handle the message correctly and
will
neither modify it gratuitously nor absorb it silently.
And so on for all other RSVP-TE messages.
Thus there is a bidirectional full trust model between neighbors.
Given that the trust model is full and bidirectional, this I-D cannot
modify
the trust model.
Now, as I said, the damage you could do for any one LSP is subtly
different.
That is, during LSP setup, the maliscious LSR would have been limited to
doing damage as a recipient of a Path message and sender of a Resv. With
this I-D it is able to tell the upstream (restarting) LSR that the Path
message it sent previously was different from the one it actually sent.
What
new damage could this do?
It doesn't change any of the behavior at any downstream LSR because the
malicious LSR could already have lied in the Path message that it sent
downstream.
It doesn't change anything at the malicious LSR because that LSR is always
free to be malicious in its own way.
It doesn't change anything upstream of the restarting LSR because the
restart information is not propagated further upstream.
All it can do is tell the restarting LSR that the LSP parameters have
changed. So what?
This might cause the LSP to be torn down with some kind of state mismatch
between the existing data plane state (that survived the restart) and the
control plane state reported from the malicious LSR. If the malicous LSR
wanted to cause the LSP to be torn down, it could do it itself anyway (it
is
on the path of the LSP). The state mismatch is likely to show up as a
problem with restart so the malicious LSR will not be able to hide.
So...
Now change in trust model. No substantial change in the damage that can be
done if the trust model is subverted.
Adrian> Simply put, the trust model between peers (once they are
Adrian> identified and authenticated) must be full for
Adrian> RSVP-TE. Otherwise there are many ways that a malicious
Adrian> neighbor can really mess with its peer. For example, a
Adrian> malicious upstream LSR could pretend that it had received
Adrian> an LSP setup request from somewhere further upstream and
Adrian> could send a Path message to its peer - this could cause
Adrian> network resources to be squandered on all downstream LSRs.
I agree that there needs to be some level of trust between peers in
the current protocol.
Adrian> If you think about it, this hop-by-hop trust is necessary
Adrian> because otherwise every network node must have a security
Adrian> relationship with every potential LSP ingress, and that
Adrian> cannot scale.
More like every network node must be able to have data origin
authentication with every potential ingress, which is a much weaker
statement.
Are you supposing that the signaling data cannot be modified hop-by-hop?
Actually much of it can be changed, and some of it must be changed.
But that's not a matter of discussion for today: we're not
redesigning RSVP so we're not redesigning the hop-by-hop
trust model.
We're simply trying to validate that we have not changed it.
Given that the trust model was full and bidirectional, the only direction
for change would be to assume less trust. This I-D does not assume less
trust.
Adrian> Again, I would prefer not to use an RSVP-TE extensions
Adrian> draft to document normal RSVP-TE behavior, although I do
Adrian> understand that this behavior *does* need to be
Adrian> documented. It is our hope that an effort recently started
Adrian> in the MPLS working group to document MPLS security will
Adrian> cover all of these bases, if somewhat belatedly.
As I said, my discuss can be resolved without text changes; I just
need to be convinced of the answer to my question. And again, I'm not
asking you to document normal RSVP procedures only to show you have
not changed them.
Convinced yet?
===
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Sent: Tuesday, January 23, 2007 6:09 PM
FYI, I am having an off-line discussion with Sam Hartman during IESG
review
of this document (that has now advanced to 07) as he has raised a DISCUSS
(you can see his issues in the I-D tracker).
He is concerned that the extensions in this I-D change the trust model in
RSVP-TE, and I am trying to convince him that there is already a
bidirectional full trust model between neighbors without which basic
RSVP-TE
signaling could not work. Thus (I say) this I-D does not change the
existing
trust model although it reverses the flow of information for a specific
LSP.
Further (I say) even a malicious LSR neighboring a restarting LSR could do
very little more damage during restart than it could do during normal LSP
processing.
If anyone want to see the contents of this discussion, please shout.
Adrian
===
From: "Ross Callon" <rcallon@juniper.net>
To: <asatyana@cisco.com>; <rrahman@cisco.com>
Cc: <adrian@olddog.co.uk>; <dbrungard@att.com>;
<dimitri.papadimitriou@alcatel.be>; <lberger@labn.net>; <ancaz@cisco.com>;
<jisrar@cisco.com>; <rcallon@juniper.net>
Sent: Thursday, January 25, 2007 8:44 PM
The document "draft-ietf-ccamp-rsvp-restart-ext-07.txt" was discussed
during the IESG telechat today. As you will see from the data tracker
(let me know if you need a pointer to this), there are two DISCUSS
votes that will need to be resolved in order for this document to
progress.
[SNIP]
The other DISCUSS by Sam Hartman states:
Based on a security review by Derek Atkins and comments from Sandy
Murphy, please help me understand why the trust model of this spec and
normal operation of RSVP is the same. In particular, what damage can
be done by a malicious peer sending back altered contents of path
messages? How could the same damage be done in the normal protocol?
It may well be that writing text to cover these issues is too
expensive. If the authors would like to discuss with me offline that
could work too. Text is of course preferred if it is relatively easy
to write because then the entire world can review our findings.
I think that you need to see the security review by Derek and comments
by Sandy. Also, resolving this is likely to require an email exchange with
Sam. Let me know if you need any help resolving this.
It was not clear whether Sam's discuss will result in significant
additional
text for the document. If so, then you probably will want to add the other
text as well and do a new version.
Please let me know when you feel that you have these two issues
resolved, or if you need additional help in resolving them.