Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19

[Randy Bush]

> potentially repeating BGP IDs

not weighing in on the rest.  but i am not sure what you mean by bgp
id.  if it is routerID, those are unique within an AS.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Mirja Kuehlewind]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-sidr-bgpsec-ops-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/



--
COMMENT:
--

Quick question: I'm by far not an expert here, but I remember that there
used to be some concerns that it is practical not possible to disable
BGPsec once enabled. If that's (still) true, should this be mentioned
here?


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

> Quick question: I'm by far not an expert here, but I remember that
> there used to be some concerns that it is practical not possible to
> disable BGPsec once enabled. If that's (still) true, should this be
> mentioned here?

i am not sure what you mean, so let me guess.

an established bgp session has negotiated simplex or duplex bgpsec via
bgp capability exchange.  one can not change the agreement without
tearing down and restarting the session.

a router which is bgpsec enabled, receives a signed path from the left,
but on the right it had a non-sec session, strips the bgpsec info from
the path.

these are discussed in the bgpsec protocol document.  section 6,
appended to save dumster diving, shows some of the operational uses of
this.  do you have suggestions for other examples worth enumerating?

randy

6.  Considerations for Edge Sites

   An edge site which does not provide transit and trusts its
   upstream(s) SHOULD only originate a signed prefix announcement and
   need not validate received announcements.

   An Operator might need to use hardware with limited resources.  In
   such cases, BGPsec protocol capability negotiation allows for a
   resource constrained edge router to hold only its own signing key(s)
   and sign its announcements, but not receive signed announcements.
   Therefore, the router would not have to deal with the majority of the
   RPKI, potentially saving the need for additional hardware.

   As the vast majority (84%) of ASs are stubs, and they announce the
   majority of prefixes, this allows for simpler and less expensive
   incremental deployment.  It may also mean that edge sites concerned
   with routing security will be attracted to upstreams which support
   BGPsec.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Mirja Kuehlewind (IETF)]

Hi Randy,

thanks for you quick reply.

I actually might be mixing this up with some discussion about DNSsec a while 
ago, where the problem was that once enable others will remember that it was 
supported and will not accept non secured requests anymore. 

But as we are talking about this, could there be a similar case here, where a 
router is known to support BGPsec and others would ignore/drop non-signed 
announcements? (Sorry if that’s all discussed in the protocol doc; in this case 
just ignore my questions ;-); didn’t review the protocol spec yet but it’s the 
next doc on my list; probably should have read that one first…)

Mirja


> Am 02.01.2017 um 14:45 schrieb Randy Bush :
> 
>> Quick question: I'm by far not an expert here, but I remember that
>> there used to be some concerns that it is practical not possible to
>> disable BGPsec once enabled. If that's (still) true, should this be
>> mentioned here?
> 
> i am not sure what you mean, so let me guess.
> 
> an established bgp session has negotiated simplex or duplex bgpsec via
> bgp capability exchange.  one can not change the agreement without
> tearing down and restarting the session.
> 
> a router which is bgpsec enabled, receives a signed path from the left,
> but on the right it had a non-sec session, strips the bgpsec info from
> the path.
> 
> these are discussed in the bgpsec protocol document.  section 6,
> appended to save dumster diving, shows some of the operational uses of
> this.  do you have suggestions for other examples worth enumerating?
> 
> randy
> 
> 6.  Considerations for Edge Sites
> 
>   An edge site which does not provide transit and trusts its
>   upstream(s) SHOULD only originate a signed prefix announcement and
>   need not validate received announcements.
> 
>   An Operator might need to use hardware with limited resources.  In
>   such cases, BGPsec protocol capability negotiation allows for a
>   resource constrained edge router to hold only its own signing key(s)
>   and sign its announcements, but not receive signed announcements.
>   Therefore, the router would not have to deal with the majority of the
>   RPKI, potentially saving the need for additional hardware.
> 
>   As the vast majority (84%) of ASs are stubs, and they announce the
>   majority of prefixes, this allows for simpler and less expensive
>   incremental deployment.  It may also mean that edge sites concerned
>   with routing security will be attracted to upstreams which support
>   BGPsec.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)

[Borchert, Oliver (Fed)]

See my comments inline

On 12/29/16, 6:23 PM, "sidr on behalf of Randy Bush"  wrote:

>>> 1. It is common to use private ASNs in Confederations, 
>> but the global RPKI can’t support that.  draft-ietf-sidr-slurm seems
>> to address the issue of local management of private resources in the
>> RPKI.  …

