Hi,
I have read this document and i believe this is a useful thing to have
and it ready for publication.
I have some comments. I am far from an expert on this area, so consider
these comments as coming from a somehow informed outsider.
My more general comment, is that i understand this mechanism is very
useful to deal with operational mistakes rather than as a security tools
to deal with attackers (especially if not deployed with RPKI). If that
is the case, it should be clarified in the document as per my comments
below. If that is not the case, i would appreciate some enlightenment.
Some comments:
The boiler plate, especially the name of the authors seems not properly
aligned.
Section 1, terminology, the terms are not in correct alphabetical order
In section 3 it reads:
Some examples of such security and operational
issues include BGP route leaks affecting the anycasted service, rogue
anycast nodes appearing for the service, or the emergence of other
aberrant behavior in either the routing system, the forward query
datapath, or query response datapath.
So, I fully understand that using unique origin AS will help debugging
operational mistakes, but i am not sure i understand why this is a
security feature. I mean, if an atttacker wants to inject the anycast
prefix, it could even use one of the appropriate AS numbers as origin
and with this new practice, it could even issue it with its own AS
number and would be still be ok as different AS origins will be
acceptable (of course, this would make it traceable, but still). So
bottom line is, i don't understand why this is a security tool.
Then the same section reads:
Additionally, while it goes without saying that anycasted services
should always strive for exact synchronization across all instances
of an anycasted service address, if local policies or data plane
response manipulation techniques were to "influence" responses within
a given region in such a way that those response are no longer
authentic or that they diverge from what other nodes within an
anycasted service were providing, then it should be an absolute
necessity that those modified resources only be utilized by service
consumers within that region or influencer's jurisdiction.
I agree with the statement, but maybe it would be worth stating more
explicitly how this relates to the proposal. I guess you are envisioning
to filter routes of anycasted prefixes based on the origin, sicne you
know that certain origins are being "creative" in the treatment of their
replies?
In section 3 it reads:
Discrete origin ASNs per node provide a discriminator in the routing
system that would enable detection of leaked or hijacked instances
Again, i am not sure how this helps with hijacked prefixes as the
hijacker should be able to also fake the origin AS, right?
Later on, in section
5. Security Considerations
The recommendations made in this memo aim to provide more flexibility
for network operators hoping to better monitor and prevent issues
related to globally anycasted critical infrastructure resources.
Anycast itself provides considerable benefit in the face of certain
attacks, yet if a given instance of a service can appear at many
points in the routing system and legitimate instances are difficult
to distinguish from malicious ones, then anycast expands the
service's attack surface rather than reducing it.
How come that an anycast service expands the surface of an attack? I
would actually say the opposite, the surface of the attack diminishes as
there are more anycast servers deployed, as each server will serve a
smallr surface, what am i missing?
El 17/12/10 5:54, Peter Schoenmaker escribió:
Hi,
I would like to issue last call for draft-ietf-grow-unique-origin-as-00. We
will close last call Jan 2nd 2011.
Please review the draft and provide any last comments.
Thanks
Peter
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
