Minutes for SIDR at interim-2012-sidr-3
minutes-interim-2012-sidr-3-1

Minutes

Trivia

Agenda bashing

0:15: Sandy talking about AS Path parameters
pcount0, signatures on As Path.
protocol specification was changed to capture all the semantics from the BGPSec
attribute. Doing away with the entire As Path parameter is not acceptable as
was discussed on the mailing list. On the boundary between a BGPSec speaking As
and a non BGPSec speaking AS we reconstruct the classic ASpath from the
bgpsecattribute.

9:50 Randy asks question about what are the problems we have today with knowing
what path has been followed. Are signatures sufficient Randy eludes to the
discussion that occured on the mailing list a week before on confederations.

 Sriram Slide #7 Confed sequence
talks about AS confed configuration, signing example.
Randy objects to pcount 0. Sandy, Wes George weighs in. Everyone agrees to use
pcount 1. resolved

As confederation discussion
20:35: Removing the signatures and ASNs that are internal to the confed at the
edge of the router. Sandy: at the exit point,you assume you know the public
identity of the As, and you step back until AS recognizes the public AS
(something that is signing forward). Ruediger: Loops is a showstopper. Randy:
If you go backwards (leftwards) stripping signatures until you reach the first
public AS, then we wont have a problem. Reminds that John scudder
implementation works in a stub stub stub core.

Randy summarizes: For confeds, everyone signs on exit. Exit AS knows all the
ASes and strips or goes leftwards by removing all signatures until it reaches
the 1st signature forward andthen forward signs (pubic AS).

Sandy's comment: BGPSec configs allow loops.

31:00 discussion on potential of abuse in confed

Ruediger:more discussion on loops in confeds.
consider a configuration where the confederation is not completely bgpsec. Some
additional work is required to be done. Randy explains how it will work. A
correct confed sequence is required. Wes George and Brian Weis weigh in.

45:30 Sandy asks a question for operators: Do we have to do a unique set of
operations when leaving a confed or not? <unknown> said yes. Ruediger (operator
answer): Yes. Not convinced that everyone keeps the information of all the
partipants in the confed for a large one, so we go with a marking operation.

New additions, how are they dealt with?
Sandy:Warren says that new additions will cause them to have to tell all the
other members. No other choice.

Randy asking everyone whether they understood the ASPAth. Summarizes:

In a confed, every AS signs normally, when you enter the As the first AS within
the confederation sets a flag in the flags field of signature block that says I
am the entrance  of the confederation, the data wanders around wonderfully in
the confed and everyone signs it. At the exit the router where it is existing
looks backwards in the AS sequence until it finds the first instance of that
flag. it strips that sig and all subseq sigs and forward sings to the next
As.While this little packet is traversing the As ifit should hit a peering
where the deestination isan external As is not bgpsec capable, just as normal
it must recostruct the classic AS-As path including using the going left to
find the flag bit to find the sequence.

Question from jabber room Jayb: suppose a bgpsec router that knows it's not in
a confed sees the "start of confed" flag.  should we specify the action to take
in that case?"

ruediger: if someone not in a confed sees a confed flag,it should mark it as
invalid, just as when someone sees two flags set, which is invalid.

Brian Weis suggests having a common algorithm to convert back to an As Path
irrespective of whether inside a confed or not.

more discussion on flag setting at entrance and exits.

No suport for nested configurations.
=====

=====

1:06 Aliasing

Sandy says Use of pcount = 0 does not require changes to the

protocol.
Warren describes What happens when we have aliasing? Currently,

aliasing bob thinks you are called fred but when you talk to the

rest of the world you are joe:
So, how is that handled in BGPsec? <unknown> explains with example.
Warren's concern is it comes back to the lets use pCount=0 hammer.

MOre people means more usage.

Sriram on Slide 9. Explains an example of aliasing. As2--> AS3--

>AS4, with AS2 setting Pcount=0.
Reudiger discusses the example on the slide further. He says

ambulating (?) alias AS is visible in path as it is pushed down to

customer while other way around AS3 is not visible but the customer

As is published. Customer will have to set pcap=0 which is not

allowed. AS4 not expecting transparent then will get angry. Randy

and Warren join the discussion. Result is that of discussion was

that an internal AS cannot set pcount= 0. These rules are made for

protection of everybody.

1:13 Sandy asks for a generic diagram for better explanation in

future.

Sriram asks about AS migration vs. Aliasing.
Reudiger clarifies that AS migration is a use case and Aliasing is

a technique, when asked whether AS migration and Aliasing are one

and the same (question asked by Sandy).

Sandy asks a question about aliasing: when you have two ASes under

similar administrative control and you will use an AS aliasing in

the future. where does this get set?
Randy replies single router configuration, Reudiger explains that

it will be on the router that has a real AS and a fake AS. Wes