>the issue is not how the confed AS validates ROAs of the private ASs in
>the confed.  that is trivial and supported by existing software.  my
>questions revolve around path processing.


I believe the answer to your question is found in section 7, paragraph #8 and 
following. 
There I see explanation on how to process the path using private AS numbers, 
etc.


>4.3 confuses me by using 'private' ambiguously.  i have tried to read
>that section yet again and drowned in the mass of words.  perhaps more
>coffee will help; but i am not optimistic.  i pity the implementors. 
>
>randy

Revisiting Section 4.3, I made the following observations:
In my opinion the second Paragraph explains clearly the process of the ingress 
BGPSec 
router at the confederation boundary. I believe the process described of adding 
a 
signature with pCount=0 will resolve the issue that Alvaro observed.

Said that, I feel that the explanations in paragraphs #3 and #4 are not very 
helpful. 
There I do agree with Randy's "mass of words" comment. I suggest to either 
shorten 
them or completely remove them. These two paragraphs are not needed, in 
contrary 
they might add unnecessary confusion.

When removed the following current paragraphs 5 and following do explain 
clearly the
process in the intermediate AS-members and the egress BGPSec router of the 
confederation.

In short I think paragraphs #3 and #4 disrupt the flow and are not so helpful,
so I propose to remove them.

To avoid unnecessary confusion with the ambiguity of the word private, I would 
change 
the wording of “the (private) Member-AS Number” to “the Member-AS Number” by 
removing the wording of “(private)” within parenthesis. 
This leaves the usage of private only for the signing parties private key which 
I think 
is well understood.

Oliver 

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

hi mirja,

> could there be a similar case here, where a router is known to support
> BGPsec and others would ignore/drop non-signed announcements?

h.  as far as i can remember, this has not actually been discussed.

how would a router be known to support bgpsec?  well, if i saw it on a
signed path.  (for the moment, let's ignore changes over time).  but it
might have an out-degree of O(100) and some portion are signed and the
rest not.  the ones that are not signed are due to the peer not
negotiating bgpsec, or that one or the other is configured to not have
the peering be bgpsec.

and it's way too late here for me to do the necessary deep dive into
draft-ietf-sidr-bgpsec-pki-profiles-18.txt to know if i can definitively
identify a router, especially as one router can have multiple ASs and
therefore multiple certs and therefore multiple skis.

maybe someone on the us beast coast has had enough coffee to hit me with
a clue by four when i wake.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Chris Morrow]

At Tue, 03 Jan 2017 00:33:49 +0900,
Randy Bush  wrote:
> 
> hi mirja,
> 
> > could there be a similar case here, where a router is known to support
> > BGPsec and others would ignore/drop non-signed announcements?
> 
> h.  as far as i can remember, this has not actually been discussed.

i think this is correct.
(I don't remember discussing something like this in the past)

I can imagine a future where the operations staff decides: "We only do
bgpsec (with peers x, y, z) turn on the knob that requires bgpsec at
peer establishment!"

In that case, if it were to be true, the operator would have chosen to
only do bgpsec and not fallback to normal bgp... The router(s) aren't
really remembering that their peer did bgpsec in the past as much as
requiring the bgpsec capability at peer 'connect'.

> how would a router be known to support bgpsec?  well, if i saw it on a
> signed path.  (for the moment, let's ignore changes over time).  but it
> might have an out-degree of O(100) and some portion are signed and the
> rest not.  the ones that are not signed are due to the peer not
> negotiating bgpsec, or that one or the other is configured to not have
> the peering be bgpsec.

I bet with a distant view of one ASN (or all ASN) you could tell, over
time, whom the ASN peers with via 'bgpsec' vs 'bgp'. You MAY choose to
do some policy stuff that says: "ASN X, Y, Z seem to always do bgpsec
with +XX% of their peers in my view of them... so only accept routes
originated by these ASN if the routes arrive on bgpsec-enabled
peerings."

This seems dangerous, today anyway, but maybe tomorrow it'd be more
feasible? I also don't know that you could easily tell: "the router"
vs "the asn", because as you get further away on the network your
entrypoint (and whom in that ASN you hear routes FROM) to the remote
ASN is less guaranteed.
 
> and it's way too late here for me to do the necessary deep dive into
> draft-ietf-sidr-bgpsec-pki-profiles-18.txt to know if i can definitively
> identify a router, especially as one router can have multiple ASs and
> therefore multiple certs and therefore multiple skis.
> 
> maybe someone on the us beast coast has had enough coffee to hit me with
> a clue by four when i wake.
> 
> randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

ok, i have had coffee.

as a bif gedanken experiment, posit a global registry where r0 can say
"i can speak bgpsec."  i am a distant r1 and receive an unsigned path
with r0 in it.
  o did someone before r0 on the path not speak bgpsec, so the path was
never signed?
  o did someone between us not speak bgpsec, so the path was stripped?
  o was there a monkey in the middle?

i think we did discuss this problem space, and decided that, as long as
we allow islands of partial deployment, and therefore path stripping,
the monkey is on our back.  we might have been wrong in this; but even
with coffee i do not see a way out.

and i do not think the idea of partial path signing, r0 signing a
received unsigned path, would have helped a lot.

it is not clear to me that this is a space where the ops doc can help
much.  i am open to ideas.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Review of draft-ietf-sidr-rpki-oob-setup-05

[Roni Even]

Reviewer: Roni Even
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.
Please resolve these comments along with any other Last Call comments
you may receive.
Document:  draft-ietf-sidr-rpki-oob-setup-05
Reviewer: Roni Even
Review Date:2017-1-3
IETF LC End Date: 2017–1-10
IESG Telechat date:  

Summary: This draft is ready for publication as a standard track RFC.


Major issues:

Minor issues:

Nits/editorial comments:



___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)

[Sriram, Kotikalapudi (Fed)]

>From: Randy Bush 
>Sent: Thursday, December 29, 2016 6:02 PM

>that is not the core of the problem.  the bgpsec protocol doc has to
>specifically say that the public AS upon receiving the update from the
>private AS
>  o if the private signed to the public, public should check sig, then
>strip it and then might sign as the originating AS or might not.  on
>what criteria does it decide?
>  o if the private did not sign, the public might sign or it might not.
>on what criteria does it decide?

>as i said, once you burn that in, i will hack the ops doc

Does this change (in Section 7 in the document) work for you?

[OLD]

   It is possible that a stub customer of an ISP employs a private AS
   number.  Such a stub customer cannot publish a ROA in the global RPKI
   for the private AS number and the prefixes that they use.  Also, the
   stub customer cannot become a BGPsec speaker.  If a BGPsec speaker in
   the ISP's AS receives an announcement for a prefix from the stub
   customer and chooses to propagate it to BGPsec peers, then it MUST
   strip the private AS and re-originate the prefix.  In order to do
   this, the prefix MUST have a ROA authorizing the ISP's AS to
   originate it.

[NEW]

   It is possible that a stub customer of an ISP employs a private AS
   number.  Such a stub customer cannot publish a ROA in the global RPKI
   for the private AS number and the prefixes that they use.  Also, the
   global RPKI cannot support private AS numbers for issuing router
   certificates for eBGP routers in the private AS.  For interactions
   between the stub customer and the ISP, the following two scenarios
   are possible:

   1.  The stub customer sends an unsigned BGP update for a prefix to
   the ISP's AS.  An edge BGPsec speaker in the ISP's AS may choose
   to propagate the prefix to its non-BGPsec and BGPsec peers.  If
   so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the
   private AS number, and then (a) re-originate the prefix without
   any signatures towards its non-BGPsec peer and (b) re-originate
   the prefix including its own signature towards its BGPsec peer.
   In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in
   the global RPKI authorizing the ISP's AS to originate it.

   2.  The ISP and the stub customer may use a local RPKI repository
   (using a mechanism such as described in [I-D.ietf-sidr-slurm]).
   Then there can be a ROA for the prefix originated by the sub AS,
   and the eBGP speaker in the stub AS can be a BGPsec speaker
   having a router certificate, albeit the ROA and router
   certificate are valid only locally.  With this arrangement, the
   stub AS sends a signed update for the prefix to the ISP's AS.  An
   edge BGPsec speaker in the ISP's AS validates the update using
   RPKI data based the local RPKI view.  Further, it may choose to
   propagate the prefix to its non-BGPsec and BGPsec peers.  If so,
   the ISP's edge BGPsec speaker MUST strip the Secure_Path and the
   Signature Segment received from the stub AS with the private AS
   number, and then (a) re-originate the prefix without any
   signatures towards its non-BGPsec peer and (b) re-originate the
   prefix including its own signature towards its BGPsec peer.  In
   both cases (i.e. (a) and (b)), the prefix MUST have a ROA in the
   global RPKI authorizing the ISP's AS to originate it.

Sriram
 

 


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr