
The problem as already been defined by Jessica. Something needs to be done.
There needs to be an automated mechanism to deal with this.
A different problem: Masquerading as another AS. Also needs to be solved, but that's not this talk.
How should this be done?
Use DNS to distribute information about encoding prefixes. DNSSEC would provide authentication information. BGP speakers would check the DNS for correct information. The result of this check would be
Success (match), failure (no match, successful return), no information (unsucessful return, no information).
The proposal would add an AS resource record to DNS.
The BGP would need to do these lookups and cache them to build list that BGP can use to validate the information it gets.
If there is a matching AS RR and the origin does not match, it is a BOGON. Don't advertise it. Widthdraw it if necessary and send an SNMP trap.
If there is a matching AS RR and the origin does match, the route is accepted. Authenticated paths could be used over unauthenticated paths.
If there is no matching AS RR, the path is unauthenticated, but may be used.
AS0 would be reserved to indicate an unautheticated path.
AS65535 would be reserved to indicate an unallocated route.
Aggregation would be included.
The DNS part is hard.
It's hard to deal with non-octet boundaries. Using the classless in-addr hack would be used. There is a question about what the root of the name would be (bgp.in-addr.arpa has been suggested).
Open issues:
Thanks to Havard Eidnes, Geert Jan de Groot, Paul Vixie, the DNSSEC group, and Jerry Sharf
Michael Patton notes that CNAMEs only work to end-nodes, not to domains. Tony agrees. He does not see this as a problem. Michael points out this is more complex than any DNS resolving that is currently being done.
Curtis asserts that this does not actually solve this problem. Mike says that this does solve the problem of accidentally advertising bad stuff. It does not solve the problem of bad guys originating bad information. Curtis suggests that a more complete solution should be pursued.
Sandy says that the delegated zone gets to speak authoratatively about the association between a prefix and an AS. Mike and Tony agree. That’s what it is supposed to be.
Is this better than upgrade to existing database stuff? Tony suggested that this is automated.
Curtis thinks that this is worse than what we have now.
Curtis notes that he has not seen any denial of service attacks, only accidental problems. Michael agrees.
A particular router vendor has actually solved this problem. However, Tony notes that two of the authors of this proposal work for this router vendor. Cutis notes that he thinks they are solving a non-problem.
Sean notes that a possible denial of service attack here is to advertise a route that keeps the correct route from being authenticated. Tony notes that the router could ignore unauthenticated routes where less specific authenticated routes exist.
Yakov notes that this proposal solves a practical problem in less than geologic time. He suggests that using DNS is a core of this proposal because it is there, it works and it is distributed.
John Curran notes that the IOPs proposal solves a very common problem. What is the strength of this proposal over the IOPS proposal? Tony notes that these two proposal solves the problem. Tony suggests that doing only one.
Curtis suggests that if the issues with the RR was solved, would there be any need for this. Tony says that that depends on the details of how the problems with the IRR are resolved.