Re: [sidr] [Technical Errata Reported] RFC6482 (7079)

[Randy Bush]

> Original Text
> -
>Before a relying party can use a ROA to validate a routing
>announcement, the relying party MUST first validate the ROA.  To
>validate a ROA, the relying party MUST perform all the validation
>checks specified in [RFC6488] as well as the following additional
>ROA-specific validation step.
> 
>o  The IP address delegation extension [RFC3779] is present in the
>   end-entity (EE) certificate (contained within the ROA), and each
>   IP address prefix(es) in the ROA is contained within the set of IP
>   addresses specified by the EE certificate's IP address delegation
>   extension.
> 
> Corrected Text
> --
>Before a relying party can use a ROA to validate a routing
>announcement, the relying party MUST first validate the ROA.  To
>validate a ROA, the relying party MUST perform all the validation
>checks specified in [RFC6488] as well as the following additional
>ROA-specific validation step.
> 
>o  The IP address delegation extension [RFC3779] is present in the
>   end-entity (EE) certificate (contained within the ROA), and each
>   IP address prefix(es) in the ROA is contained within the set of IP
>   addresses specified by the EE certificate's IP address delegation
>   extension.
>o  The AS Resources extension is not used in Route Origin Authorizations
>   and MUST be omitted.

while i agree with the sentiment, to this amateur, this smells more like
a bit more of a change than an erratum.

randy

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

Re: [sidr] [Errata Held for Document Update] RFC6480 (5196)

[Randy Bush]

> --
>   3. For each manifest, verify that certificates and CRLs issued
>  under the corresponding CA certificate match the hash values
>  contained in the manifest.  Additionally, verify that no
>  certificate or CRL listed on the manifest is missing from
>  the repository.  If the hash values do not match, or if any
>  certificate or CRL is missing, notify the appropriate
>  repository administrator that the repository data has been
>  corrupted.
>
> On the fourth line: it should read "certificate or CRL" instead of
> "certificate or manifest".

while you are at it, data are plural

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

Re: [sidr] [Editorial Errata Reported] RFC6487 (5187)

[Randy Bush]

> What about certificate that contain IP address set only OR AS number set
> only (not both)?

s/and/or/ seems formally correct, albeit a bit nitty

>>> Original Text
>>> -
>>>  encompass
>>> Given two IP address and AS number sets, X and Y, X
>>> "encompasses" Y if, for every contiguous range of IP addresses
>>> or AS numbers elements in set Y, the range element is either
>>> "more specific" than or "equal" to a contiguous range element
>>> within the set X.
>>>
>>>
>>> Corrected Text
>>> --
>>>  encompass
>>> Given two IP address or two AS number sets, X and Y, X
>>> "encompasses" Y if, for every contiguous range of IP addresses
>>> or AS numbers elements in set Y, the range element is either
>>> "more specific" than or "equal" to a contiguous range element
>>> within the set X.

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

Re: [sidr] RPKI-RTR implementation clues

[Randy Bush]

>> I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd
> This is not directly related to your question, but note that the new
> RFC, standardizing the new version of RTR (version 1, RFC 6810 was
> version 0) is in AUTH48-DONE and can be published any time now
> 

you may also find draft-ymbk-sidrops-ov-clarify-01.txt useful

randy

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

Re: [sidr] RIR's moving to all resources (0/0) RPKI TA's

[Randy Bush]

> FYI.  While excellent progress is ongoing with the alternative
> algorithm specified in draft-ietf-sidr-rpki-validation-reconsidered,
> it is worth noting that the RIRs will presently be moving to all
> resource RPKI TA’s to help mitigate the risk of massive downstream
> invalidation that would occur in the case of inconsistencies under
> present validation algorithm:

what continues to amuse me is that all these contortions address rir
failures we have not seen; while the failures we have seen (ee cert in
manifest expiration timing, etc.) have not been systematically
addressed.

randy

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

Re: [sidr] [Errata Held for Document Update] RFC7115 (4973)

[Randy Bush]

> In some cultures, the number 666 is supposed to be the number of “the
> beast”, i.e. the devil, and therefore a sign of evil.  The text
> chooses this number 666 in the prefix 10.0.666.0/24 with the intent to
> imply that the announcement is deliberately evil, disregarding the
> fact that 666 is not a legitimate ipv4 prefix octet.
> 
> Of course, I’m not the author, so I could be wrong.

you are, but no big deal.  it could have been anything gt 255, but i
knew 666 would catch the western eye.

randy

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

Re: [sidr] [Sidrops] operator inputs -- route leak solution

[Randy Bush]

> With all due respect, your draft fails to acknowledge the earlier work by
> me (from 2012), outside of the recent drafts of which I am a
> co-author.

apologies.  this should be corrected,

> So, perhaps it would be best to avoid claims of plagiarizing, when (a)
> there is clear evidence that the source of the material predates your work,
> and (b) when your work does not credit the original work by me.

word for word

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

Re: [sidr] [Editorial Errata Reported] RFC7115 (4973)

[Randy Bush]

666 was not accidental.

randy

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

Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)

[Randy Bush]

> ebgp neighbor? the text talks about ibgp, and about explicitly
> ignoring ebgp senders of this community (by default).

if it does not say MUST NOT accept from ebgp, the jakob has to have
code.  imiho, it sould say MUST NOT accept from engp.

randy

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

Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)

[Randy Bush]

> The ext-comm may come from an ebgp neighbor.

ok.  saves a character.  my kind of change :)

  "Similarly, a receiving BGP speaker, in the absence of validation
   state set based on local data, SHOULD derive a validations state from
   the last octet of the extended community, if present."

randy

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

Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)

[Randy Bush]

> Section 2, 3rd paragraph:
> 
>   "Similarly on the receiving IBGP speakers, the validation
>state of an IBGP route SHOULD be derived directly from the last octet
>of the extended community, if present."
> 
> to:
>  "Similarly on the receiving IBGP speakers, the validation state of
>   an IBGP route SHOULD be derived directly from the last octet of the
>   extended community, if present. A receiving router should use
>   locally achieved validation state before trusting an IBGP neighbors
>   state information."

sure.  or, tersified, 

  "Similarly, a receiving IBGP speaker, in the absence of validation
   state set based on local data, SHOULD derive a validations state from
   the last octet of the extended community, if present."

randy

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

Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)

[Randy Bush]

i am very confused.  what is the actual problem here?

if the community arrives at a router that has computed a validation
state from local data, the community's state must be ignored.

does the spec need to be clarified in this aspect?  if so, text would be
helpful.

randy

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

Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)

[Randy Bush]

> What happens if a BGP speaker validates a route in its own RPKI
> database and finds it to be either Valid or Invalid (not NotFound) and
> also receives the extended community that specifies a different
> validation state?
> 
> I don't see that condition covered in the draft.
> I would say to ignore the extended community.

agree

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

Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT)

[Randy Bush]

>>> - section 9: What's the background to removing the statement
>>> that one of TCP-AO ssh etc SHOULD be used? What is the reality
>>> of deployments here? I assume it is not TCP-AO anyway but does
>>> TLS or SSH get used?
>> 
>> TCP-AO never maaterialized.
>> 
>> off-hand, i can not think of a way to measure who is using what, but i
>> have this horrible suspicion it's all "it's all inside our domain of
>> control, so let's just run nekkid."
> 
> Yeah that's the concern. If the answer was "seems mostly folks
> use ssh" (or tls, or ipsec, whatever), I'd have asked if we
> could get away with at least a SHOULD-use for that.
> 
> Such encouragement would be good IMO, if it's non-fiction.

i hack routers and servers daily to keep from becoming a complete bs
artiste.  so of course i tried setting up and running each transport.
ssh was painful; key-based did not work for many platforms, ...  no AO
on any platform i could find.  no TLS client side support.  and there is
a special hell where you have to do a device-diverse deployment of ipsec
once a day ( smb has a student who did a good paper on this).

luckily, ipv6 comes with secure transport built in.  oh wait.

i fear we are in yet another case of security software is not easy to
use so we shift the blame to the user.  we've gotten good at that.

i think that all this is designed to make me happy to go back to hacking
on a paper in latex.

randy

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

Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT)

[Randy Bush]

> - section 9: What's the background to removing the statement
> that one of TCP-AO ssh etc SHOULD be used? What is the reality
> of deployments here? I assume it is not TCP-AO anyway but does
> TLS or SSH get used?

TCP-AO never maaterialized.

off-hand, i can not think of a way to measure who is using what, but i
have this horrible suspicion it's all "it's all inside our domain of
control, so let's just run nekkid."

> - various places: I think 6810 was correct in using "that" and
> not "which" in many places. I realise that's a fairly frequent
> style thing that gets toggled though, but I bet the RFC editor
> sets a load of those back to "that" :-)

chicago style.  the rfced and we amuse ourselves over that one.  which
is why rfced gets the big bucks.

randy

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

Re: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT)

[Randy Bush]

> why is there no associated error checking for the Max Length field in
> the IPvX PDUs

it is assumed any error checking was done *before* they are sent to the
router.  a major goal of this protocol is to relieve the router of any
load.  so, if field consistency is to be done, it should be in the
protocols at the rpki level, e.g. at the latest when the cache receives
and validates the data.

randy

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

Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT)

[Randy Bush]

 4) How can URI of the service be discovered?
>>> Out of scope, but draft-ietf-sidr-oob-setup would be one way.
>> I was thinking that defining a .well-known HTTP URI prefix would be a
>> good idea
> it rarely is.  in this case it is a really bad idea.  the services are
> not associated with the domain name; it is a coincidence.

  a friend "suggested" i be clearer.  :)

i run a publication server.  a half dozen CAs publish there.  only one
of the CAs has a domain name related to that of the publication server.

and having to futz around with the dns would be a non-useful pita while
provisioning.

to be clear, this stuff has nothing to do with bgp or the dns, unlike
92.3% of the rest of the internet :)

randy

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

Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT)

[Randy Bush]

>>> 4) How can URI of the service be discovered?
>> Out of scope, but draft-ietf-sidr-oob-setup would be one way.
> I was thinking that defining a .well-known HTTP URI prefix would be a
> good idea

it rarely is.  in this case it is a really bad idea.  the services are
not associated with the domain name; it is a coincidence.

randy

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

Re: [sidr] EE cert to RTR

[Randy Bush]

> https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08

dragon research labs software supports it.  drl relying party cacheware
fully supports 6810-bis.  and the drl CA gooey has the router cert
functions you need to create the router certs.

and i presume the two test bgpsec implementations have some way of
generating router certs which you can then use with any relying party
cacheware which supports 6810-bis.

randy

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

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

[Randy Bush]

>>Note that BGPsec update messages can be quite large, therefore any
>>BGPsec speaker announcing the capability to receive BGPsec messages
>>SHOULD also announce support for the capability to receive BGP
>>extended messages [I-D.ietf-idr-bgp-extended-messages].
>> 
>> isn't a MUST, but Section 7 explains this 
>> 
>>In Section 2.2, is was stated that a BGPsec speaker SHOULD announce
>>support for the capability to receive BGP extended messages.  Lack of
>>negotiation of this capability is not expected to pose a problem in
>>the early years of BGPsec deployment.  However, as BGPsec is deployed
>>more and more, the BGPsec update messages would grow in size and some
>>messages may be dropped due to their size exceeding the current 4K
>>bytes limit.  Therefore, it is strongly RECOMMENDED that all BGPsec
>>speakers negotiate the extended message capability within a
>>reasonable period of time after initial deployment of BGPsec.

how about just saying

   A router announcing the capability to send or to receive BGPsec
   updates MUST also announce the capability to send and receive BGP
   extended messages [I-D.ietf-idr-bgp-extended-messages].

and call it a day?

randy

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

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

[Randy Bush]

i had to do some ascii porn for rob to deal with a secdir reviewer for
draft-ietf-sidr-publication.  it may help here.  i added the routers for
this discussion.

   +--++--++--+
   |  CA  ||  CA  ||  CA  |
   +--++--++--+
   |   |   |  Publication Protocol
   |   |   |   draft-ietf-sidr-publication
   +---+   |  ++ Business Relationship Set Up by
   |   |  |  draft-ietf-sidr-rpki-oob-setup
  +v---v--v-+
  | |
  |   Publication   |
  |   Repository|
  | |
  +-+ Distribution Protocols
   |   draft-ietf-sidr-delta-protocol
+--++  and/or rcynic
|  ||
+---v-+ +--v--+  +--v--+
|   Relying   | |   Relying   |  |   Relying   |
|Party| |Party|  |Party|
+-+-+++ +---+-+---+  +-++--+
  | ||  | ||  | |
  | |++ | | +--+  | |  RPKI to Router Protocol (RFC 
6810)
  | | | | | | | | 
draft-ietf-sidr-rpki-rtr-rfc6810-bis
  v v v v v v v v
 / \   / \   / \   / \   / \   / \   / \   / \
|Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr|
 \ /   \ /   \ /   \ /   \ /   \ /   \ /   \ /
  V V V V V V V V


we're talking about 6810-bis here, the rpki-rtr protocol which carries
the router keys and origin roas for bgpsec and origin validation.

it is a total database push from the RP cache to the router, not a
piecemeal router driven request protocol.  so a monkey in the middle
receives no clues as to what the router is using.  there is no side
channel leakage that i can see.  i would be happy to be educated
otherwise.

as 6810[-bis] has stripped the crypto of the rpki validataion chain to
the root TA, it no longer has object security; red alert.  so the two
ops drafts, 7115 for origin validation and draft-ietf-sidr-bgpsec-ops
for bgpsec, try to be very explicit about transport protection for these
data.

draft-ietf-sidr-bgpsec-ops points to rfc 7115 for RP cache advice.

  As RPKI-based origin validation relies on the availability of RPKI
  data, operators SHOULD locate RPKI caches close to routers that
  require these data and services in order to minimize the impact of
  likely failures in local routing, intermediate devices, long
  circuits, etc.  One should also consider trust boundaries, routing
  bootstrap reachability, etc.

  For example, a router should bootstrap from a cache that is reachable
  with minimal reliance on other infrastructure such as DNS or routing
  protocols.  If a router needs its BGP and/or IGP to converge for the
  router to reach a cache, once a cache is reachable, the router will
  then have to reevaluate prefixes already learned via BGP.  Such
  configurations should be avoided if reasonably possible.

  If insecure transports are used between an operator's cache and their
  router(s), the Transport Security recommendations in [RFC6810] SHOULD
  be followed.  In particular, operators MUST NOT use insecure
  transports between their routers and RPKI caches located in other
  Autonomous Systems.

so maybe the bgpsec-protocol document can remove, as opposed to add,
text just this once?

randy

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

Re: [sidr] draft-ietf-sidr-bgpsec-protocol

[Randy Bush]

re keyur's point 4.  the issue is that 4271 has semantics of AS_PATH,
bgpsec replaces it with BGPSEC_PATH, but bgpsec does not explicitly
repeat things such as loop detection using BGPSEC_PATH.  instead of this
becoming another text explosion, a simple statement that, in bgpsec, the
following AS_PATH semantics of 4271: , hold analogously for
BGPSEC_PATH.

randy

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

Re: [sidr] draft-ietf-sidr-bgpsec-protocol

[Randy Bush]

did i miss the response to this?  i think some of the points are
important.

randy

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

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

> Thanks, that helps. Would it make the last sentence say something to
> the effect of "... and MUST additionally be signed by the propagating
> router."?

alvaro has asked me to stop editing

randy

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

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

>> Sorry, I did not mean that stripping was suggested; the previous
>>> phrase (non-normatively) recommends against stripping. My question
>>> is, since the subject of the sentence is "signed paths" whether the
>>> "MUST be signed" language means "MUST NOT strip the signature"
>>> (which I suspect to be the case), or something else.
>> 
>> how about
>> 
>>As the mildly stochastic timing of RPKI propagation may cause
>>version skew across routers, an AS Path which does not validate at
>>router R0 might validate at R1.  Therefore, signed paths that are
>>Not Valid and yet propagated (because they are chosen as best
>>path) MUST NOT have signatures stripped and MUST be signed if sent
>>to external BGPsec speakers.
>> 
>> if not, use larger clue bat
> 
> It's likely I have this particular bat by the wrong end.
> 
> In the last sentence, does "MUST be signed" mean it must have a
> signature (which would seem to make "MUST NOT strip" and "MUST be
> signed" redundant), or does it mean the propagating router must add
> it's own signature in addition to the existing one(s)?

yes, it must preserve the signed path and add its own signature.

randy

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

Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

[Randy Bush]

>> so, i think you are referring to
>> 
>>As core BGPsec-capable routers may require large memory and/or modern
>>CPUs, origin validation based on the Resource Public Key
>>Infrastructure (RPKI), [RFC6811], will occur over some years and
>>BGPsec will start to deploy after that.
>> 
>> as rpki is deployed to a fair extent, origin validation is baked into
>> current routers, and bgpsec in the core will require bigger hardware, OV
>> before BGPsec would seem to be the sequence.
>> 
>> otoh, your last statement is true, an operator will have to set up rpki
>> data before deploying either origin validation or bgpsec.  rpki is
>> needed for both.
>> 
>> so i am not sure what you are suggesting i do.
> 
> I was suggesting re-wording so that the text cannot be read so
> as to mean "don't bother with BGPsec until the entire world has
> finished deploying OV."
> 
> Maybe:
> 
>As core BGPsec-capable routers may require large memory and/or modern
>CPUs, origin validation based on the Resource Public Key
>Infrastructure (RPKI), [RFC6811], will occur over some years and,
>once origin validation has been deployed at an AS, then BGPsec
>can start to deploy in that AS.
> 
> Though I'm not sure that's precisely right either.

ok, how about

   Origin Validation based on the Resource Public Key Infrastructure
   (RPKI), [RFC6811], is in its early phases.  As BGPsec,
   [I-D.ietf-sidr-bgpsec-protocol] may require larger memory and/or more
   modern CPUs, it expected to be deployed incrementally over a longer
   time span.  BGPsec is a new protocol with many operational
   considerations which this document attempts to describe.  As with
   most operational practices, this document will likely evolve.

i am still not in love with it.

longitudinal study: how has the distribution of draft word count pre and
post iesg review changed over time?

for research papers, there is considerable pressure to be terse to get
one's content into restricted page limits.

randy

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

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

[Randy Bush]

> Wait, I thought I wasn’t supposed to duplicate any of the crazy stuff
> from 6487 :)

duplication opens to errors in copying and makes later changes messier

randy

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

Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

[Randy Bush]

> "The considerations for RPKI objects (Certificates, Certificate
> Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]),
> Trust Anchor Locators (TALs) [RFC6490], cache behaviours of
> synchronisation and validation from the section on RPKI Distribution
> and Maintenance of [RFC7115] apply. Specific considerations relating
> to ROA objects do not apply to this document"

done.  one can tell you hang out with lawyers who are paid by the word.
it says the exact same think with six times as many words.

> This is surely early days of BGPsec adoption and use. I have personal
> opinions about how adoption will go and what will be learnt or
> discovered along the way. So I do share Stephen's observation about
> painting one's self into a corner.

we all have our worries.  but when a major rtgsec hits the wsj, at elast
we wil have a plan.

randy

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

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

[Randy Bush]

spencer,

[ btw, your mua seems not to do quoting level in its ascii rendering ]

> you are at the intersection (well actially union) of two twisty sets of
> passages, bgp routing and internet ops.
> 
> > I'm wondering if "the transitive closure of a client's customers" has
> > a precise meaning. I know what a customer is, at the hand-waving
> > level
> 
> the academic, overly-idealized, definitions of customer/provider/peer
> are in https://www.cs.princeton.edu/~jrex/papers/sigmetrics00.long.pdf,
> aka gao-rexford; though this has been shown to apply to the real
> internet far less strictly than many researchers have stubbornly
> assumed; see http://conferences2.sigcomm.org/imc/2015/papers/p71.pdf
> 
> at the network ops level, a 'customer' is an ebgp-speaking AS to which
> you give routes learned from
>   o other custimers
>   o your peers
>   o your upstreams/transits
>   o your internals
> of course, by business arrangement, this might be restricted.
> 
> this may be contrasted with peers and upstreams/transits, to whom you
> give only customer and internal routes.
> 
> > Is "customer" being used a shorthand for another term that isn't
> > depending on an economic transaction?
> 
> exactly
> 
> > (If this was "the transitive closure of a client's clients", for
> > instance, I would know what that meant
> 
> a route reflector's "clients" are ibgp speakers (stress is on the 'i')
> within the RR's AS.  a (possibly improper) subset of those clients may
> be "customer aggregation" routers, i.e. connect via ebgp to ASs of
> external entities (aka customers).  iff one or more of those RR clients
> (or their clients, cf 'transitive closure') speak bgpsec to a customer
> is the RR required to do bgpsec.  if all the customers (which could be
> the null set) of of the RR's clients speak only bgp classic, there is no
> requirement that the RR speak bgpsec.
> 
> 
> I'm wondering if there's another term that's not wrong, and not more
> confusing. If you say there's not, I believe you!

as we said in my long gone compiler days, 'customer cone' is a reserved
word.

> Thanks for catching me up.

no extra charge

randy

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

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

>>> -4, first paragraph: I found "either" followed by "and/or" a bit
>>> confusing. I suggest simply dropping the word "either".
>> 
>>As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers
>>are either capable of generating their own public/private
>>key-pairs and having their certificates signed and published in
>>the RPKI by the RPKI CA system, and/or are given public/private
>>key-pairs by the operator.
>> 
>> but the router(s) might not be capable of generating key-pairs.  they
>> might, they might not, the op may generate or not, or both.  an
>> absurd corner case might be that a router with two ASs has the as0
>> key stuffed by the as0 noc, and the as1 key is generated on device
>> because that is the as1 policy.
> 
> I merely meant that "either" seemed odd for non-exclusive options. I
> take your argument to mean that the options really are non-exclusive.

ok, i will drop the either.

>>> -4, last paragraph: "a prudent operator will..." sounds like it
>>> might be worthy of a SHOULD.
>> 
>> given the previous, how about lower case should
> 
> That would not seem to change anything :-) My point was that the
> language seemed stated in a way that _might_ justify a 2119
> keyword.

ok, upcased SHOULD

>>> -7, paragraph 6: This seems to say that signed paths MUST be
>>> signed. Does the "MUST be signed if sent to external BGP speakers"
>>> mean that the existing signature must not be stripped (as stated
>>> more weakly in the previous sentence), or does it mean the sender
>>> must re-sign the path?
>> 
>>Because of possible RPKI version skew, an AS Path which does not
>>validate at router R0 might validate at R1.  Therefore, signed
>>paths that are Not Valid and yet propagated (because they are
>>chosen as best path) should have their signatures left intact and
>>MUST be signed if sent to external BGPsec speakers.
>> 
>> i am not seeing where bgpsec stripping was suggested; in fact, the
>> opposite.  if router r0 receives a signed path and intends to pass
>> that signed path to the next listener, r0 must sign the path.  i am
>> at a loss to understand your question.  clue bat please.
> 
> Sorry, I did not mean that stripping was suggested; the previous
> phrase (non-normatively) recommends against stripping. My question is,
> since the subject of the sentence is "signed paths" whether the "MUST
> be signed" language means "MUST NOT strip the signature" (which I
> suspect to be the case), or something else.

how about

   As the mildly stochastic timing of RPKI propagation may cause version
   skew across routers, an AS Path which does not validate at router R0
   might validate at R1.  Therefore, signed paths that are Not Valid and
   yet propagated (because they are chosen as best path) MUST NOT have
   signatures stripped and MUST be signed if sent to external BGPsec
   speakers.

if not, use larger clue bat

> As I mentioned in response to Alvaro's comment: Maybe section 2 should
> cite the protocol rather than the overview?

done

randy

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

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

[Randy Bush]

you are at the intersection (well actially union) of two twisty sets of
passages, bgp routing and internet ops.

> I'm wondering if "the transitive closure of a client's customers" has
> a precise meaning. I know what a customer is, at the hand-waving
> level

the academic, overly-idealized, definitions of customer/provider/peer
are in https://www.cs.princeton.edu/~jrex/papers/sigmetrics00.long.pdf,
aka gao-rexford; though this has been shown to apply to the real
internet far less strictly than many researchers have stubbornly
assumed; see http://conferences2.sigcomm.org/imc/2015/papers/p71.pdf

at the network ops level, a 'customer' is an ebgp-speaking AS to which
you give routes learned from
  o other custimers
  o your peers
  o your upstreams/transits
  o your internals
of course, by business arrangement, this might be restricted.

this may be contrasted with peers and upstreams/transits, to whom you
give only customer and internal routes.

> Is "customer" being used a shorthand for another term that isn't
> depending on an economic transaction?

exactly

> (If this was "the transitive closure of a client's clients", for
> instance, I would know what that meant

a route reflector's "clients" are ibgp speakers (stress is on the 'i')
within the RR's AS.  a (possibly improper) subset of those clients may
be "customer aggregation" routers, i.e. connect via ebgp to ASs of
external entities (aka customers).  iff one or more of those RR clients
(or their clients, cf 'transitive closure') speak bgpsec to a customer
is the RR required to do bgpsec.  if all the customers (which could be
the null set) of of the RR's clients speak only bgp classic, there is no
requirement that the RR speak bgpsec.

randy

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

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

> The issue I saw is that section 2 says readers are expected to
> understand bgpsec, and cites the overview for that purpose. Perhaps it
> should cite the protocol doc for the "expected to understand" part

ok.  done.  i would be happier if that document was easier to read and
more concise.

i just pushed

randy

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

Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

[Randy Bush]

> - general: given where we are with deployment I wonder
> would it be a good idea if this document explicitly said
> sometthing to the effect that "it's early days, this is
> what we think is the BCP but that may change over time, so
> while we think doing this is right, be careful to not
> paint yourself into a corner when doing this."

added

As with most operational practices, this document will likely
evolve.

> - intro: this seems to say: first do rpki and only when
> that's finished start on bgpsec - is that really what's
> meant? The rest of the document makes me doubt that. I
> think what you maybe meant was "Any specific ASN needs to
> have setup RPKI for itself before it can speak BGPsec."

we are in a twisty maze of nomenclature.  to be boringly clear (i
suspect you know this stuff, but i believe that you are using the wrong
terms).

The RPKI is the X.509 based hierarchy [rfc 6481] with is congruent
with the internet IP address allocation administration, the IANA,
RIRS, ISPs, ...  It is the substrate on which the next two are
based.  It is currently deployed in all five administrative regions.

RPKI-based Origin Validation [rfc 6811] uses some of the RPKI data
to allow a router to verify that the autonomous system announcing an
IP address prefix is in fact authorized to do so.  This is not
crypto checked so can be violated.  But it should prevent the vast
majority of accidental 'hijackings' on the internet today, e.g. the
famous Pakistani accidental announcement of YouTube's address space.
RPKI-based origin validation is in shipping code from Cisco,
Juniper, AlcLu, and others.

Path validation, AKA BGPsec, is a the next technology step with only
proto/test code.  It uses the full crypto information of the RPKI to
allow a receiver of a BGP announcement to formally cryptographically
validate that the originating autonomous system was truly authorized
to announce the IP address prefix, and that the systems through
which the announcement passed were indeed those which the
sender/forwarder at each hop intended.

so, i think you are referring to

   As core BGPsec-capable routers may require large memory and/or modern
   CPUs, origin validation based on the Resource Public Key
   Infrastructure (RPKI), [RFC6811], will occur over some years and
   BGPsec will start to deploy after that.

as rpki is deployed to a fair extent, origin validation is baked into
current routers, and bgpsec in the core will require bigger hardware, OV
before BGPsec would seem to be the sequence.

otoh, your last statement is true, an operator will have to set up rpki
data before deploying either origin validation or bgpsec.  rpki is
needed for both.

so i am not sure what you are suggesting i do.

> - intro, 3rd para: where are the "special operational
> considerations" explained? A reference would be good.  If
> there's no good reference, I'm not clear why saying this
> is useful. (Actual operators might find this clear of
> course, in which case, please ignore me.)

how about

This has special operational considerations, see Section 6.

> - section 2: this refers to the BGPsec overview which
> refers back to this document, but says that this is
> informational rather than a BCP. Just noting that in case
> there's confusion and that's not just a typo or a case of
> the overview not having been updated. I expect the fix is
> to change the text in the overview.

i can support that :)

> - section 5: What does "fully BGPSEC enabled" mean
> exactly? That could be referring to signing or to
> validation of signatures (with or without hard fails) or
> to never emitting unsigned or accepting unsigned
> announcements or to some combination of the above.  It
> might be better to avoid use of such a term in order to
> avoid having to define it for now. (This relates also to
> the mail subsequent to Mirja's comments.)

somehow i do not think that adding more words helps, but

   In an AS where edge routers speak BGPsec and therefore inject BGPsec
   paths into the iBGP, Route Reflectors MUST have BGPsec enabled if and
   only if there are eBGP speakers in their client cone, i.e. an RR
   client or the transitive closure of a client's customers' customers'
   customers' etc.

> - section 7: MED could do with expansion and a reference.

how about

... value such as local-preference or multi-exit discriminator
(MED).

> - section 7: I'm not clear what you mean by "RPKI version
> skew." You could explain that or maybe use another basis
> to explain why R0 and R1 might disagree, e.g. revocation
> status info availability or freshness maybe.

sigh.  more words.

   As the mildly stochastic timing of RPKI propagation may cause version
   skew across routers, an AS Path which does not validate at router R0
   might validate at R1.

> - section 8: "forward signed to R" is a bit opaque (for me
> anyway, before I read the protocol draft). Maybe 

Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

[Randy Bush]

> +1 to the comment from Suresh about order. I though that something like
> what he proposed will minimize memcopies and possibly use of memory why
> hashing. So I am also curious to know answer to his question.

a vendor engineer actually implementing requested the change to the
current syntax for ease of generating/parsing.

randy

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

[ side comment best ignored ]

>> otoh, private AS numbers are used in non-confed topologies, e.g. the bgp
>> stub customer who uses a private AS.  they should not sign of course.
>> but once i receive their announcement and strip the private AS,
>> can/should i sign?  i just looked at bgpsec-protocol and found no
>> guidance.
> 
> from that vantage point you are the origin. it's not clear to me that a
> customer  relationship is substantively then if you do this internal to
 ^ different [ i presume ]
> your org. operationally the'yre probably also registering route objects,
> issuing LOAS and operating on behalf of the private ASN.

i buy everything but the LOAs.  issues of legal authority to enter into
contracts et alia.

randy

___
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)

[Randy Bush]

>> 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.

i am easily confused.  can this be said with significantly less words so
i have a chance to actually understand it?

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]

> Agreed. I guess you could in addition be very clear that a router that
> once negotiated (and/or send) BGPsec (attributes) should not be
> expected to always do so.

whoops!  that'll be in -14.  thanks.

randy

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

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

i posted -13 so iesg has fresh

randy

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

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

thanks for the review.

> Update: I noted when reviewing other sidr drafts on this telechat
> agenda that this draft treats 2119 keywords differently than the other
> drafts.  That is, this draft explicitly excludes lower case versions
> of the 2119 keywords

which is, i believe, the current wisdom; see long discussion on ietf
list.

> while the other related drafts do not.

have fun with that. :)

> -1, first paragraph: "It is thought...": Can you mention "who" thinks
> -it?

phrase removed

> -1, third paragraph: Please consider writing out "also known as"

rich got that

> -4, first paragraph: I found "either" followed by "and/or" a bit
> confusing. I suggest simply dropping the word "either".

   As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers
   are either capable of generating their own public/private key-pairs
   and having their certificates signed and published in the RPKI by the
   RPKI CA system, and/or are given public/private key-pairs by the
   operator.

but the router(s) might not be capable of generating key-pairs.  they
might, they might not, the op may generate or not, or both.  an absurd
corner case might be that a router with two ASs has the as0 key stuffed
by the as0 noc, and the as1 key is generated on device because that is
the as1 policy.

> -4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended
> to offer permission, or describe reality? (The latter should not use a
> 2119 keyword.)

sure

> -4, last paragraph: "a prudent operator will..." sounds like it might be
> worthy of a SHOULD.

given the previous, how about lower case should

> -6, first paragraph: "SHOULD/MUST only" constructions tend to be
> ambiguous. In this case, are we saying SHOULD only originated signed
> announcements, as opposed to unsigned announcements? Or as opposed to
> validating received assignments? If the latter, then the "need not
> validate" seems to weaken the SHOULD.

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

> -6, last paragraph: Can something be cited for the 84% assertion?

easier to remove it.  actually, i thought i had done so already; which
causes me to worry if i lost other edits.

> -7, paragraph 6: This seems to say that signed paths MUST be signed. Does
> the "MUST be signed if sent to external BGP speakers" mean that the
> existing signature must not be stripped (as stated more weakly in the
> previous sentence), or does it mean the sender must re-sign the path?

   Because of possible RPKI version skew, an AS Path which does not
   validate at router R0 might validate at R1.  Therefore, signed paths
   that are Not Valid and yet propagated (because they are chosen as
   best path) should have their signatures left intact and MUST be
   signed if sent to external BGPsec speakers.

i am not seeing where bgpsec stripping was suggested; in fact, the
opposite.  if router r0 receives a signed path and intends to pass that
signed path to the next listener, r0 must sign the path.  i am at a loss
to understand your question.  clue bat please.

> -7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid."
> seems like a statement of fact.

are you suggesting to downcase it?  i will assume so.

> -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as
> needed to understand this document. That suggests it should be a
> normative reference. 

ennie meenie.  i think some other reviewer had me push refs around.  i
don't have a dog in this fight.  my personal opinion would be that
overview is informative and the protocol spec itself is normative.

again, thanks.

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.
> 
> I'm currently not using bgpsec (or rpki for that matter).  BUT, if there
> was no path to go back, I would never ever use it.  Destroying my ASN
> because I wasn't ready to migrate is a straight-up No Go(tm).
> 
> Mistakes will be made.  Rolling back will happen.  Preventing rolling
> back will kill the baby and will guarentee this will never be rolled
> out.

what do you mean by "no path to go back" and "rolling back?"

where do you see "destroying" your AS?

my only guess is that
  o you have not read the spec or any documentation on it, and
  o you triggered on the phrase "path stripping"

fwiw, path stripping is removing the bgpsec gorp from a bgpsec path and
rendering a classic bgp4 path to hand to a bgp listener who does not
understand bgpsec.  no ASs are harmed in the process.

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

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)

[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] 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

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

[Randy Bush]

>> 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.

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

___
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)

[Randy Bush]

>> 2. Private ASNs (as pointed out in the SecDir review) are commonly
>> used for stubs.
> This document should include something (I’m thinking in the Ops
> Section) about the protocol considerations: there must be a ROA from
> the resource owner for the ISP to properly re-originate the Update,
> etc..

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

randy

___
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)

[Randy Bush]

> IOW, AS65003 doesn’t necessarily always know that AS65001 is also AS2.
> It may not know the confederation ID at all, or it may even think that
> AS65001 is also some other AS.

and this is within spec.  we have no measure of how common this is, and
it would be hard to measure due to the problem of vantage points.  such
is life with bgp.

randy

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

Re: [sidr] Last Call: (BGPsec Operational Considerations) to Best Current Practice

[Randy Bush]

hi job,

> TEXT:
> 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.
> 
> COMMENT:
> If you are multihomed and receive full (or partial) tables, there is
> benefit in validating the received routes, if not: why not? One
> upstream might be poisoned while the other isn't? Mabye the text
> should be amended to make it clear that this might apply if the stub
> ASN only takes default-originates?

that is why it is SHOULD.  and note it does say "and trusts its
upstream(s)."  going down the rat-hole of trusting upstreams differently
seems an exercise in adding words but not adding value.

note that doing path validation would pretty much mean the end site buys
new hardware.  pointing out that one could avoid that was the purpose of
the paragraph.

if i made any change, it would be a rant about out-sourcing security.
e.g. "Note that this is out-sourcing security, which is generally
unwise.  But the trade-off is likely out-sourcing security or buying
bigger hardware."

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-algs-16: (with COMMENT)

[Randy Bush]

> Just a thought: Would it be useful to add an IESG note saying something
> like in the sheperd write-up:
>  "[...] there are published references
> that preceded the filing of the patent, especially those mentioned
> in RFC6090.  RFC6090 notes that its descriptions "may be useful
> for implementing the fundamental algorithms without using any of
> the specialized methods that were developed in following years.""

perhaps the simple truth would raise less objection; if it does raise
objection then i suspect something is broken.

say that there is an ipr filing on this draft and the wg considered that
and decided to go ahead anyway.  also say that \cite{rfc6090} describes
relevant algorithms and has no ipr filed against it.

randy

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

>> otoh, private AS numbers are used in non-confed topologies, e.g. the bgp
>> stub customer who uses a private AS.  they should not sign of course.
>> but once i receive their announcement and strip the private AS,
>> can/should i sign?  i just looked at bgpsec-protocol and found no
>> guidance.
> 
> from that vantage point you are the origin. it's not clear to me that
> a customer relationship is substantively then if you do this internal
  ^ did you drop "different?"
> to your org. operationally the'yre probably also registering route
> objects, issuing LOAS and operating on behalf of the private ASN.

almost.  while they _may_ be registering route objects, it is unlikely
they are signing contracts on behalf of the customer.  different transit
providers provision customers using private ASs in different ways (doh).

but i think essentially we are in agreement.  as far as bgpsec and
roa-based origin validation go, it would probably be good to specify how
the transit operator proxies for the private AS customer.

but this is the ietf.  i have faith that someone can come up with a
corner case where this should not be done. :)

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-algs-16: (with COMMENT)

[Randy Bush]

> It's the implementors problem to consider IPR issues even without a
> disclosure.

and ours not to lead them into ipr with no warning.

randy

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

Re: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-bgpsec-algs-16: (with COMMENT)

[Randy Bush]

> BGPsec uses a different algorithm as compared to the rest of the RPKI
> to minimize the size of the protocol exchanged between routers
> [RFC5480].

to reduce the size of signed bgpsec updates on the wire.

i still wonder why we are not doing 25519 considering it is the cfrg
recco and all the kool kids have gone that path.

randy

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

> Yes, there should be something about private ASNs in the protocol spec.
> 
> It would be nice to also see some operational guidance in this document.
> 
> Alvaro.
> 
> otoh, private AS numbers are used in non-confed topologies, e.g. the bgp
> stub customer who uses a private AS.  they should not sign of course.
> but once i receive their announcement and strip the private AS,
> can/should i sign?  i just looked at bgpsec-protocol and found no
> guidance.

first the protocol spec needs to make clear if the real AS can proxy
sign for a connected private AS.  then i can hack the ops doc.

seems to me that, as the real AS is required to strip the private AS
from the path, the real AS should be able to proxy sign.  but then
who has the cert to create the roa, etc.?

randy

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

otoh, private AS numbers are used in non-confed topologies, e.g. the bgp
stub customer who uses a private AS.  they should not sign of course.
but once i receive their announcement and strip the private AS,
can/should i sign?  i just looked at bgpsec-protocol and found no
guidance.

randy

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

> M4. Still in Section 7: “To prevent exposure of the internals of BGP
> Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a
> Confederation MUST NOT sign updates sent to another Member-AS of the
> same Confederation.”  This is another case where the BGPSec spec says
> something different: Section 4.3. (Processing Instructions for
> Confederation Members) presents a mandatory mechanism that includes
> signing, but not necessarily validating.  BTW, if the updates are not
> signed, then the signed path would be broken, even if all the routers
> in the path support BGPSec, right?  Is that the recommendation?
> 
> it is common for a bgp confederation to include private ASs for which
> there can be no unique authorative router credentials in the rpki.
> hence i am suspicious of the protocol spec.

i recant.  the protocol spec 4.3 says the intra-confed path elements are
stripped before exporting outside the confed.

   To prevent exposure of the internals of BGP Confederations [RFC5065],
   a BGPsec speaker exporting to a non-member removes all intra-
   confederation Secure_Path segments.  Therefore signing within the
   confederation will not cause external confusion even if non-unique
   private ASs are used.

randy

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

alvaro,

> In thinking about this point some more…what about
> draft-ietf-sidr-slurm?  Isn’t that supposed to address the private
> space?
> 
> M4. Still in Section 7: “To prevent exposure of the internals of BGP
> Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a
> Confederation MUST NOT sign updates sent to another Member-AS of the
> same Confederation.”  This is another case where the BGPSec spec says
> something different: Section 4.3. (Processing Instructions for
> Confederation Members) presents a mandatory mechanism that includes
> signing, but not necessarily validating.  BTW, if the updates are not
> signed, then the signed path would be broken, even if all the routers
> in the path support BGPSec, right?  Is that the recommendation?
> 
> it is common for a bgp confederation to include private ASs for which
> there can be no unique authorative router credentials in the rpki.
> hence i am suspicious of the protocol spec.

if a private-as router in confederation C signs from that as, others in
the confed C may (or may not) have the slurmy data.  but assuredly, when
that route finally makes its way out to the global internet, there will
be a signature in the path which no one can validate.

randy

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

unless someone screams

   As BGPsec will be rolled out over years and does not allow for
   intermediate non-signing edge routers, coverage will be spotty for a
   long time.  This presents a dilemma; should a router evaluating an
   inbound BGPsec_Path as Not Valid be very strict and discard it?  On
   the other hand, it might be the only path to that prefix, and a very
   low local-preference would cause it to be used and propagated only if
   there was no alternative.  Either choice is reasonable, but we
   recommend dropping because of the next point.

   Operators should be aware that accepting Not Valid announcements, no
   matter the local preference, will often be the equivalent of treating
   them as fully Valid.  Local preference affects only routes to the
   same set of destinations.  Consider having a Valid announcement from
   neighbor V for prefix 10.0.0.0/16 and an Not Valid announcement for
   10.0.666.0/24 from neighbor I.  If local policy on the router is not
   configured to discard the Not Valid announcement from I, then longest
   match forwarding will send packets to neighbor I no matter the value
   of local preference.

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

> “naggumite” – it took me a while to figure this out… ;-)

one of the times jon postel and i disagreed.  imiho being liberal in
what you except is the road to entropic death.

> My biggest problem with the original text is the normative “SHOULD
> NOT”, so changing that to “might not” works for me as you’re
> describing a fact of what may happen in the initial deployments…
> 
> I am also happy to take the blame for dropping invalid stuff. ;-)

this is the bit i wanna tweak when i get off the phone with untied

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

sig.  wrong docco.  will push this one.

randy

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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

[Randy Bush]

i realized you wanna ietf last call it.  will push a rev in a few hours.

randy

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

I'll wait to push when until have heard from the protocol editors. 

randy

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

Re: [sidr] Current document status && directionz

[Randy Bush]

 draft-ietf-sidr-rtr-keying
>> i thought this was done
> this one maybe done, but has not hit WGLC. we can do that here, or
> there...  I'm agnostic at this point.

this is protocol, not ops

randy

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

Re: [sidr] Current document status && directionz

[Randy Bush]

>> draft-ietf-sidr-bgpsec-ops

waiting to rev when iesg and whomever reviews are in.  if someone wants
an earlier push, shout.

>> draft-ietf-sidr-lta-use-cases

i thought this was post last call

>> draft-ietf-sidr-rtr-keying

i thought this was done

randy

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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

[Randy Bush]

> ideally you also backstop that with some protections (tcp-ao, of
> course!)

and cash will fall from the sky

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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

[Randy Bush]

> I guess I will wait for Alvaro to answer, but so far I'm not seeing
> the need for anything more than a couple lines that remind the reader
> of the basic (in)security properties of BGP, maybe an RFC 4272
> reference.

section 4.5 of 4593 is relevant, or all of sec 4
i am kinda sad that 7132 is not too good on this

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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

[Randy Bush]

>>> and stitching back together the tcp session... same effect.
>> 
>> Not sure why you have to stitch back together the TCP session? I
>> thought you were supposing the "attacker" was the edge node, it can
>> just apply an export policy towards the core.
> 
> say the case is inside your network, between the edge node in NYC and
> the core nodes in BWI, something on the fiber path just removes/adds
> information to the bgp stream.

< pedantry >

the point is the tcp 'stream' does not have to be hacked in any way.
the hack is at a layer above.

randy

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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

[Randy Bush]

> > C2. [Major] Security Considerations.  I think that there is one 
> > consideration that should be mentioned in this section:  Given that the 
> > largest value is preferred (2 = invalid), there is an attack vector where a 
> > router in the path (yes, even an internal router) can inject a community 
> > indicating that the route is invalid; the communities are not protected.  
> > This action could result in inconsistent routing or in even a DoS.  I know 
> > the document is not explicit about what to do with the validation state 
> > (which is ok), but the clear intention (from rfc6811 and rfc7115) is that 
> > it will be used to make routing decisions.  Please add some text about this 
> > potential issue.
> 
> I started to write something about this and then realized I don't understand 
> what you mean. At first I thought you were saying that an attacker that can 
> forge an OV community can bias route selection. While this is true of course, 
> it's also not unique to OV (Localpref has this property for example). It 
> probably wouldn't be hard to write a sentence to summarize this, if 
> necessary. 
> 
> However, you specifically refer to the invalid state: "a router in the path 
> ... can inject a community indicating that the route is invalid". This makes 
> me think you think there's something special about "invalid", and I don't 
> know what it is. You also say something about the sorting order, which I'm 
> also not sure why that would matter.
> 
> As far as I can tell, injecting "a community indicating that the route is 
> invalid" is kind of boring attack -- it just makes the route less likely to 
> be selected by the downstream router. The "bad" router could also just fail 
> to propagate the route at all ("underclaiming") making it flat-out impossible 
> for the downstream to select it, or could use any number of other path 
> attribute manipulations (Localpref, AS path, etc) to make the route less 
> preferable. Are you suggesting there is some fancier attack than this, or are 
> you just asking us to acknowledge BGP doesn't work very well in the face of 
> an on-path attacker?
> 
> By all means, if anyone has text to send, do.

you have out-sourced your security.  the party to which you have out-
sourced it can send you anything.  get over it.

as the OV signaling is vanilla bgp, there is no integrity enforcement,
not even a useless checksum; any monkey in the middle can fake anything.
get over it.

none of this is new.  you'll really love the wonderful new blackhole
community.

randy

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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

[Randy Bush]

> C1. The reference to rfc7607 should be Informative.
> 
> C2. [Major] Security Considerations.  I think that there is one
> consideration that should be mentioned in this section: Given that the
> largest value is preferred (2 = invalid), there is an attack vector
> where a router in the path (yes, even an internal router) can inject a
> community indicating that the route is invalid; the communities are
> not protected.  This action could result in inconsistent routing or in
> even a DoS.  I know the document is not explicit about what to do with
> the validation state (which is ok), but the clear intention (from
> rfc6811 and rfc7115) is that it will be used to make routing
> decisions.  Please add some text about this potential issue.

would you prefer a revision soon, or wait for other iesg comments?

randhy

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

alvaro,

thanks for the best review this has had in a while.  i am not ignoring
you; and may even get a version out for next week.  but no promises, as
i suspect you folk will think that having a solid ietf network next week
is more important :)

