[sidr] Draft minutes from IETF78 Maastricht

[Sandra Murphy <[e-mail]>]

Here are the draft minutes from IETF78 in Maastricht.  Thanks to Vesna 
Manojlovic for volunteering to produce the minutes.

Please send corrections, comments, additions, etc., to the list.  Final 
minutes are due 15 Sept.

These minutes have been uploaded to the IETF web site.

--Sandy

Secure Inter-Domain Routing WG (sidr)
78th IETF, Maastricht 
WEDNESDAY, July 28, 2010 
1300-1530  Afternoon Session I
Auditorium 2
=====================================================
CHAIR(s): Sandra Murphy <Sandra.Murphy at Sparta.com>
           Chris Morrow <[e-mail]>
 	(audio recording available)
AGENDA:
  1) Administrivia
    - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html
    - WG Resources: http://tools.ietf.org/wg/sidr/
    - Minute taker: Vesna Manojlovic
    - Jabber Scribe: Warren Kumari
    - Blue Sheets
    - Agenda Bashing

Last Call status (slide #5)
New WG documents (slide #6)


2) Requested Discussion Topics

a) Removing TLS from the Provisioning Protocol 
Rob Austein 
http://www.ietf.org/proceedings/78/slides/sidr-0.pdf

TLS was added to  "up-down protocol" specification.
TLS would theoretically protect from Replay Attack (example).
Easier Replay protection; CMS timestamps, serial numbers,
CMS introduces another problem, with MitM.

Gregory: reboot.
There are details that need to be worked out.
A: Serial number

Robert K.: if the MitM consistently keeps dropping messages, that is DoS.

Jabber: Mike Hammond: if you include in your message which time-stampt 
you are obsoleting, that solves it.
A: Gaps in the sequence, clock is not good enough.

Speaker: We do not currently have with TLS protection against MitM. It 
could be a good additional requirement, but we would not lose it if we 
drop TLS.

b) Alternative to the Trust Anchor Format 
Samuel Weiler
http://www.ietf.org/proceedings/78/slides/sidr-11.pdf
draft-weiler-sidr-trust-anchor-format

Randy Bush: I disagree, we often have opportunities to simplify the 
drafts. I suggest we do not pass on this one.

Robert: I prefer this one.
Steve Kent: 1) it tries to re-define trust anchors, no need.
3779 tells you.
This is the alternative.
Q: What do you call it?
Mechanism to verify the ... (?!)
"something different".
If this is going to become an Equivalent alternative, I've already 
suggested some changes in the comments to the list...

Sandy: So, I hear there are some wording issues, no significant objection?

A: If you add Second level, and the CRL.

Randy: I would stress "explicit requirements".

Rob Austin: I support it.
A question to Steve: level of indirection, two level approach is a MUST?
Does the WG agree to it being a MUST, or a SHOULD?
I seem to recall the list supports the SHOULD. Why MUST?
Steve Kent: Mandating good security practices.
Sandy: I'll put the question to the mailing list.

3) Key Rollover
     (a) Key Rollover at RIPE     NCC
         Presenter: Tim Bruijnzeels
http://www.ietf.org/proceedings/78/slides/sidr-1.pdf

Roque: Is deletion also manual, or the batch process?
A: The start is manual, the rest is automated. I'm happy to do it either 
way.

Rob Austin: I understood that all the algorithms are the same.
Differences: no waiting period (?!) [staging period?]
A: We go straight to the publication.

     (b) Key Rollover
         Presenter: Steve Kent
http://www.ietf.org/proceedings/78/slides/sidr-7.pdf
http://tools.ietf.org/id/draft-huston-sidr-aao-profile-0-keyroll-00.txt
http://tools.ietf.org/id/draft-huston-sidr-repos-struct-02.txt

Geoff: Step 5 happens after the staging period, not during.
Geoff: "short" period means  Minutes, not hours.

This is the new document, so it needs review.

Rob: all the implementations are doing more-less this.
Comment: Lock around rsync will be .. pain in the but.
I am not sure if the staging is necessary at all.

Steve: We disagree. Let me explain why...
Rob: OK, I have less problem with that.

Rob: Do we really need to have the waiting period and locking so many 
things out?
Geoff: The reason for suspension is to generate the clean overwrite.

Sandy: It would be useful for this to happen as the conversation on the 
list.

4) Algorithm Migration
    Presenter: Roque Gagliano
http://www.ietf.org/proceedings/78/slides/sidr-2.pdf

Requested by Security AD.

Summary: 3 questions:
1) Do we want to support only top-down algorithm transitions?
2) Do we want to support multiple signatures in CMS objects?
3) Any validation issue...?

Robert: No, No, and "as long as there is *one* ROA that validates, you 
should accept"

Paul Hofman: 1) No "top down". It will get in the way...
Argue towards the "laisser faire".

Rob:
1) I would like to understand it as "the Top-down is the minimum ..." 
(what?!)
relying party is only
2) I am not sure it is worth going through all the trouble...
I could live with the (...??)

Steve Kent: You can not stop using the OLD algorithm, until the "end of 
life" / twilight.
That is why the top down makes lots of sense.

Geoff: I suspect that the transition means the relying party using 
"current" and "new"
Sandy: this validates Steve's argumentation.

6) Updated Drafts
     (a) Certificate Policy
     Certificate Policy (CP) for the Resource PKI (RPKI)
     http://tools.ietf.org/html/draft-ietf-sidr-cp-09
     Presenter: Karen Seo

http://www.ietf.org/proceedings/78/slides/sidr-6.pdf

(b) RPSL Signatures
     Securing RPSL Objects with RPKI Signatures
     http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-03
     Presenter: Robert Kisteleki

http://www.ietf.org/proceedings/78/slides/sidr-5.pdf


(c) Use Cases
     Use Cases and interpretation of RPKI objects for issuers and relying
     parties
     http://tools.ietf.org/html/draft-ietf-sidr-usecases-00
     Presenter: Sriram Kotikalapudi

http://www.ietf.org/proceedings/78/slides/sidr-3.pdf

7) New Drafts
     (a) Publication Protocol
     A Publication Protocol for the Resource Public Key Infrastructure
     (RPKI)
     http://tools.ietf.org/html/draft-weiler-sidr-publication-00

     Presenter: Sam Weiler

http://www.ietf.org/proceedings/78/slides/sidr-12.pdf

Are we ready to adopt this to the work item?

Sandy: Will send a question to the mailing list.


8) New Topic

     (a) AS_SET, Aggregator Stats and Implications for the {Prefix, Origin}
         Validation Algorithm

     Presenter: Sriram Kotikalapudi

  http://www.ietf.org/proceedings/78/slides/sidr-4.pdf

Q: Closest to the origin?
A: The most recent AS is the extreme left, origin AS is the extreme right.

Almost in all cases, the first AS after the AS_SET is the origin AS, 
therefore the Recommendation - disregard the aggregator!

John Scutter, Juniper networks: OK

?: Can not treat the agreggator like that, ....

4-bite AS purposes: additional consistency checks need to be performed.

AS SET is optional

Rudiger: I am not sure if the new attack type is any different then any 
other attack that can be performed by such attacker.

Private ASN should not show up. BGP specs need clean-up.

Gregory, France Telecom: Conclusions based on current statistics. If we 
base the algorithm on this, add recommendation to do have the correct 
ASN behind the aggregator.

John Scudder: It does make sense from the PoV of how the AS path is 
constructed.

5) Use of RPKI in Routers

     (a) RPKI Use in Routers
     The RPKI/Router Protocol
     draft-ymbk-rpki-rtr-protocol-06.txt
     http://tools.ietf.org/html/draft-ymbk-rpki-rtr-protocol-06
    Presenter: Randy Bush

http://www.ietf.org/proceedings/78/slides/sidr-8.pdf

Q: Alexis: should it also reevaluate discarded prefixes?
A: (?)

Q: What happens when there is no other cache?
A: Start paddling!

      (b) BGP Prefix Origin Validation
     draft-pmohapat-sidr-pfx-validate-07
     http://tools.ietf.org/id/draft-pmohapat-sidr-pfx-validate-07.txt
    Presenter: Randy Bush

http://www.ietf.org/proceedings/78/slides/sidr-9.pdf

Solution: allow the operator to test the validity, and set local policy

Q: Does something prevents the router to rewrite the policy?
A: (?)

John: you want all the routers to follow the same policies
Jeff: advertise best-external-always

Q: Alexei: if all 3 have different state...
A: The reason for this is: Incremental deployment. When I add my first 
router (with RPKI), I can add this to my existing policy.

Dani: If your different routers can have different cashes... then you 
have bigger problem.

Rob Austin: Global distributed DB. They will not have the same view nor 
consistent state.

6) Updated Drafts

     Validation Signaling
     BGP Prefix Origin Validation State Extended Community

  http://tools.ietf.org/id/draft-pmohapat-sidr-origin-validation-signaling-00.txt
      Presenter: Keyur Patel

http://www.ietf.org/proceedings/78/slides/sidr-13.pptx

Defining the new extended community.

Randy: Let's have this as the WG draft, so I can disagree with it.

Alexis: I don't see why do we need 3 new community space for 3 new 
communities. Nor global well knows communities. You cna just choose
A: It's just one, with 3 bits.
Anyway, it is in my opinion, polluting the number space.

John Scudder: I mostly agree, but with regular communities there is no 
transitivity bit.

Dani: I support this.

Randy: I think it could be useful for diagnostics.

Final comment by the Chair: NRO has the deadline at 1.1.2011 to start 
operations with RPKI.
It would be good if our documents be out of the Last Call. Before the 
Beijging meeting.

Please comment on drafts!

(next meeting - please send the slides before the day of the session).