Subject: grow: draft-scudder-bmp-00.txt

From: David Meyer <[email-masked]>
Date: Thu, 10 Nov 2005 15:58:04 -0800

Folks,

	At the GROW meeting this week we took away an action item
	to ask the list to please read draft-scudder-bmp-00.txt
	and let us know whether you feel this draft should be
	adopted. Please let us know your opinion on this.

	Thanks, 

	Geoff & Dave

---

From: Shane Amante <[email-masked]>
Date: Thu, 10 Nov 2005 18:03:06 -0800

I support this draft becoming a WG draft.

It should be noted that this protocol would be useful not only to 
researchers, but also potentially to [some] operators that are looking 
for ways to monitor paths, for various troubleshooting reasons, in a 
[relatively] lightweight fashion.

Also, I'm curious as to why TCP-MD5 isn't mentioned for use as an 
authenticated transport of BMP in the Security Considerations section, 
(since TCP-MD5 is already widely implemented and deployed in routers)? 
For some environments, e.g.: Intra-AS, TCP-MD5 is sufficient, since its 
the de facto transport anyway.  OTOH, I'm not opposed if folks think 
IPSec is a better answer because it can provide authentication, 
encryption or both simultaneously, (presumably, because BMP is more 
likely to be run over untrusted, e.g.: Inter-AS, paths).

-shane

> 	adopted. Please let us know your opinion on this.

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: Geoff Huston <[email-masked]>
Date: Fri, 11 Nov 2005 13:41:07 +1100

Shane,

Thanks for responding here.

The MD5 question is timely. From my notes from the crypto research group 
report to the IETF Plenary MD5 had a goal of 2 to the power 64, but has 
been shown to produce a collision in 2 to the power 30 operations i.e. MD5 
is not goals.

hmmm - should we be stateing "use MD5"? Is there something better to say 
instead?

thanks,

   Geoff

At 01:03 PM 11/11/2005, Shane Amante wrote:
>[...]
>(since TCP-MD5 is already widely implemented and deployed in routers)? For 
>some environments, e.g.: Intra-AS, TCP-MD5 is sufficient, since its the de 
>facto transport anyway.  OTOH, I'm not opposed if folks think IPSec is a 
>better answer because it can provide authentication, encryption or both 
>simultaneously, (presumably, because BMP is more likely to be run over 
>untrusted, e.g.: Inter-AS, paths).

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Nov 2005 19:14:00 -0800

Hi Shane,

Ok so let me ask you and others about scaling principle of this 
approach. I think this is brilliant idea for ad-hoc session monitoring. 
I would fully support it.

Now looking at some comments made during GROW meeting .. some folks 
already go over the board and intend to use it for full scale session 
monitoring with possible feedback.

Imagine you have few hundreds of ABRS each few hundreds of EBGP sesions. 
Are you going to bridge all of them to a single management station ???

What problem are we solving ? Isn't this like Chandra Appana asked 
during the meeting some issues about implementation defficiencies to be 
addressed via a huge overlay ? Should we not fix this or maybe even 
perhaps improve BGP itself if something fundamental elements are missing ?

Next thing ... who is going to support full BGP code on the managemnt 
station .. zebra ? I strongly doubt it. And clearly it is needed to 
parse the latest BGP capabilites, new AFI/SAFIs or even new attributes.

So before we all jump at support for it - I would recommend to step back 
and see what exact technical problem are we solving here ?

Perhaps this is indeed the best solution ... But I would like to see 
this a bit deeper analyzed ...

Cheers,
R.

---

From: David Meyer <[email-masked]>
Date: Fri, 11 Nov 2005 06:51:05 -0800

> [relatively] lightweight fashion.

	Thank you for your comments.

> likely to be run over untrusted, e.g.: Inter-AS, paths).

	Yes, good comment. Did you happen to catch the crypto
	talk last night at the plenary. There's good reason to do
	something stronger that MD5. But yes, we need to think
	about this issue (here and in general).

	Dave

---

From: David Meyer <[email-masked]>
Date: Fri, 11 Nov 2005 07:25:13 -0800

Robert,

> I would fully support it.

	Can you define "ad-hoc session monitoring"?

> perhaps improve BGP itself if something fundamental elements are missing ?

	What might be useful then, is to describe exactly which
	implementation deficiencies you think this might be
	addressing. Just to come clean on this one, I didn't
	fully understand the point Chandra was trying to make.

> station .. zebra ? I strongly doubt it. 

	Surely you're kidding, right? Also, you've assumed a
	mangagement/collection architecture, so it might also be
	useful to explictly state what that is.

> And clearly it is needed to parse the latest BGP capabilites,
> new AFI/SAFIs or even new attributes. 

	Understood, but let's not get caught in the "we need to
	solve every case before we can get anything useful"
	trap. 80% rule, law of dimiinshing returns, etc. That
	being said, there would be quite a bit of value in having
	this for v4 and v6 unicast AFI/SAFI today. The other
	AFI/SAFIs will, as always, get implemented when the value
	proposition is there.  

> this a bit deeper analyzed ...

	Fair enough. And BTW, there are (at least) three use case
	scenarios here that seem fairly easy to identify. First,
	there's the obvious research and operational angles that
	do not require anything like a "few hundreds of ABRS each
	few hundreds of EBGP sesions." And no one today, even
	those who run large collection infrastuctures, "bridge
	all of them to a single management station" (I'm not even
	sure I follow the meaning or assumptions underlying this
	last statement). And BTW, even if one wanted to, it wouldn't
	be that hard or expensive to build h/w and/or design s/w
	to do so. 

	There is also the scenario that Rudiger mentioned (which
	I believe is the use case you are referring to). That may
	be more challenging from a scaling perspective (on the
	router side, see below), but we would need to see a more
	detailed use case description to really analyze that one. 

	Finally, an unstated (or at least I didn't see it stated)
	issue one of resource requirements. In particular, the
	number of updates that a router might (will) have to sent
	to a collector could be (will be) quite a bit larger than
	what we see today, as all of the updates it sees
	would/could be sent (rather than just those that were
	selected by best-path, as we see today). However, some on
	the collecting side would consider this one of the
	attractive features of the proposal. OTOH, router vendors
	might be concerned about CPU loading and other resource
	consumption. 

	Dave

---

From: Shane Amante <[email-masked]>
Date: Sun, 13 Nov 2005 17:53:28 -0700

Geoff,

On Nov 10, 2005, at 7:41 PM, Geoff Huston wrote:
> The MD5 question is timely. From my notes from the crypto research  
> group report to the IETF Plenary MD5 had a goal of 2 to the power  
> 64, but has been shown to produce a collision in 2 to the power 30  
> operations i.e. MD5 is not goals.
>
> hmmm - should we be stateing "use MD5"? Is there something better  
> to say instead?

The point I wanted to raise was that the method to secure BMP should  
be aligned with the existing authenticated transport that has been  
defined for BGP[1], (namely, RFC 2385) -- let's try to avoid spec'ing  
something new/special solely for BMP, (e.g.: IPSec).  Since you  
brought it up, though, RFC 2385 states in Section 4.4:

    Since this memo was first issued (under a different title), the MD5
    algorithm has been found to be vulnerable to collision search  
attacks
    [Dobb], and is considered by some to be insufficiently strong for
    this type of application.

... and, RFC 2385 was published in August 1998.  I'm not a crypto  
guy, but perhaps it's long overdue to get them involved so we can  
[immediately] deprecate TCP-MD5 for BGP and replace it with  
appropriate hash algorithm(s) we should be using instead, for both  
BGP & BMP?  I noticed that there is at least one I-D, which might be  
the answer and just needs some "nudging" through the standards  
process?  Specifically: draft-bonica-tcp-auth-02.txt.  It looks like  
this draft is being discussed in tcpm WG, (which I don't follow), but  
appears to address the need for multiple hashing algorithms in TCP,  
(and time-based key roll-over) -- both good things.  Has IDR and/or  
GROW weighed in with TCPM on draft-bonica and its importance?

-shane

[1] I do realize whatever proposal is chosen as a next-step to RFC  
2385 is meant only to secure the transport-layer used by BGP.   
Ultimately, a work product of rpsec+sidr will secure sets of BGP  
attributes, which has bearing on BGP's path selection process and  
are, IMO, more critical to authenticate.  Still, securing BGP's  
transport layer should be a priority, until the work in rpsec gets  
wrapped up and sidr gets [well] underway.

>> authenticated transport of BMP in the Security Considerations  
>> section, (since TCP-MD5 is already widely implemented and deployed  
>> in routers)? For some environments, e.g.: Intra-AS, TCP-MD5 is  
>> sufficient, since its the de facto transport anyway.  OTOH, I'm  
>> not opposed if folks think IPSec is a better answer because it can  
>> provide authentication, encryption or both simultaneously,  
>> (presumably, because BMP is more likely to be run over untrusted,  
>> e.g.: Inter-AS, paths).
>
>

---

From: Shane Amante <[email-masked]>
Date: Sun, 13 Nov 2005 18:24:41 -0700

Hi Robert,

On Nov 10, 2005, at 8:14 PM, Robert Raszuk wrote:
> approach. I think this is brilliant idea for ad-hoc session  
> monitoring. I would fully support it.
>
> already go over the board and intend to use it for full scale  
> session monitoring with possible feedback.

I wasn't able to attend the GROW meeting this time, and unfortunately  
the minutes from the meeting don't reflect this concern.   
Nonetheless, I don't see the value in using BMP for "possible  
feedback," (although I'm sure some route optimization vendors  
might).  IMO, I think BMP should be scoped as a "one-way, monitoring- 
only" protocol.  If one wants feedback, then use BGP (or, scripts --  
blech) -- of course, one has to be *very* careful not to engineer too  
tight of a feedback loop between BMP and BGP, but that's something  
that's outside the scope of BMP.

> Imagine you have few hundreds of ABRS each few hundreds of EBGP  
> sesions. Are you going to bridge all of them to a single management  
> station ???

No, but what I would like to see, at a minimum, ~6 peering routers  
bridged to a single monitoring station.  However, it would be ideal  
if I could have a few dozen routers (at most, < 40) bridged to a  
single monitoring station.  Presuming I stagger start-up of BMP  
sessions to such a large # of routers, during a full reboot of the  
monitoring station, I assume a reasonably fast box should be able to  
keep up with continuous updates flowing in under steady state and  
some operational changes?  However, if that's unrealistic, CPU's are  
relatively cheap so maybe I have to throw a monitoring box per dozen  
routers ... which isn't that expensive.

> during the meeting some issues about implementation defficiencies  
> to be addressed via a huge overlay ? Should we not fix this or  
> maybe even perhaps improve BGP itself if something fundamental  
> elements are missing ?

I'm not sure of the context of this question, but the only value I  
see in BMP is monitoring only.

> Next thing ... who is going to support full BGP code on the  
> managemnt station .. zebra ? I strongly doubt it. And clearly it is  
> needed to parse the latest BGP capabilites, new AFI/SAFIs or even  
> new attributes.

Well, if open source guys don't develop it, I'm sure there are a  
handful of commercial vendors who would easily step in.  At the  
moment, though, I see the most value in monitoring IPv4 (and,  
eventually IPv6), which should be possible in a straightforward  
manner with zebra/quagga/etc.

-shane

> So before we all jump at support for it - I would recommend to step  
> back and see what exact technical problem are we solving here ?
>
> Perhaps this is indeed the best solution ... But I would like to  
> see this a bit deeper analyzed ...
>
> Cheers,
> R.
>
>
>
>
>> researchers, but also potentially to [some] operators that are  
>> looking for ways to monitor paths, for various troubleshooting  
>> reasons, in a [relatively] lightweight fashion.

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 18 Nov 2005 21:33:08 +0100

<inline>
Tom Petch
----- Original Message -----
From: "Shane Amante" <[email-masked]>
To: "Geoff Huston" <[email-masked]>
Cc: "David Meyer" <[email-masked]>; <[email-masked]>
Sent: Monday, November 14, 2005 1:53 AM
Subject: Re: grow: draft-scudder-bmp-00.txt

>     algorithm has been found to be vulnerable to collision search  attacks

I do follow idr, tcpm and rpsec.  BGP is seen as an unusual case in that its
sessions are long-lived but short on hopcount (like zero) so that the bigger
threat are tcpm-style attacks from fake packets (rather than the recognised
weaknesses of MD5).  BGP does surface in that context on tcpm while the
justification for the ongoing use for MD5 lies in

draft-iesg-tcpmd5app-01.txt

Interestingly, when the work was going on for the new, soon to appear, BGP4 RFC,
many BGP sessions had no security at all but a spate of attacks about two years
ago caused many if not most to turn on MD5; I saw evidence of this in
presentations to RIPE.

rpsec appeared to be the forum to move this on further but seems stalled with
two (or more) diametrically opposed views; whether or not the IETF has a process
to progress this I await with interest (perhaps it goes under the name of sidr).

---

From: Russ White <[email-masked]>
Date: Mon, 21 Nov 2005 10:35:01 -0500

> ago caused many if not most to turn on MD5; I saw evidence of this in

RPsec is currently considering a charter update to include a draft for 
point-to-point security for all protocols, including the replacement of 
MD5. No draft yet, but volunteers are welcome. :-)

> to progress this I await with interest (perhaps it goes under the name of sidr).

Actually, I would characterize the impasse in rpsec as two things:

-- Not enough participants. We're down to 7 votes, in the last vote on 
the idr requirements doc. Since people aren't going to "change sides" at 
this point, we probably need more participation to form a wide concensus.

-- Three basic viewpoints:

  -- The BGP specification should be taken as a process explaining how 
routes should be handled. Security mechanisms should ensure that process 
takes place on every router.

  -- The BGP specificiation should be taken to describe a system that 
distributes routing information throughout an internetwork. Security 
mechanisms should ensure the accuracy of the data, including some bits 
of policy, at least (origin authentication being the strongest example). 
The point is to make certain the information advertised matches reality.

  -- The entire concept of doing some new system or protocol enhancement 
to "secure" BGP is off on the wrong track. We should just focus on quick 
fixes, and worry about replacing BGP.

The last vote seems to have fallen along three lines.... All of the 
folks in the first camp voted against it. Some of the folks in the 
second camp voted for it, while others voted against it, because of 
"nits" or because "it doesn't cover x well enough." I think we'll always 
get those, and I don't know that we'll ever actually make it perfect 
enough, in those sorts of senses. All of the folks in the last camp 
voted against it, saying we don't need requirements at all.

That seems to be the status at the moment, or at least my perception of 
it (which could be wrong).

:-)

Russ

-- 
[email-masked] CCIE <>< Grace Alone
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/