On 3/11/2013 3:31 PM, Stephen Kent wrote:
Residual Vulnerabilities section. I suggest the following updated text
for that section, to better explain the criteria for inclusion and
exclusion in that document:
snip
-bgpsec-threats-05 has been updated with the revised paragraph.
Editorial
Danny,
On 2013-03-11 13:31, Stephen Kent wrote:
Danny,
We have been told by several operators that the values stated in
Section 4.3 of RFC 4271 are not what is used today. We also have been
told that, contrary to the SHOULD NOT in Section 5.1.1 of this RFC,
it is not uncommon for ASes to
On 2013-03-12 07:07, Stephen Kent wrote:
As far as I'm concerned, we're going to follow IETF procedures.
That charter was intentionally worded when it was written so that the
solution envisaged would be the only thing worked on here, absent being
information by any actual threats or
A quick clarification: The current BGPSEC protocol specification can easily
be modified to protect the ORIGIN attribute. (That is, prevent it from
being modified by intermediate ASes.)
I can very quickly put out an update to the BGPSEC protocol specification
if the working group decides that
On Tue, Mar 12, 2013 at 9:38 AM, Matthew Lepinski
mlepinski.i...@gmail.com wrote:
A quick clarification: The current BGPSEC protocol specification can easily
be modified to protect the ORIGIN attribute. (That is, prevent it from being
modified by intermediate ASes.)
I can very quickly put out
A quick clarification: The current BGPSEC protocol specification can
easily be modified to protect the ORIGIN attribute. (That is, prevent
it from being modified by intermediate ASes.)
ops with deep clue and who i respct have spoken. don't do it.
randy
On 12/03/13 10:21 -0400, Christopher Morrow wrote:
On Tue, Mar 12, 2013 at 9:38 AM, Matthew Lepinski
mlepinski.i...@gmail.com wrote:
A quick clarification: The current BGPSEC protocol specification can easily
be modified to protect the ORIGIN attribute. (That is, prevent it from being
Danny,
We have been told by several operators that the values stated in Section
4.3 of RFC 4271 are not what is used today. We also have been told that,
contrary to the SHOULD NOT in Section 5.1.1 of this RFC, it is not
uncommon for ASes to change this value, en route. Given these two
heas,
Whether anyone likes it, it has become a TE knob of sorts, in a protocol
with few such knobs, and many smaller transit providers rely upon it to
affect route selection for non-malicious reasons, such as to balance their
own transit links. Without providing an alternative, it will be
Mon, Mar 11, 2013 at 03:45:17PM -0700, Randy Bush:
heas,
Whether anyone likes it, it has become a TE knob of sorts, in a protocol
with few such knobs, and many smaller transit providers rely upon it to
affect route selection for non-malicious reasons, such as to balance their
own
I do not have an opinion about what in particular the Threats document
should say (or not say) about the ORIGIN attribute. However, I am quite
concerned about potential hurdles to BGPSEC deployment. It appears that
breaking a current (non- standard) use of ORIGIN had little if any benefit
since no
Therefore, I would like not create a new reason for some operators to deploy
BGPSEC.
From the tone of the remarks preceding this sentence, it seems that you might
have misplaced a not in here somewhere.
Could you clarify?
--Sandy
___
sidr mailing
I am sorry.
I do not want to sign ORIGIN if doing so will create a new obstacle to
deploying BGPSEC
On Mar 11, 2013 7:05 PM, Murphy, Sandra sandra.mur...@sparta.com wrote:
Therefore, I would like not create a new reason for some operators to
deploy BGPSEC.
From the tone of the remarks
On 2013-03-11 18:33, Matthew Lepinski wrote:
I am sorry.
I do not want to sign ORIGIN if doing so will create a new obstacle
to deploying BGPSEC
And I'm saying that the ability (i.e., option) to protect the ORIGIN as
set by the originating AS is IMO one reason that's a positive to deploy
On 2013-03-11 13:31, Stephen Kent wrote:
Danny,
We have been told by several operators that the values stated in
Section 4.3 of RFC 4271 are not what is used today. We also have been
told that, contrary to the SHOULD NOT in Section 5.1.1 of this RFC,
it is not uncommon for ASes to change this
On 2013-03-08 11:10, Murphy, Sandra wrote:
In reviewing the discussions about the threat document, the wg
eventual consensus wrt one topic was not clear to the chairs.
The ORIGIN attribute was mentioned by some as having the potential to
be used out-of-spec to influence routing through the
On Sun, Mar 10, 2013 at 12:00 PM, Danny McPherson da...@tcb.net wrote:
On 2013-03-08 11:10, Murphy, Sandra wrote:
In reviewing the discussions about the threat document, the wg
eventual consensus wrt one topic was not clear to the chairs.
The ORIGIN attribute was mentioned by some as having
In reviewing the discussions about the threat document, the wg eventual
consensus wrt one topic was not clear to the chairs.
The ORIGIN attribute was mentioned by some as having the potential to be used
out-of-spec to influence routing through the neighbor (and their neighbors,
etc.).
One
18 matches
Mail list logo
