[Changed the Subject to specifically discuss Confederation support, and
hopefully get some attention from the WG.]
Sriram:
Hi! I think the only item left is the Confederations one…and we might be
speaking past each other.
Yes, I agree that the collusion problem is one that (as you mentioned below) is
out of the scope of BGPsec. You are right that pCount=0 (as proposed below)
doesn’t solve the collusion problem – but it does address the following
security guarantee that is currently not met in the Confederations case (from
8.1):
o For each AS in the path, a BGPsec speaker authorized by the holder
of the AS number intentionally chose (in accordance with local
policy) to propagate the route advertisement to the subsequent AS
in the path.
In the case of Confederations, it cannot be (currently) verified that all the
ASNs in the path intentionally chose to send the update to the next ASN because
there is a discontinuity at the border. For a topology like this: AS1 ->
AS2/AS65001 -> AS65002/AS2 -> AS3 (AS2 is the Confederation ID and AS65001 and
AS65002 are Members), it can be verified that AS1 intentionally sent the Update
to AS2, but there is no explicit indication (even if symbolic: pCount=0) of the
intention for AS65001 to “receive” the update, and then be able to send it to
AS65002.
I still think that this continuity issue should be addressed; it nothing more
just because the intentionality is mentioned as a security guarantee of BGPsec.
Chairs: Please poll the WG or make a decision of whether there is consensus (or
not) to not solve this continuity issue (maybe from prior discussions on the
list). If the WG decides not to solve this issue (or if it was already
discussed), I’m ok with being in the rough.
Related to the above, is the support for private ASNs --- this topic also came
up in the review of draft-ietf-sidr-bgpsec-ops, and the GenArt/SecDir reviews.
There are two related points:
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. Given that the signing of
Updates is mandated, I think that support of draft-ietf-sidr-slurm is
necessary; IOW, I think that draft-ietf-sidr-slurm should be a Normative
reference.
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..
Thanks!
Alvaro.
On 12/5/16, 1:35 PM, "Sriram, Kotikalapudi (Fed)"
<kotikalapudi.sri...@nist.gov<mailto:kotikalapudi.sri...@nist.gov>> wrote:
Personally, I would have preferred if you actually solved the problem. One
solution is to borrow from draft-ietf-sidr-as-migration and forward sign from
the Confederation AS (the public number) to the Member-AS with pCount=0. Note
that this operation would take place inside the border Confederation router, so
there are no issues with pCount=0 and the full path continuity is preserved.[*]
Chairs: I think that this part (whether it is solved or not) should also be
bounced by the WG.…
[Sriram-2] Please see discussion at the top of this email. I am afraid, the
solution you propose will not work. The first AS in the Confederation can still
tunnel the update to the second AS it is colluding with, and the second AS
“forward signs from the Confederation AS (the public number) to the Member-AS
with pCount=0”. So the problem you originally identified doesn’t go away.
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
