Minutes

Administrative trivia like minutes, jabber scribes, and volunteers,
and agenda discussion

1) Replay and Freshness

Sandy Murphy presented an initial set of slides about the problem.
Sriram Kotikalapudi presented a set of slides with some measurements
of the load to be expected from beacons.

Freshness is important, it allows us to eliminate state in the system
that has gotten stuck which can cause problems and security issues.
However there is a non negligible cost associated with providing
freshness that is proportional to how often we provide it (rate). ("We
will need to act the fastest when we are hurting the most.")

Cost is what router has to do to generate a beacon and what receiver
has to do to detect it is a beacon and not do best path.

[If a router receives updates from A and B and chooses B, then
receives a new beaconed update from A, do not want to do best path
decision again, do not want to propagate the beacon update further.
And if the router has chosen B and receives a beacon for B, it must
propagate even though the best path decision has not
changed. Distinguishing beacon from original update requires retention
of state.]

At low rate (human rate) the cost to the operator is tolerable.  Many
routes are incredibly stable so having long timers is good. At higher
rates (machine rates) the cost to set up, sign and verify can be
extremely large depending on the number of prefix and number of
upstream neighbors involved.  One potential damage could be from
routers that beacon too often.  One possible amelioration mentioned
was to change the units of the time so that even a small beacon time
(scalar) would not be a burden.

An alternative to beacons is to change the keys on a router, using
publication in the RPKI as the means of ensuring old updates are
rejected.

Propagation of new router keys and revocation of the old keys through
the RPKI was a concern, with the possibility of generating a sequence
of keys to be pre-published in the RPKI. There exist other mechanisms
using certificates validity times to choose the freshest certificate.
Another mechanism mentioned was to create a new nlri to alert "please
update, I have changed", akin to the DNS Notify.

It was suggested that graceful restart right now gives an example of
the best timing we can do now, we won't do better with beaconing.

There was concern over burstiness if you have to rekey for all 400K
routes that have to be reassigned for a given AS. It was pointed out
that policy changes can also similarlyicause burstiness, so it's not a
new thing.

[There was a small segue into considerations of getting keys into
router . generate on router or generate elsewhere and inject into
router.  Even in the generate on router case, wise to export offboard
for recovery after failure.  This is new conjunction of routing
operations and security and may need careful consideration of how it
is handled.]

Brian Dickson (on jabber) suggested flooding invalidation of revoked
signatures (instead of revoking keys) systemwide . not following bgp
best path logic.  This would make the revocation specific to one
update.  Reactions in the room were that this would be a brand new
security mechanism and so would require special attention.  Also, the
semantic difference between this and a CRL was not clear, and if none,
why invent a special mechanism.  Brian hinted that he might create a
draft for this.

There was some discussion of means to ensure old keys were revoked
(other than revocation in the RPKI) such as prepublishing daily keys
or specially designated 'emergency keys' were discussed.


Discussion considered protections possible in different attack timeframes:

- long term low frequency replay attacks -- here rekeying works and is
feasible. Post hoc rekeying is fine.
- short term high frequency attacks that can be anticipated --
rekeying can work here too (depending on many constraints) but mainly
by prepublishing keys.
- short term high frequency attacks that cannot be anticipated --
rekeying cannot work. Beaconing might be the only solution but there
will be high cost.

There were three different levels of opinion about beaconing:

For long term, low frequency, human rate protection , rpki rekeying
defense is good.  Beacons might be more comforting in that case but
not worth the additional cost.  For short term, high frequency case,
beacons are too high cost.

Router key change in the RPKI seems adequate in most cases but it
would be good to have a second protection mechanism as a backup (eg a
link has failed and traffic is being diverted)

If human response is days but the automated beacons can respond in
hours, may be worth it to beacon.

A theme throughout this discussion was a need for understanding the
threat, so we do not expend effort on the wrong problem.  Threats
mentioned included human scale events, like relationship change
between peers, damage from immediate neighbors vs replay by
intermediate, non-adjacent neighbors on the path and attacks against
freshness as well as replay.  Etc.

The result was to suggest that the protocol document replace the
discussion of beacons in the protocol specification with an indication
that the working group is still considering the best approach for
replay protection.

3) Route Leaks

Dongting yu provided an empirical analysis of route leaks that his
group followed by observing large IXPs (Internet exchange points).  He
was unable to explain the definition he used for "route leaks" in this
study.  It seemed that he was notified of an "event" by a provider and
could not characterize it further (by the terms of his agreement). The
study presented found that leaked prefixes were generally not
originated by the leaker. Most leaks are related to the number of
prefixes that passed through the concerned AS the day before and were
represented as a ratio of prefixes passed on the event day to the
prefixes passed the previous day. IXPs closest to the event were found
to be more affected, and resulted in higher number of updates from
those IXPs.

Sandra Murphy talked about Route Leaks in general, and various example
scenarios of potential route leaks.  She also opened up the discussion
to steer towards a precise definition of route leaks, detection and
response actions.

There was general agreement in the room that people could label the
various scenarios as leak or not leak, but only by assigning semantics
to the direction of connecting links.  (Embedding gifs of topology
graphs in the bgp protocol was easily rejected.)  Those semantics are
not presently carried in the bgp protocol.

The scenarios included the stub customer leak between two providers
that was the example in the draft noted in the sidr mailing list.  It
is not clear if this is the only scenario that needs to be considered.

Brian Dickson (on jabber) suggested the "valley free" notion.
However, a few of the scenarios were considered "leaks" but appeared
"valley free".  Brian amplified his suggestion in various ways,
suggesting tags or new signatures on each hop, rules for judging lists
of tags, stripping signatures, etc.  He suggested a trust model for
the approach, with both neighbors required to attest to the link tag.
The room could not follow all the details and Brian offered to write
it down.

A couple of definitions of route leaks were discussed, but there was
no general consensus in the room regarding a precise definition for a
route leak.

Using existing communities might catch the stub customer case, but not
others.  As many of these situations seem to be need an update to be
restricted in propagation, use of the as-hop limit was considered.
That however did not match the scenarios.  Use of RPSL, or something
as expressive as RPSL, was mentioned.

The following were discussed:

- Modify BGP to carry information for the detection of route leaks in
the protocol and modify the protocol behavior to respond. Then use
BGPSEC signatures to protect the new capability.

- Modify BGPSec security mechanisms to include some sort of route 
leak semantics.

- Leave the protocol alone, and encourage mechanisms for detection
that will work with peripherals like the routing database.


Sean Turner presented some thoughts on Route leaks:

He quoted some possible definitions of route leaks.

He opened the discussion to whether route leak detection should be
solved in BGP or BGPSec.

From the BGP viewpoint, thwarting attacks is BGPSec's problem.  From
the BGPSec viewpoint, BGPSEC cannot change the semantics of BGP but
only secure BGP semantics. General opinion was in agreement with Russ
Housley, who stated that in past efforts he found that adding new
semantics/features to a security protocol instead of the protocol
being secured was the wrong choice.  He and many agreed felt that this
problem should be presented to the IDR wg, which is where BGP is being
maintained.

The final consensus was that a statement of the problem should be
worked out in the SIDR mailing list and sent to IDR for their
consideration.  Joint work with IDR to design security protections for
any new feature design work they take on is likely.