randy

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

Re: [sidr] Agenda Upload

[Randy Bush]

i stil think we should be doing some rigorous interoperability testing,
inter CA, caches and routers, routers applying origin validation, ...

yes, we should be doing this in sidrops, but we all know that it will be
populated by the usual suspects, barring voter suppression.  so it would
be nice to discuss this next week, irresptive of the air cover and hats.

randy, already in seoul noc

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

Re: [sidr] Current document status && directionz

[Randy Bush]

> yes, the chairs posed the question: "Err, did we sink your battleship
> with too many docks?" to alvaro, he's still using his snorkel to swim
> out of the trench... he'll get there he says :)

it would seem desirable to get them through the iesg before closing sidr
and transitioning to sidrops.

randy

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

Re: [sidr] Current document status && directionz

[Randy Bush]

> Currently we have the following in IESG/pub-request status (13 documents):
> draft-ietf-sidr-adverse-actions
> draft-ietf-sidr-as-migration
> draft-ietf-sidr-bgpsec-algs
> draft-ietf-sidr-bgpsec-ops
> draft-ietf-sidr-bgpsec-overview
> draft-ietf-sidr-bgpsec-pki-profiles
> draft-ietf-sidr-bgpsec-protocol
> draft-ietf-sidr-origin-validation-signaling
> draft-ietf-sidr-publication
> draft-ietf-sidr-rpki-oob-setup
> draft-ietf-sidr-rpki-rtr-rfc6810-bis
> draft-ietf-sidr-delta-protocol (10/26 sent forward)
> draft-ietf-sidr-rpki-validation-reconsidered (10/26 sent forward)

an interesting view on progress of these documents is visible in
https://datatracker.ietf.org/doc/ad/alvaro.retana/

randy

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

Re: [sidr] WGLC - draft-ietf-sidr-delta-protocol - 10/25/2016

[Randy Bush]

i believe i already responded, but just in case.

have read, have used, no ill affects detected.  ship it.

randy

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

Re: [sidr] adverse actions -01 posted

[Randy Bush]

> The term “adverse" doesn’t means “hostile" necessarily.

oh bs.  it is the first definition in most dictionaries.

change the word.  get over it.

randy

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

Re: [sidr] Current document status && directionz

[Randy Bush]

> going forward though, what's the path? "get rir and iana/icann to
> agree that this is important, set a schedule for deployment, profit?"
  ^deploy,

> ok, so we're back to: "I hear what you are saying, we (community)
> really need 'single root' please go make that happen."

yeppers

randy

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

Re: [sidr] Current document status && directionz

[Randy Bush]

> ICANN, as the IANA Internet Numbering Functions Operator, did come
> forward and we were informed there was no interest from the RIRs for
> the IANA Internet Numbering Functions Operator to participate in
> testing a single root RPKI service.

this matches my memory.  i am told the rirs even sent a letter to the
iana saying, in pore politic terms, foad.

> I suspect if the Internet Numbering Community would be interested in a
> single root operated by the IANA Internet Numbering Functions
> Operator, all they need do is _ask_.

i hereby ask

randy

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

Re: [sidr] Current document status && directionz

[Randy Bush]

> Or maybe there's pushback that says: "Hey, I hear what you all in the
> rir want, but it's not cool, please please let's dive back into the
> politics stream and see how we get movement on what we all (probably?)
> want: a single root for this system."

the iab did that and got a written agreement that the rirs would do so.
nothing more is needed other than action.

randy

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

Re: [sidr] Current document status && directionz

[Randy Bush]

> (note, I do not care for this message about politics)
> 
> we're here because, I think, from the top down to the RIR there isn't a
> hierarchy being created, right? the RIR folk are saying: "Ok, you all want
> this thing, but upstairs hasn't created the root, so we're going to do the
> best we can with making a root each that allows us to xfer between RIRs.
> This is how it's being done, so you have some docs about the mechanics
> involved and can build/guide from there"
> 
> is that not the case? (again, I don't care about the politics)

dear ostrich,  the problem is it is all about politics.  and politics is
what happens when two or more funny monkeys are involved.

despite many years of promises promises of a single root

  o the rirs have been at war with the iana this whole time.  i neither
know nor care whose fault it is.  but their egos and lawyers are
preventing an iana root.

  o the rirs have the nro, which could be a single root.  they seem to
lack the fortitude and/or spirit of cooperation to root at the nro.

this was not how it was being done a year ago.  now the warring parties
are each declaring themselves god.  this is not an improvement, in fact
the opposite.  if we accept this draft, as rob says, it should be
labeled as highly toxic.

randy

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

Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016

[Randy Bush]

have read.  have used.  wfm.

randy

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

Re: [sidr] two stranded docuemnts - stake time

[Randy Bush]

you may, or may not, notice that the current i-d does not mention
ripe/ncc

randy

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

Re: [sidr] adverse actions -01 posted

[Randy Bush]

>>> Tim offered no suggestion for a different term, which is not helpful.
>> the suggestion was "unwanted".
> I reread Tim's message; I don't interpret it as having suggested 
> "unwanted" as an alternative.

that is clear.  others, such as matthias and i, did.  but this is not
productive.

to be clear, i hereby suggest s/adverse/unwanted/

randy

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

Re: [sidr] adverse actions -01 posted

[Randy Bush]

>> To me the word "adverse" communicates an unfavourable, possibly even
>> malicious, action by an adversary.
> 
> The term adverse is appropriate as used in this document. When I look
> up the term I find the following primary definitions:
> 
>  unfavorable or antagonistic in purpose or effect, opposed to
> one's interests, causing harm, etc.
> 
> Synonyms include inimical and injurious.
> 
> These meanings are precisely what is intended here.

and what tim, and others, are trying to say is that exactly those
meanings are inappropriate.  we do not really know intent, contracts,
and business/social context.

i picked the first example of an 'adverse action' in your document and
explained how it can be normal operations (and it is said you have fixed
it, tyvm).  i had hopes you would induce.

operations and deployment are messy.  apologies.

tim made a fair suggeston of a lighter word.

randy

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

Re: [sidr] two stranded docuemnts - stake time

[Randy Bush]

>   1) use-cases - decide on tweaks & rev-document: Aug 1
>  review and WGLC  Aug 14
>  send to IESG Sept 1

do we have a concise issue list (other than steve not liking the style
used)?  not sure i will make the 1 aug dreadline if i have to sift
through the mailing list, whine, whine, whine.

randy

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

Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00

[Randy Bush]

> I don’t see that there’s a requirement that a router have only one
> certificate, either.  A router that was configured to speak as two
> different ASs might have one key certified by both ASs and might have
> two different keys, one for each AS.

that this is designed in is not an accident.  we had this discussion,
just as we had the multi-roa discussion; but they are ops complexity, so
easly ignored/forgotten.

randy

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

Re: [sidr] wglc for draft-ietf-sidr-rpki-oob-setup-04

[Randy Bush]

> The authors believe that draft-ietf-sidr-rpki-oob-setup-04 ("An
> Out-Of-Band Setup Protocol For RPKI Production Services”) is mature
> and ready for a working group last call.

i read it
i use it
ship it

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

Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00

[Randy Bush]

> I'll revise that text to note the case of a resource transfer appears to 
> be competition

it is more than transfer.  it is the very frequent operation of changing
tranist providers.  i own P, but do not use bgp.  my parent T0 announces
it for me (roa P-T0).  i change upstream providers to T1.  during the
move there are two roas, the second being P-T1.

this all was very intentionally designed for make before break.
multiple roas with different ASs for the same prefix are normal.  i
found it shocking and disappointing to have the introduction say
otherwise.

randy

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

Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00

[Randy Bush]

the introduction starts by labeling the basic make before break of a
provider switch, a perfectly normal operation, as an adverse action.

randy

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

Re: [sidr] come on people Re: The question about https certificates and frequency of mft/crl re-issuance

[Randy Bush]

> Look, if no one can summon the energy to respond, Tim has no way to
> decide on a change.

i believe that rob laid this out clearly many months ago.  and no, i
will not look it up for folk; the epicycles have become too painful.

randy

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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Randy Bush]

>   I read v09. No objections only minor comments:

i hacked in many of these changes, though i think most did not really
change anything other than an alternate way of saying the same thing.
but i just do not want to see this go on an on interminably.  and at
least you reviewed it.  thanks!

randy

> 
> line 102: BGPsec need*s* *to* be spoken only
> 
> line 104: s/by small edge routers/by resource constrained edge routers/
> 
> line 119: *see* [RFC4271]
> 
> line 159: s//etc./
> 
> lines 200-206 seem redudant to lines 208-213
> 
> line 202 s/smallish/resource constrained/
> 
> line 215: I don't know where the 84% comes from, I suppose it's just a 
> more or less arbitrary illustration of "vast majority". I would remove 
> the number.
> 
> line 234: I would be more explicit: "How this is used in routing is up 
> to the operator's local policy, similar to origin validation [RFC6811]."
> 
> lines 243-250: This paragraph confused me. What about:
> 
> Operators should be aware that controlling Invalid announcements by 
> local preference might be delusive. Local preference affects only routes 
> to the same set of destinations. Consider having a Valid announcement 
> from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for 
> 10.0.66.0/24 from neighbor I. If the local policy on a router is 
> configured to accept Invalid announcements, then both routes will be 
> installed, no matter of the value of local preference.
> 
> (Btw, I suppose that routes to .666 will be discarded anyway ;)
> 
> line 252: It sounds that only edge routers are allowed to speak BGPsec. 
> I would weaken and say "Validation of signed paths is usually deployed 
> at the eBGP edge."
> 
> line 292: s/BGPSEC_Path/BGPsec_Path/
> 
> lines 288-295:  The paragraph seems to mix transparent operation and the 
> question of validation. What about:
> 
> A route server is usually 'transparent'. To operate transparently in an 
> environment in which the route server connects BGPsec-enabled peers, the 
> route server needs to run BGPsec as well. This implies that the route 
> server creates signatures per client including its own AS in the 
> BGPsec_Path and the target ASes. However, increasing the AS hop count 
> reduces the likelihood of best path selection. See 2.2.2 of 
> [I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route 
> server uses pCount of zero to not increase the effective AS hop count.
> 
> Furthermore, a BGPsec-aware route server needs to validate the incoming 
> BGPsec_Path but should not drop invalids. In case the client speaks 
> BGPsec the route server should just forward updates to clients which 
> then validate . In case the client does not speak BGPsec, the route 
> server reconstructs the AS_PATH and may signal the validation outcome 
> using communities.
> 
> line 300: s/Routers should default to this knob disallowing pCount 0./Routers 
> should disallow pCount 0 by default./
> 
> line 346: I would rephrase: "Operators should deploy servers that 
> provide time service, such as [RFC5905], to client routers."

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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Randy Bush]

matthias,

> one more: Can you please replace "Invalid" by "Not Valid", because 
> this is the notation defined in draft-ietf-sidr-bgpsec-protocol-17.

done.

randy

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

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-09.txt

[Randy Bush]

aris's fixes.

nest person to find bugs pays the publication fees :)

randy

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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Randy Bush]

> Line 94: There’s a typo: “twp” instead of “two”
> Line 202: Grammatical error: “it’s” instead of “its”
> Line 317: Typo: “see see” instead of “see”



>>  BGPsec protocol capability negotiation provides for a speaker signing
>>the data it sends without being able to accept signed data.  Thus a
>>smallish edge router may hold only its own signing key(s), sign it's
>>announcements, but not receive signed announcements and therefore not
>>need to deal with the majority of the RPKI.  Thus such routers CPU,
>>RAM, and crypto needs are trivial and additional hardware should not
>>be needed.
> 
> “Operators might be utilising hardware with limited resources. In such
> cases, BGPsec protocol capability negotiation allows for a resource
> constrained edge router to just hold 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."

eenie meenie.  but if it makes you happy, i'll use yours.

randy

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

Re: [sidr] Last Call: (Securing RPSL Objects with RPKI Signatures) to Proposed Standard

[Randy Bush]

> But regardless of process. For this to be useful for route objects we
> need two signatures in cases where the AS and prefix are held by
> different parties.

then we have misplaced this whole discussion.  it is really about using
rpki keys to sign rpsl data willy-nilly, as opposed to using the rpki
infrastructure.

the rpki-based origin validation and bgpsec models specifically do not
authenticate the authority of an AS.  the AS does that by announcing.

i happen to be in the building having post lunch coffee.  wanna chat
face to face?  bring clue bat.

randy

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

Re: [sidr] Last Call: (Securing RPSL Objects with RPKI Signatures) to Proposed Standard

[Randy Bush]

>>> I agree that the original text allowing multiple signatures supports
>>> the case where the components of the primary key of the object (i.e.,
>>> prefix+ASN) come from different resource holders. I will restore that
>>> text.
>> 
>> this is gonna be really simple; no complications at all i am sure.
>> 
>> btw, was this a consensus of the wg?
> 
> The original draft supported multiple signature attributes. During WG
> review (WGLC?, don't recall), several people suggested simplifying the
> approach by only allowing one signature attribute. Given the route[6]
> example, we need multiple signatures modulo the proposed text to clarify
> the handling/generation of those signatures.

i.e. it was not wg consensus but you think you should do it anyway?

randy

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

Re: [sidr] Last Call: (Securing RPSL Objects with RPKI Signatures) to Proposed Standard

[Randy Bush]

> I would propose adding some text to this draft (probably as a
> sub-section in section 2) that says that the SIA defined in RFC 6487 is
> omitted when a certificate is used to sign RPSL objects.

perhaps you might also include your reasoning for this seemingly odd
choice.

> I agree that the original text allowing multiple signatures supports
> the case where the components of the primary key of the object (i.e.,
> prefix+ASN) come from different resource holders. I will restore that
> text.

this is gonna be really simple; no complications at all i am sure.

btw, was this a consensus of the wg?

randy

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

Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01

[Randy Bush]

>> this glibly glosses over that, by outsourcing origin validation, an
>> attack vector is introduced.  i presume i do not need to describe it.
>> so it needs to be big in the sec cons.
> Is it bigger than the attack vector allowed for when not doing origin 
> validation at all?

now we're comparing the size of the guns used to shoot yourself in the
foot?

my point was that it needs to go in the sec cons.  not the size of the
type to be used.

randy

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

Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01

[Randy Bush]

> Some people do use route servers, and won't do their own validation -
> I'd rather that they have the information available to make a decision
> than not...

this glibly glosses over that, by outsourcing origin validation, an
attack vector is introduced.  i presume i do not need to describe it.
so it needs to be big in the sec cons.

randy

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

Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01

[Randy Bush]

>> mostly because I don't see a clear method to ensure that 'third party' has:
>>   1) up-to-date information
>   Same with RTR cache server.

i would not load routers from rpki caches i do not own and control

>>   2) my best interest at heart
>   If you peer with a route server, you should establish a trust relation 
> anyway.

in my heart i agree with chris, a prudent operator does not outsource
security.

otoh, i also do not think a prudent operator outsources bgp, i.e. uses a
route server.

putting the two together, if you are willing to outsource bgp to a route
server, then outsourcing bgp security to the route server is not much of
a leap.

chris, think of it as shooting yourself in the foot with a two-barrelled
gun instead of one with one barrel.  :)

randy

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

Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01

[Randy Bush]

> Please respond on the list to say whether you support adoption of this
> work as a working group work item

yes

> AND whether you will participate in the discussion.

i see no need to answer

randy

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

Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt

[Randy Bush]

> I would like to come back to a solution that was discussed already: If
> the route-server is not able to perform the origin prefix validation
> the BGP community is not added to the BGP update. The BGP community is
> only added if the origin prefix validation could be executed.
> 
> This solution allows a clear signalling. This would also be compatible
> with the current ietf-sidr-origin-validation-signaling document and
> could be easily stated in draft-kklf-sidr-route-server-rpki-light.

you're welcome

randy

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