Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 23 Jan 2007 18:09:42 -0000

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

----- Original Message ----- 
From: "Sam Hartman" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 23, 2007 2:44 AM
Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06

>>>>>> "Sandy" == Sandy Murphy <[email-masked]> writes:
>
>    Sandy>    [email-masked], [email-masked], [email-masked],
>    Sandy> [email-masked], [email-masked]
>    >> 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: [email-masked]
Date: Tue, 23 Jan 2007 20:26:50 +0100

adrian - if this i-d has to be revisited wrt to the trust model
it implies there are a couple of other items that would fall in
to the same category

hence, the point is the following can we share that discussion
(i mean the off-line one) such as to assess the rationale and
arguments that led sam to this conclusion

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
23/01/2007 19:09
Please respond to "Adrian Farrel"
 
        To:     <[email-masked]>
        cc: 

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.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Jan 2007 00:42:11 -0000

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
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" <[email-masked]>
To: "Derek Atkins" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
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" <[email-masked]>
To: "Derek Atkins" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
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" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>
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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>
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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Brungard, Deborah A, ALABS" <[email-masked]>
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

===

> proposed trust model is justified.

===

From: "Sam Hartman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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" <[email-masked]>
To: <[email-masked]>; "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 23, 2007 2:59 PM

>>>>>> "Adrian" == Adrian Farrel <[email-masked]> 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" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
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" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 23, 2007 6:09 PM

> If anyone want to see the contents of this discussion, please shout.

===

From: "Ross Callon" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
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.