Subject: RE: Purpose of the BGP req draft (RE: [RPSEC] proposed message totheIESG)

From: "Susan Hares" <[email-masked]>
Date: Mon, 31 Jan 2005 18:11:28 -0500

Bora:

Why do you not want to have BGP communities?

Why not the other items - specifically: Graceful Restart or Route
Reflectors or AS Confederation? 

Are you eliminated Dynamic Capabilities because it is not widely
deployed?
(Mostly redback routers due to the earlier errors).

Sue Hares

-----Original Message-----
From: Bora Akyol [mailto:[email-masked]] 
Sent: Monday, January 31, 2005 4:41 PM
To: 'Tom Petch'; [email-masked]
Subject: RE: Purpose of the BGP req draft (RE: [RPSEC] proposed message
totheIESG)

Hi Tom

I think Multi-Protocol should be covered, I am not sure about
communities.

I think 
the rest of the items you mention (if I understand correctly), are
between
two peers
and should be covered by transport integrity mechanisms; that is, the
information does not get sent beyond the two peers unlike reachability
which
gets sent across the network.

Bora

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tom Petch
> Sent: Monday, January 31, 2005 4:05 AM
> To: Bora Akyol; [email-masked]
> Subject: Re: Purpose of the BGP req draft (RE: [RPSEC] 
> proposed message to theIESG)
> 
> Bora
> 
> I think there is another aspect of this that needs to be nailed down.
> 
> Does it cover Multi-Protocol Extensions?  The implication of 
> some posts recently is yes, in which case, which?
> 
> Does it cover communities?  Ditto, ditto ie all or some only 
> in which case, which?
> 
> And then there are other smaller topics like Graceful 
> Restart, Capabilities, Route Flap Damping etc, etc.
> 
> I am not very good at spotting loopholes through which the 
> malicious can launch DoS attacks but I suspect that most of 
> the I-D and RFC listed on the IDR charter web page could form 
> the basis of an attack and should either be explicitly 
> included or excluded in the scope of this work ie should be 
> mentioned in your draft.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Bora Akyol" <[email-masked]>
> To: "'Brijesh Kumar'" <[email-masked]>; 
> <[email-masked]>
> Cc: <[email-masked]>; "'Tom Petch'" 
> <[email-masked]>; "'Susan Hares'" <[email-masked]>
> Sent: Saturday, January 29, 2005 6:20 PM
> Subject: Purpose of the BGP req draft (RE: [RPSEC] proposed 
> message to the IESG)
> 
> 
> > I will try to address your question.
> >
> > The requirements document tries to address two primary issues:
> >
> > 1) Is the originator of an address range (prefix) authorized to 
> > advertise that address range.
> >
> > 2) When router A in a given AS receives a BGP Update 
> message in which 
> > there exists an AS_PATH object, does the information contained in 
> > __that__ object appear to be authentic.
> >
> > While we did include the transport security in there, that 
> is not the 
> > main concern of the draft.
> >
> > The arguments about the draft center on three areas:
> >
> >   -- In (1) above what exactly does "authorized" mean? Although, I 
> > think this is the least contentious of all. Where I think 
> all agree on 
> > the purpose, but there are technical details that need to 
> be ironed out.
> >   -- In (2) lies the contention. One could achieve (2) in 
> at least two ways:
> >          -- Using out of band information to construct a 
> verification 
> > database via which the incoming AS_PATH information can be 
> verified from
> >          -- By explicitly "signing" the AS_PATH at every 
> BGP speaker 
> > that is on that path.
> >      Note that I put "signing" in quotes, because it is 
> more than just 
> > appending a signature to each iteration of the AS_PATH, it also 
> > requires addition of other fields.
> >
> >
> > Note that (1) and (2) above address the byzantine node problem, but 
> > they also address a lot more than that.
> >
> > What (1) and (2) do not address is a bgp blackhole that supresses a 
> > set of advertisements that are supposed to go through it but do not.
> >
> > Transport security is nice to have, but really, all we need out of 
> > transport is to guarantee the integrity of messages on a 
> hop-by-hop basis.
> >
> > Bora
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Brijesh Kumar
> > > Sent: Thursday, January 27, 2005 9:10 AM
> > > To: [email-masked]
> > > Cc: [email-masked]; Tom Petch; Susan Hares
> > > Subject: RE: [RPSEC] proposed message to the IESG
> > >
> > >
> > > I briefly looked at the draft - I too was wondering what is this 
> > > draft trying to accomplish. It was n't very clear to me.
> > >
> > > I did some work way back on routing security ( Integration of 
> > > security in network routing protocols
> > > Source ACM SIGSAC Review archive Volume 11 , Issue 2   
> Spring 1993,
> > > and Integrating security in inter-domain routing protocols Source 
> > > ACM SIGCOMM Computer Communication Review archive Volume 
> 23 ,  Issue 
> > > 5  (October 1993)), and of course things have changed since then, 
> > > but any discussion for routing protocol security still 
> has only two 
> > > aspects to it: 1.
> > > Subverted links 2. Subverted nodes (including byzantine failures, 
> > > misconfugrations).
> > >
> > > Link security is n't an issue with the current version of
> > > BGP+MD5/SSL-TCP. Except, proposing mechanisms for 
> subverted nodes, 
> > > BGP+and
> > > misconfigurations, I don't see what else can comeout of 
> this draft 
> > > in terms of any solution.
> > >
> > > So unless, requirements discuss all BGP features like AS 
> > > Confederations, Route Reflectors, VPNs, Communities, IPv6, Route 
> > > Flap Damping, Like Sue, I too don't see how these 
> requirements can 
> > > be deemed complete.
> > >
> > >
> > > --bk
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > > Susan Hares
> > > > Sent: Thursday, January 27, 2005 10:01 AM
> > > > To: [email-masked]; Tom Petch
> > > > Cc: [email-masked]
> > > > Subject: RE: [RPSEC] proposed message to the IESG
> > > >
> > > >
> > > > Bill and Tom:
> > > >
> > > > I agree.  BGP as a protocol implemented in the world 
> includes many 
> > > > specifications.  (AS the IDR web page will attest to).
> > > >
> > > > BGP as an implemented protocol does include AS Confederations, 
> > > > Route Reflectors, VPNs, Communities, IPv6, Route Flap
> > > Damping. (etc).
> > > >
> > > > Any plans to focus on a secure BGP that does not 
> support current 
> > > > operational BGP would find itself limited in it's deployment.
> > > >
> > > > Sue
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked] 
> > > > [mailto:[email-masked]]
> > > > Sent: Wednesday, January 26, 2005 8:19 PM
> > > > To: Tom Petch
> > > > Cc: Blaine Christian; Susan Hares; [email-masked]
> > > > Subject: Re: [RPSEC] proposed message to the IESG
> > > >
> > > > > > " This specification covers only the exchange of IP 
> version 4
> > > > network
> > > > > >    reachability information."
> > > > > >
> > > > > > Which seems to state that all the other uses for BGP
> > > are not covered
> > > > under
> > > > > > the draft.  Is that true?
> > > > >
> > > > > Yes.
> > > > >
> > > > > I think this is a key point.  Look hard and you will not find
> > > > Confederations,
> > > > > Route Reflectors, VPNs, Communities, IPv6, Route Flap
> > > Damping etc etc
> > > > etc in
> > > > > this draft, all very valid aspects of BGP.  The aim of
> > > this draft does
> > > > not
> > > > > include those functions (although the relevant RFC 
> are listed as
> > > > informative
> > > > > references with no references in this draft to them:-).
> > > > >
> > > > > So is BGP security looking at the scope of BGP as defined in 
> > > > > this
> > > > basic document
> > > > > (give or take some operator licence with prepending or
> > > aggregation);
> > > > or at the
> > > > > scope of BGP as defined in a much wider set of RFC and
> > > I-D?  If the
> > > > latter,
> > > > > which documents are included?
> > > >
> > > >       it would seem best to stay tightly focused on the 
> core spec,
> > > >       since new stuff is allowed (and used to be
> > > encouraged) to emerge
> > > >       to deal w/ changing situations... like the short 
> list above!
> > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > RPSEC mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/rpsec
> > > >
> > > >
> > > > _______________________________________________
> > > > RPSEC mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/rpsec
> > >
> > > _______________________________________________
> > > RPSEC mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/rpsec
> > >
> 
> 
> _______________________________________________
> RPSEC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rpsec
> 

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec