[RPSEC] Consensus and Draft Minutes from SF

Hi folks,

We've got the minutes put together from SF.
There were a few people who are listed as "??" in the
conversational part because the takers didn't catch
their names.

If anyone can fill in those blanks (or has other corrections)
please pipe up within the next couple of days.

Also somewhat buried in there is the fact that we had a consensus
call for accepting draft-beard-rpsec-routing-threats-01.txt
(the merged threats doc) as a WG document per our charter
to be developed in fulfillment of our first milestone (those need
updating).  The people in the room in SF voted overwhelmingly to
accept the doc as a WG item.  I don't recall any opposition, but
perhaps there were a few hands.  Speak up now if you disagree with
this action.

Thanks,

Tony
----

Routing Protocols Security Meeting
Draft Minutes
IETF 56, 18 March 2003  0900-1130 PST

Co-Chairs: Tony Tauber, Russ White

Agenda
------
 Tony Tauber presenting
 Agenda Bashing
  no comments

Merged Threat Doc
------ ------ ------
 draft-beard-rpsec-routing-threats-01.txt
 Sandy Murphy presenting

  Unauthorized Vs Masquerading Attackers
   Steve Kent: Should we distinguish unauthorized vs masqerading
attackers?

   Gregory Lebovitz: Distinguishing between the two makes the point that
packet filtering is not enough

   Sandy Murphy: Any security mechanism that would prevent anyone from
masquerading would also prevent anyone who is not authorized.

   Gregory Lebovitz: Keeping them separate makes people think about
solving both issues.

  Packet Filtering
   Sandy Murphy: We don't want to imply that packet filtering will
"solve" the problem

   Sean Convery: Saying packet filtering is useless is against attacks
completely ignores the way security is used today (RFC2327).

   Sandy Murphy: I don't think it adds value, although it is common use.
It's not going to save you from anyone who knows how to get around them

   Sean Convery: iBGP using packet filtering prevents cannot be
circumvented unless the router is compromised.

   Steve Kent: We haven't defined what a threat is: packet filtering
works as long as routers aren't compromised. We can't decide if packet
filtering prevents attacks unless we agree on what a threat is.

   Sandy Murphy: Parts of the original threat document that expands on
this didn't make it into the merge; maybe we should expand this part.

   Steve Kent: We don't have any concept of what assurance is. No
mechanism is secure in and of itself, you have to know the context. Not
100% doesn't mean it's not good, we need an agreement on threats to
agree on whether something is good.

   Sean Convery: Security is incremental, you can't provide 100%
assurance.

   Steve Bellovin: Packet filtering is one technique among many which
can be useful. It can keep out a nontrivial amount of bad stuff. If the
filters are on all perimeters, and no internal compromises, it is good.

   Bob Hinden: This argument is typical of the real world who think that
address filtering does something with security, while those in security
don't think it does. Packet filtering has some value, but it's not what
security people would call security. It's a tool that people understand
and it exists today.

   Steve Albant: Ingress filtering is a good technology used badly. If
the filtering is implemented correctly and there is no subvertion
inside, it's a good idea.

   Sandy Murphy: Some routing protocols (wireless) have no concept of a
list of peers. The context matters.

 Underclaiming
  Steve Kent: Underclaiming is not necessarily a problem; you may not be
required to advertise stuff that you own. We have to be careful about
this.

  Sandy Murphy: I don't like to claim this as an attack

  Tony Tauber: Underclaiming could be a problem. If you have load
sharing, and you force all the traffic onto one link, you have broken
the network.

  Sandy Murphy: There are normal situations that one of the home site
has to stop advertising.  There's no way to figure out it's intentional
or unintentional? It's rather a correctness issue than security issue.

  Sandy Murphy: Underclaiming is the router doesn't adve what it's
supposed to do.

  Russ White: One business hires a hacker to block advertisement of another
business' web site; this is an attack that we should worry about.

  Sandy Murphy: This is not underclaiming. This is a falsification attack.
There's no way to protect against the router stating it's link is down
wrongly

  Geoff Houston: That's threat vs standard operating practice? Insert
peers AS may be valid to indicate that common link is not to be used.
Underclaiming may also have valid applications: standard operating
   practice.  The issue is to determine intent.

 Transport Layer
  Steve Kent: Since the RP's choose the transport they will use, there's
reason to include them in the in threat model; protocol designers need
to be aware of issues in the transport they use.

  Sandy Murphy: These are important, but how do we handle them?

  Steve Kent: Put it in a section that talks about resource consumption.
Different security methods can exhaust resources. How can we get rid of
things that I don't want as fast as possible.

  Alex Zinin (as a WG member): Even though something may not be
detectable at the routing level, doesn't mean they shouldn't be
included. We should include them, and then analyse what can be done
about it.

 Sandy Murphy: If the document pursued a functional breakdown, this
would have been more obvious/more places to put it. I'm reluctant to
include all threats to the routing system, since that's a huge area.

 ??: Part of the design of OLSR's design that dropping packets will
break the protocol. Should this be included as a threat?

 Sandy Murphy: How should we handle this? BGP routers are under no
obligation to accept a session, but OSPF is. It needs to be addressed
somehow, but we don't know how.

 Sean Convery: We could provide pointers to outside doc's, but we
shouldn't ignore the system level threats. The context is missing.  More
conversation about the routing system Threat consequences in this draft
are focused on the rp, not on the routing system.

 Other Comments
  Steve Kent: Point out to people what real consequences are of an
attack. Some people talk about DOS, but that is only one option. You
could try to cause traffic to pass by a point where it can be tapped.

  Steve Kent: The originator is not the only important part of the
route, other modifications may also alter routing. This isn't not just
BGP.

  Steve Kent: Our goal is to try and prevent localalized failures from
breaking the system.

  Sandy Murphy: How many bad routers do we want to protect yourself
against?

  Jeff Haas: Is adding in as' that are not in the path a falsification
attack?

  Sandy Murphy: This is a change in the path that isn't authorized, so
this is a falsification attack.

  Steve Kent: Correct Operation vs What are the Symantics of the RP?
Security is very closely aligned with correct operation. We could go far
towards security by simply making certain the RP is operating correctly.
Some protocols have symantics which are underspecified for local
flexibility. This local flexibility makes security impossible

-----
Consensus call: Should this doc be a WG doc?
 (Charter calls for a threats analysis doc.  Is this the one we should
  work on?)
  Sense of the room is overwhelmingly "yes".  No objections.
-----

Requirements Doc
------ ------ ------
 Danny McPherson presenting

 Top Down Vs Bottom Up
  Lots of discussion on whether this was a top down analysis or a bottom
up analysis

  Tony Tauber: We should redefine the terms; it's actually protocol vs
attack analysis.

Protocol specific discussion
------ ------ ------
 Tony Tauber: specific doc is still in our scope. we need to focus on generic
stuff first.

 Alex (hat on): Discussion w/ADs and WG chairs are on-going.  We do
recognize that rpsec is where the clue (routing + security) is.

Encap Draft
------ ------
 draft-zinin-rtg-dos-00.txt
 Alex Zinin presenting

 Joel Halpern: You have this almost completely wrong; there has been a
bit discussion in the routing protocols on how to encap the protocols.
IS-IS uses a seperate layer 2 encap, while OSPF when with IP encap.
Buffer overflows can only be fixed by the implementations. For an
operator, you can deploy IP based protocols with a single filter without
new encaps. Creating a new encap doesn't help anything. How does this
address BGP?

 Alex Zinin: BGP is addressed. Most filtering techniques require
hardware support.

 John Ionnadis: Are you moving the data plane to an out of band "network?"

 Alex Zinin: No, RP follows the same links as user data. The encap is
changed, to seperate the traffic.

 John Ionnadis: I meant that below the network layer you're
distinguishing between user data and routing data.

 ??: I don't know that I believe that RP's need to run at line rate

 Alex Zinin: The assumption is not that the RP's need to run at line
rate, you need to run the security checks at line rate, because they can
be attacked at line rate.

 Steve Kent: Remove the word trusted from the draft; it's not what
you're trying to do. Subverting a router destroys the trust. On a point
to point basis, you'd like a way to demux the traffic efficiently so you
can discard the traffic at a high rate to kill certain attacks. The
problem arises is when the traffic comes from a not directly connected
(remote) station, and try to propagate it.

 Alex Zinin: The draft addresses this.

 Steve Kent: How do you handle this?

 Alex Zinin: The tag isn't carried up the stack. Packets which are already
encap'd in the special encap, it is encap'd on the outbound side.

 Steve Kent: It does change the forwarding plane. You shouldn't compare
this to MD5.

 Alex Zinin: No, it's changes the encapsulation.

 Steve Kent: The infrastructure has to be there to keep people in the
group, etc.

 Alex Zinin: Yes, but that's low overhead.

 Peter Lothberg: This is trying to solve the same problem as all
