Brian,
...
That is not correct, i.e. you misunderstand.
The desired outcome is that sender/receiver _negotiate_ what is or
is not to be sent,
and the protocol merely enforces what has been agreed upon. The
automatic enforcement
of this high-level policy, is what stops route leaks from being
initiated or propagated.
The policy is still determined by the operators at both ends of a
peering session.
Just like the IP addresses and ASNs, the policies have to match for
BGP session establishment.
Unilateral misconfiguration (whether by accident or deliberate act),
which could have introduced
or propagated route leaks, are prevented.
Pairwise enforcement may be useful, in general, but the bigger issue
seems to be whether ASes farther along a path see the propagation as
a violation of the pairwise agreement. So, it might be useful to view
this in two parts:
- adding a new feature to BGP that allows explicit
negotiation of route marking to support detection of route leaks on a
pairwise basis
- adding a mechanism to enable ASes father along a path to detect when
a route has been propagated in a fashion contrary to the pairwise agreement
But, that work is appropriate relative to a later version of the
charter (if I may skip ahead to what appears to be your major
concern, cited below).
...
Pot_ay_to, pot_ah_to.
It should fall to the _WG_ to determine whether BGPSEC _is_,
and/or _should_, be treated as a new feature.
I do not believe the charter explicitly forces
the WG onto one side of the line in the sand (feature/not-feature).
The SIDR charter talks about "security enhancement for inter-domain
routing protocols" which, IMHO, supports the not new features, just
securing extant features, perspective.
And, I believe fundamentally, it _needs_ to be a new feature (set)
on BGP, with all that goes along with it. There seems to be a strong
reluctance among a subset of folks, to say this is a new feature set.
This reluctance is appearing to fracture the WG into an us/them
dichotomy, which is antithetical to the IETF philosophy.
At this stage it seems that at most a subset of folks believe these need
to be a set of new features, so whose responsible for the "fracture?"
Also, I'm curious; what part of the IETF philosophy do you cite as
being violated when not everyone in a WG sees eye-to-eye on the scope
of the WG?
As a WG co-chair I see this problem arise periodically.
This WG has a reasonably well-specified charter, which was updated
after the first charter (which was very narrow) was satisfied. Your
argument seems to be that you don't like the scope of the charter.
If BGPSEC were not a new feature, there would not be any need
to add the BGP options negotiation between peers doing BGPSEC.
That's one way to look at it. But, in my response to Eric I explained why
one might not view these as new features per se, but rather as just
security mechanisms added to the protocol to secure the semantics of
the existing feature set in hostile environments.
And, if we acknowledge that it is a new feature, it then is incumbent
on the WG members and chairs, to listen to all the WG participants,
regarding what the requirements are in reaching the charter's goals,
whether they are explicitly in the charter, or implicit consequences
of what is necessary and sufficient in reaching those goals. This
would potentially include other attributes being added, other data
being cryptographically protected, and/or other negotiated peering
parameters.
The WG charter defines what we're doing now. It specifies the two
vulnerabilities that we are to address, and it specifies some
parameters re what tools we are to use in addressing these
vulnerabilities.
So, for example, if "other data being cryptographically protected" is
not directly related to the two vulnerabilities cited in the
charter, then it's out of scope for now.
Discussing whether the security mechanisms being discussed constitute
new features for BGP is not relevant to the charter scope.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
