Subject: [sidr] To request your comments on the new draft

From: 张民贵 <[email-masked]>
Date: Tue, 16 Nov 2010 09:20:22 +0800

Dear SIDR members,

A presentation for my draft was given on the SIDR meeting in IETF 79. It was
really appreciated that the SIDR working group gave me this opportunity. The
comments offered by the meeting attendees were valuable and helpful.

This draft is all about the security of BGP which is the mainstream of
Inter-Domain routing protocol today. This draft proposes a novel mitigation
scheme to protect the inter-domain data delivery during false routing
announcements. A new optional and transitive path attribute is defined to
Decouple propagation of a path and adoption of a path for data forwarding in
BGP (DBGP). DBGP does not use suspicious paths for data forwarding, but
still propagates them in the routing system to facilitate attack detection.
It can extensively protect data delivery from routing announcements of false
sub-prefixes, false origins, false nodes and false links, and works well
with ongoing attack detection and prevention systems.

Although the title of SIDR working group is called Secure Inter-Domain
Routing, all works are confined to the solutions based on PKI. I guess that
was why one attendee proposed that DBGP was not proper for SIDR working
group. I knew DBGP does not fit the traditional style of solutions in SIDR.
In fact, the draft was submitted to IDR. I gave presentation in SIDR since
there were experts on the security of BGP and we can get comments to help us
improve. Of course, if you ever thought that we should let in some fresh air
on securing inter-domain routing, I would love to be included. 

One attendee said that the introduction of new path attribute will certainly
increase the complexity of BGP, which will not appeal to the operators. The
design of DBGP is made to be as simple as possible. Only one optional path
attribute is added to the plain BGP. In addition, DBGP can be incrementally
deployed across the whole Internet. ISPs can make their own decision on
whether to adopt it or not. From the evaluation results, one can found that
with only a small deployment rate, a large proportion of ASes are protected
from being attacked. I heard that "draft-ietf-idr-add-paths-04.txt" had just
been accepted as an WG document in IETF 79. In this draft, a more complex
path attribute was devised.

The meeting minutes, the slides and the draft itself are all attached for
your information. Do you have additional comments, please send us emails.

Best Regards,
Mingui Zhang