isolation problems are trying to solve.  I want to build a vpn for my
routing traffic. It adds a lot of complexity. It's better to solve the
problem on the router.

 Alex Zinin: This is a generic mechanism which could be used for anything

 Bob Hinden: I don't see what the difference is between doing the
recognition in the layer 2 bits vs in the layer 3 bits.

 Alex Zinin: If you change something at L3, you have to filter those
packets on the entire perimeter of the network. L2 or MPLS label can be
checked before some other authentication is done.

 Bob Hinden: What if there are forged layer 2 packets?

 Alex Zinin: They won't be forwarded.

 ??: Multicast not addressed and won't help at all.

 Alex Zinin: I'm not trying to solve all the problems. Multicast has a
link between the data path and the control plane....that may need to be
changed.

 ??: It's the same box that's doing this encap. Why doesn't just putting
the traffic on a separate queue solve this?

 Alex Zinin: Then the attacker will just send you a lot of packets of
the right layer 3 type. Routers will not forward packets that are not
encap'd in the correct format, so the filtering at the edge is
automatic.

 John Ionnadis: What we are acheiving is not to use forwarding that
belong to these special classes.  All these things, however stay on the
link and forwarding them because they they are regenerated.  Doesn't the
TTL Hack solve this problem, as well?

 Alex Zinin: iBGP requires something more generic than BTSH, but this
could work with BTSH for eBGP.  There are things that are required to be
propagated, SSH, targeted LDP, etc. It looks like you are suggestion to
use the TTL hack for these, as well?

 John Ionnadis: Yep.

 Alex Zinin: Some things may be secured this way, but not all. Something
more generic should be used.

 Ross Callon: This is semantically equivalent to packet filters. The
problem with that is the source address can be spoofed, but it might be
a good ides to filter on source address, anyway.

 Alex Zinin: The problem is that most equipment can't do this at line
rate.  This is essentially the same as address spoof filtering.

 Lixia Zhang: Spoofing an mpls packet is not allowed today, since mpls
packets are not allowed into the network.

 Lixia Zhang: I don't understand this reaction.

 Alex Zinin: It's a crazy idea.

 Lixia Zhang: Yes, it is. We need mechanisms to protect the routers. The
question is when. We should have multiple layers of protection, it won't
hurt.

 Alex Zinin: Yes, we should. We can solve this other ways, but how long
will this take to be able to do this.

 Steve Kent: The anology of how many layers in skin doesn't work. Each
layer comes with more overhead management.

 Sue Hares: What about circular loop with mps reliant on routing, and
routing is reliant on mpls?

 Alex Zinin: Because this is link local hop by hop, and there is no mpls tag
distribution or multihop route calculation, there is no circular
dependancy.

Lack of Classification Ability Considered Harmful
------ ------ ------ ------ ------ ------ ------
Vijay Gill presenting
(added at last minute to try and illuminate the problem of DoS
attacks against router resources)

 Steve Kent: Your characterization is a subset of the problem that Alex
is talking about. You're looking for a way to tag packets saying this is
"routing traffic"

 Vijay Gill: I'm trying to describe the problem.

 Steve Kent: You don't have a multihop problem, though?

 (From several people in the room): iBGP.

 Alex Zinin: The problem is the same, but Vijay is only concerned about
routing, not other control traffic.

 Steve Kent: Why is MD5 in this discussion?

 Vijay Gill: Because MD5 does not address the problem. MD5 will not prevent
the router's cpu from inundating the router with processing. Doesn't
prvent DOS attacks against the router.

 Steve Kent: The example of MD5 reduces the scope of the problem, but
doesn't define the problem.

 Vijay Gill: The problem is overruning the router.

 Steve Kent: If the problem was narrower, then we can work on it.

 Vijay Gill: That is a subset of the problem.

 ??: You want a zero cost way to tell this is from a neighbor that I
care about. You cannot go to the next step without stating why this is a
problem

 Vijay Gill: I'm not supporting an approach.

 ??: IPv6 allows an interface to have an arbitrary number of addresses.
You could have a set of addresses that show up in traceroute, but it
doesn't ever accept any traffic on.

 Alex Zinin: You could also use unroutable addresses.

 General points to consider
------ ------
 Tony Tauber presenting (briefly)
See IAB sec drafts:
 draft-iab-sec-cons-
 draft-iab-secmech-
	The latter is likely of less usefulness to the particular
	case of routing protocols.

Some things fall outside protocols but are still of security interest:
  good operation practice, implementation considerations.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec