Subject: RE: [RPSEC] proposed message to the IESG

From: "Brijesh Kumar" <[email-masked]>
Date: Thu, 27 Jan 2005 12:09:37 -0500

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, 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

---

From: "Bora Akyol" <[email-masked]>
Date: Sat, 29 Jan 2005 09:20:42 -0800

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

> 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
> 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 
> 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).
> 
> 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 
> 
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Susan Hares

---

From: [email-masked]
Date: Sat, 29 Jan 2005 19:05:56 +0000

> purpose, but there are technical details that need to be ironed out.

	authorized ... by whom?
	           ... by what methods?

	presuming one "handwaves" over these thorny, non-technical
	points, one has to ask how a prefix-holder, in collaberation
	with the AS-holder, will present such bonafides to the RPSEC
	engine(s)?

	then one can worry about your option #2.  ...  at least imho.

--bill

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 31 Jan 2005 13:05:26 +0100

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)

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jan 2005 10:02:20 -0500

> is to guarantee the integrity of messages on a hop-by-hop basis.

Not being vulnerable to remote session resets is handy too. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: "Bora Akyol" <[email-masked]>
Date: Mon, 31 Jan 2005 13:41:15 -0800

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

> 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
> 
> 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
> 
> Cc: <[email-masked]>; "'Tom Petch'" 
> <[email-masked]>; "'Susan Hares'" <[email-masked]>
> > 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.
> >
> >   -- 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.
> >          -- By explicitly "signing" the AS_PATH at every 
> BGP speaker 
> > that is on that path.
> > 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
> >
> >
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Brijesh Kumar
> > > 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).
> > >
> > > 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.
> > >
> > > Confederations, Route Reflectors, VPNs, Communities, IPv6, Route 
> > > Flap Damping, Like Sue, I too don't see how these 
> requirements can 
> > > be deemed complete.
> > >
> > >
> > > --bk
> > >
> > >
> > >

---

From: "Bora Akyol" <[email-masked]>
Date: Mon, 31 Jan 2005 13:41:46 -0800

> On Behalf Of Jeffrey Haas
> Sent: Monday, January 31, 2005 7:02 AM
> To: Bora Akyol
> Cc: [email-masked]

Yep, TCP does have its own set of problems, resets is one of them.

Bora