At 11:35 PM -0400 3/19/12, Sriram, Kotikalapudi wrote:
>The model I have long (>30 years) employed is that if the secruity
checks succeed,
the protocol should operate as before (i.e., w/o the added secruity
mechanisms),
because the environment is seen as benign.
---snip---
I'd like to think that the BGPSEC mechanisms are being developed in
a way that tries to adhere to this paradigm.
Steve,
In light of the your above observations, how do you reflect on the
pCount field in BGPSEC?
It is not part of the current BGP-4.
In BGPSEC, pCount = 0 is used to denote a transparent IXP AS, and
the transparent IXP AS number is included in the BGPSEC update
(whereas BGP-4 practice was not to include it in the update).
And the sum of pCounts for all ASs must now be used to determine the
AS path length.
Also, in the latest bgpsec-protocol document, we have eliminated the
AS_PATH attribute.
There are only the NLRI and Signature-Segment fields.
The ASNs and the pCounts need to be pulled from the various Signature-Segments
in order to construct the AS path.
Would you or would you not characterize all this as a change in how
the protocol operates
(when the security checks have succeeded)?
Sriram
Sriram,
That's a fair, but slightly complicated question.
The current BGPSEC protocol design replaces the AS_PATH info with its
own data structure. I don't see this syntactic difference as
necessarily changing the semantics or features of the protocol. But,
one needs to examine the data elements in the BGPSEC structure to see
whether they constitute such changes.
pCount is a data element used to do two things. It provides a
shorthand way for an AS to indicate that its ASN should be counted
multiple times when computing path length. This replicates the
capability that BGP already offers, through repeated insertion of
one's own ASN, so it does not change the features/semantics of BGP.
The ability to set pCount to "0" for one's own ASN does diverge from
the repeated ASN capability that BGP already embodied. The intended
use of this convention is to accommodate transparent route servers at
IXPs. The goal is to enable BGPSEC to operate in a fashion that does
not penalize ISPs operating at IXPs with such route servers. The
mechanism preserves a feature of how BGP is used today. I argue that
this is not a new feature, just a way to preserve an existing
operational capability that has been deemed important and that is not
viewed as a security problem per se. However, allowing a pCount value
of "0" creates a potential problem relative to the BGP path security
features that BGPSEC strives to secure, if it is used in other
contexts. That's an unfortunate side-effect of this mechanism, and
the WG will need to decide whether the possible security problems are
acceptable as a cost of accommodating transparent route servers. Part
of the analysis will need to take into account suggested
countermeasures for dealing with the potential vulnerabilities
associated with pCount=0.
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
