>Hi! I think the only item left is the Confederations one…and we might be
>speaking past each other.
Thanks, Alvaro. My comments are marked with [Sriram-3].
[Sriram-3] I understand now your main comment about confederation. I think
there are two ways to address it (of course I hope other people chime in as
well):
Choice A: The pCount = 0 solution that you have suggested.
But I feel that this is somewhat a cosmetic solution. In your example, it can
be perhaps questioned whether the signature with pCount = 0 from AS2 to AS65001
does actually fit the security guarantee from Section 8.1 that you’ve cited.
Because AS2 (the AS with the public ASN) did not produce that signature
directly. Instead AS65001 played proxy for AS2 -- which is of course part of
the original solution anyway. So we may consider choice B below.
Choice B: Include a caveat to the statement in Section 8.1. For instance, we
modify it as follows:
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 (except for a minor caveat that applies in the case of BGPsec
speakers
in a confederation). The caveat applies because a BGPsec speaker
in a confederation-member AS can be a proxy receiver and signer for the
public AS
(identified by the public AS number of the confederation). Therefore, a
signature that appears to
correspond to an AS with the public AS number may actually
be proxy produced by a member AS that has an internal AS number
not matching the public AS number. The confederation-member ASes
are cognizant of this and hence it poses no security concern
within the confederation, and it is transparent to ASes outside
the confederation (see Section 4.3).
[Sriram-3] Do you feel Choice B makes sense?
[Sriram-3] Please see inline below for the rest of my comments (all marked with
[Sriram-3]).
>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.
[Sriram-3] Please see solution choices and A and B above and the related
discussion.
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.
[Sriram-3] OK, will include draft-ietf-sidr-slurm as 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..
[Sriram-3] Agree. I’ll factor in your inputs and those from Joel, Russ, and
Randy to include a paragraph on this topic in the ops and mgmt. section.
[Sriram-3] Perhaps I should wait for some more IESG LC reviews to roll in
before I include this set of changes and those from Russ (Gen-ART)
and Nevil (OPS-DIR)? Please advise.
Thank you.
Sriram
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