George disagrees with the assumption that AS2 is real and AS3 is

fake, they can both be real. The problem with this approach (using

the same approach as with confederations) is that when you forward

sign AS2, and strip AS2 from there the forward signing is now

broken. That cannot necessarily work and is hence a different

problem. If no migration is required, then no issues. Today how it

works is that the right machinery just munges the AS Paths in and

goodness comes out of the other side.
Question from Sandra Murphy: When you set up the aliasing are you

setting up aliasing between AS2 and 3? Ruediger only on a single

side of that session where two ASes are involved.

1:19 pcount=0 discussion comes up, this discussion belongs in the

use cases document. Warren says you do not want to explore all

possible horrible vendor knobs.
Wes will get with Shane and see if the understanding and concerns

regarding the use case are correct. Warren will work with Wes to

flesh out the semantics.
More discussion on pcount=0.
Doug Montgomery makes a comment on pcount=0.

Discussion on going ahead with bgpsec attributes without the

AS_Path attribute.

Sandy mentioned that John (Scudder?) felt that AS_Path should be in

the document but was aware of the problems associated with doing

that.
In summary, Randy said that here is where we should leave this

discussion today. These are the scanarios that might require

rechaining the AS path. We have not seen that requirement. We think

that we can do them, here's how we can do them. They do not require

the AS_path and therefore we do not feel AS_Path will go back into

the document.
Randy asked if anyone had any strong objections to this. No

objections were voiced in the room or on the phone.

Matt Lepinksi said we will make the document more clear with

respect to AS_Path.

1:50 Next topic: Keying and Rekeying

Rob Austein asks if we can get away with just generating keys on

the router? Randy Bush and Rob Austein talked about people not

going to spend the money to do it the cryptographically pure way,

therefore hotswappable looks the way to go.

Discussion on eeprom between Warren, Randy.

Brian discusses the WG document -01 which had a few changes based

on discussions in Paris.

Warren asks about keeping track of the state of documents in the

working group, Sandy refers to the wiki page.

Randy Bush: We should recommend that the second certificate should

always be provisioned. All you will have to do is revoke a new one

(the third)

Brian agrees. Asks what is the maximum number of keys?

Warren says some people will disagree because they will have twice

as much keying information sitting around that they have to keep

track of. If someone has compromised the first they have probably

compromised the second.

Randy Bush feels that adding the second set is no worse.

Sean Turner says that all you can say is that you must keep the

private secret.

Sriram said that everytime you roll the key you need to repropagate

all prefixes in your rib. You do have a choice for the frequently

rolling keys. You only propagate what you originate. If the key

doesnt change, then nothing changes.

Definition of replay was set as send update to peer, then withdraw,

then the peer either suppresses the withdraw or sends update

further along.

Sriram wants to note that we have not solved the problem of a

single prefix withdraw.

Brian Weiss: It does not solve all possible replays.

Next topic: Performance considerations

Andree Toonk: Shared some observations from using the RIPE

validator against various repositories. Fairly high rate of failure

synching to repository.  How long can a repository be off line?
Timeouts , certificate revocation lists that are stale, validator

declared everything invalid.
Sometimes several days when repositories are unavailable.

Rob Austein talks about the caching structure. Rsync was a good

first try but it is showing some issues. We are alot further than

we would have been without it. But, it may be time to reconsider

that. With rsync, no way to amortize the synching costs with the

flat file structures. We do not know the cost of the failures we

are seeing. We aren't getting help with debugging.
There is speculation that IPv6 might have something to do it.

The validators (RIPE's,BBN's and Rob's) need more data and

troubleshooting.

Sriram Slide #2
Acceptable convergence time, how long does it take to converge no

bgpsec. They use an OTS router XCJ turned up, same no. of routes,

AS_Paths, etc. and get average convergence rates.

Wes indicates that how long does it take to converge from a session

reset, is the metric.
Randy Bush says for CRJ 3 hours to boot, 3 minutes to converge.

Discussion of what should be reasonably measured. What is the

definition of convergence in this context?
You do not need to validate to propagate (says the spec)
What you need to do to prevent a real mess is not strip.
(Lengthy discussion on performance issues.)
lazy vs strict more operation. impacts on reconvergence.
Doug Montgomery says that the assumption here is that lazy is not a

steady state, but a temporary state on reset.

Doug mentions that after converging there might be a lot of junk

coming in.
Randy says that if he sent rubbish it will be caught at the next

router.
Brian asks how will the next router know that it is rubbish?

Reudiger raises question about delays and if large sessions occur

Sandy asks when does one go from lazy mode to strict mode?

Wes George: convergence does not equal convergent filters. Need to

articulate that and the expectation. Cert and security side not

measuring time but giving implementers a time about how long their

lazy state is going to be.

Sandy brings up the discussion about future meetings.

End of meeting.