Subject: Re: [Int-area] Your availability for a pre-WGLC document review

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Sep 2010 22:33:15 -0400

[Christian asked that we bring the review discussion to the list, with 
all context.  Thus, I am sending my reply, based on Francois' comments 
on my review, to the list with all context.]

Unfortunately, with regard to the arguments for their being a difference 
between Router Alert and BGP, I think one could reasonably disagree with 
all three points in the document.  I am not sure it is worth arguing, 
since whether the distinction in this dimension is real or not does not 
change the point of the document.  And the point of the document is 
quite well taken.  The three points you list are, simplified, core 
isolation, information termination, and configured peerings.

Given that there are not clear distinctions in practice between core 
routers and edge routers (there are routers that are primarily for 
internal use, and routers that are primarily for peering use, and 
routers that are primarily for customer facing use, but the distinctions 
all get blurred), I am not sure the first point in this portion of the 
document works.

The second point, while apparently accurate, does not match teh reality 
of issues that have been observed where incorrect information can get 
propagated through the BGP system, causing quite widespread problems. 
(The details vary from case to case, but the point is that many kinds of 
problems have managed to spread.)

The argument for their being less of na issue since peerings are 
configured is probably true.  However, given that the security 
mechanisms currently are deployed in very weak fashions (keys basically 
never change, for example), there are still very similar vulnerabilities 
there.

Yours,
Joel

On 9/13/2010 4:29 PM, Francois Le Faucheur wrote:
> Hello Joel,
>
> Thanks for your comments. Thoughts embedded:
>
> On 13 Sep 2010, at 21:43, Joel M. Halpern wrote:
>
>> This document appears to be in good shape. I do have one minor
>> concern, and one quibble.
>>
>> THe minor concern is that the document implies that encapsulating
>> packets with IP options is easily done and a general answer. It is
>> easily done when MPLS is used across an administrative domain. With
>> conventional IP networks, knowing where to send such an encapsulated
>> datagram is not so easy. For the MPLS case specifically, it works, and
>> works well. Could some clarifying text be added to distinguish these
>> two case.
>
> Agreed. The two cases will be distinguished..
>
>>
>> The quibble is with the description of how safe BGP is from these
>> attacks. I believe the text is over-optimistic relative to the degree
>> of protection available with current BGP.
>
> The current text does not intend to make statements about how safe or
> unsafe current BGP is.
> It only aims at explaining why Router Alert has a few additional
> security concerns beyond those that exist with other (commonly deployed)
> scenarios also involving opening up a hole in routers control plane
> (like BGP is doing).
>
> Is there any specific statement that contrast BGP security with RAO
> security that is not correct?
>
> Thanks
>
> Francois
>
>>
>> As I said, other than those two issues, the document looks good.
>> Yours,
>> Joel M. Halpern
>>
>> On 9/12/2010 2:20 AM, Christian Vogt wrote:
>>> Fred, Joel, and Suresh:
>>>
>>> The Intarea working group has a deliverable,
>>> draft-ietf-intarea-router-alert-considerations [1], which we believe
>>> is near-ready for working group last call. However, before initiating
>>> the last call, we would like to get some experts to review the
>>> document. Would you be able to provide such a review?
>>>
>>> Many thanks in advance! Please send your comments to the Intarea
>>> working group mailing list.
>>>
>>> - Christian
>>>
>>>
>>> [1]
>>> http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations
>>>
>>>
>
> *
> Francois Le Faucheur*
> *Distinguished Engineer*
> *Corporate Development*
> [email-masked] <mailto:[email-masked]>
> Phone: *+33 49 723 2619*
> Mobile: *+33 6 19 98 50 90*
>
>
> 	
>
> *Cisco Systems France*
> Greenside
> 400 Ave de Roumanille
> 06410 Sophia Antipolis
> France
> Cisco.com <http://www.cisco.com>
>
> 	
>
> Think before you print.
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact
> the sender by reply email and delete all copies of this message.
>
> Cisco Systems France, Société à responsabiité limitée, Rue Camille
> Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les
> Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur
> de la publication: Jean-Luc Michel Givone.
>
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Sep 2010 23:03:12 -0500

On Sep 13, 2010, at 9:33 PM, Joel M. Halpern wrote:

> Given that there are not clear distinctions in practice between core routers and edge routers (there are routers that are primarily for internal use, and routers that are primarily for peering use, and routers that are primarily for customer facing use, but the distinctions all get blurred), I am not sure the first point in this portion of the document works.

I really wish the IETF would talk about core-facing interfaces and edge-facing interfaces than about core and edge routers. Edge-facing interfaces face customers and therefore have link speeds and policy appropriate to a customer SLA; core-facing interfaces don't, and are driven by very different requirements. In any non-trivial network, edge routers have many edge-facing interfaces and a few core-facing interfaces.

The kind of router we generally call a "core router" is probably one that has only core-facing interfaces - it directly serves no customers, but may connect to one or more peer or upstream networks. That, unfortunately, is a distinction easier made in theory than in practice.

Even that is well over-simplified. But it at least makes the attributes one might want to talk about attributes of the interface rather than of the router, which is at least technically correct at that level.

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 14 Sep 2010 14:45:52 +0200

Hello Joel,

Your considerations about the three BGP points are certainly valid. I don't think they completely invalidate the points, but certainly qualify them/tone them down.

But all the more, I really see value in relating (as objectively as possible) the security issues of RAO (which common wisdom would have you rate as utterly unacceptable) to security issues of other protocols that also open up a hole in routers control plane like BGP (which is obviously widely accepted/tolerated/put-up-with/...). This question comes up all the time and would benefit from a thoughtful answer.
  
Would it work for you if we kept the BGP discussion and enhanced it to reflect your points?
eg (in simplified form): 
	* core routers are isolated from DOS attacks on Edge routers; however, distinction core/edge is becoming blurred
	* BGP policy control would normally filter undesirable stuff; however, there are known occurrences where incorrect information did get propagated 
	* configured peers facilitate filtering from other sources; however, bad practices can result in this being compromised.
(and perhaps we can refrain from making a judgment call that the BGP issues are less "serious" and simply present the above as "considerations on the differences") 

Again, I really feel this sheds (needed) light on the topic of control plane holes (and therefore on RAO security considerations).

Thanks much

Francois 

On 14 Sep 2010, at 04:33, Joel M. Halpern wrote:

> [Christian asked that we bring the review discussion to the list, with all context.  Thus, I am sending my reply, based on Francois' comments on my review, to the list with all context.]
> 
> Unfortunately, with regard to the arguments for their being a difference between Router Alert and BGP, I think one could reasonably disagree with all three points in the document.  I am not sure it is worth arguing, since whether the distinction in this dimension is real or not does not change the point of the document.  And the point of the document is quite well taken.  The three points you list are, simplified, core isolation, information termination, and configured peerings.
> 
> The second point, while apparently accurate, does not match teh reality of issues that have been observed where incorrect information can get propagated through the BGP system, causing quite widespread problems. (The details vary from case to case, but the point is that many kinds of problems have managed to spread.)
> 
> The argument for their being less of na issue since peerings are configured is probably true.  However, given that the security mechanisms currently are deployed in very weak fashions (keys basically never change, for example), there are still very similar vulnerabilities there.
> 
> Yours,
> Joel
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 20 Sep 2010 16:45:02 +0200

HI,
Just resending (earlier "send" used an incorrect alias for the Intarea WG).
Cheers
Francois

On 20 Sep 2010, at 16:36, Francois Le Faucheur wrote:

> Hi Fred,
> 
> Thanks much for the review. Some thoughts (& historical background on the I-D) embedded: 
> 
> On 14 Sep 2010, at 08:02, Fred Baker wrote:
> 
>> 
>> On Sep 12, 2010, at 1:20 AM, Christian Vogt wrote:
>> 
>>> Fred, Joel, and Suresh:
>>> 
>>> The Intarea working group has a deliverable, draft-ietf-intarea-router-alert-considerations [1], which we believe is near-ready for working group last call.  However, before initiating the last call, we would like to get some experts to review the document.  Would you be able to provide such a review?  
>>> 
>>> Many thanks in advance!  Please send your comments to the Intarea working group mailing list.
>>> 
>>> - Christian
>>> 
>>> 
>>> [1] http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations
>>> 
>> 
>> 
>> I believe that the document is close to being ready for WGLC, but I have one suggested edit and one thought that the working group can deal with according to its taste.
>> 
>> I think the BGP discussion in the document is extraneous to the primary topic, which is a certain option. Joel's comments, while on target for the BGP discussion, are extraneous to anything related to that option. This suggests to me that the BGP discussion should be removed - it is an interesting comparison and contrast, but to the extent that it draws attention away from the option it fails the document's primary purpose.
> 
> As indicated in response to Joel, my personal preference would be to refine the statements as needed and keep this analysis/comparison in.  We're almost there in terms of refining the statements to make them accurate and I do see a lot of value in this comparison: "why is OK to open up a control plane hole for BGP and not for Router Alert?" is a question that everyone asks or should be asking; so may as well help answer it.
> 
> But, this is just my take. It would be good to get more opinions.   
> 
>> 
>> Regarding the option, it does serve a very real purpose, which is to enable network devices on a unicast or multicast path through the network that may or may not have every router en route configured to use a certain protocol let that protocol inspect and modify the datagrams. The original case was RSVP, whose PATH message is directed from source to destination and needs to be inspected and updated by the RSVP processes en route. It has also been picked up by other control plane protocols such as IGMP. The issues were and I believe still are that 
>> (a) not every interface on the path will have the protocol enabled, which means that it is insufficient for control plane processes to simply emulate the routing of datagrams - the next hop router will in many cases not be in a position to process the message;
>> (b) those interfaces on the path that need to process the message cannot simply flip a few bits and pass it along - there is more processing required, and in many cases the next message is in fact generated by the process in question, not simply forwarded.
>> 
>> I will quibble a point; while the original implementation of the router alert was to punt the packet to a central processor, the real point is to punt the packet to a place that can do control plane processing. One could imagine that being on the line card or somewhere else. 
> 
> In an earlier version (draft-rahman-rtg-router-alert-considerations-01), the document explored exactly these sort of thoughts and included specific suggestions/recommendations about how to implement Router-Alert. This was discussed and the conclusion of the RTG Working Group was that, while interesting, those erred on the "implementation specific" side and did not belong in this document and instead should be replaced by more generic recommendations.
> 
>> 
>> In any event, it would be useful to have in the document recommended requirements for a replacement technology. The document says what about the mechanism is doesn't like (and argues the case effectively); it should also state what characteristics an acceptable replacement technology should have. Simplistic statements that force the protocol in question to fail one or both of the points above will be of little real value.
> 
> In an earlier version (draft-rahman-tg-router-alert-considerations-00), the document explored potential alternative/replacement technology. This was discussed and the conclusion from the RTG Working Group was to separate discussion on current situation versus discussion on alternatives (in part because it was urgent/feasible to close on description of current situation, while it was less-urgent/far-from-clear-that-we-could-reach-any-concensus on whether/what should/may be done in the future).
> The material we had regarding "acceptable replacement technology" was moved out into a standalone I-D: draft-narayanan-rtg-router-alert-extensions-00.
> 
> 
> Cheers
> 
> Francois
> 
> 
> Francois Le Faucheur
> Distinguished Engineer
> Corporate Development
> [email-masked]
> Phone: +33 49 723 2619

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Sep 2010 02:02:55 -0400

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 20 Sep 2010 10:36:19 -0400

Hi Fred,

Cheers

Francois