SAVNET-ProblemStatement-Architecture / Intra-domain-problem-statement

1 stars 0 forks source link

14. Much duplication in the documents/slides between inter and intra-domain and external which leads me to this elephant in the room problem i keep looking at. From Jared Mauch [after ietf 115] #22

Open XiaoTianCan opened 1 year ago

XiaoTianCan commented 1 year ago

Related comments from Yuanyuan Zhang: For section “5.2 All-direction Protection”, it seems that blocking spoofed traffic from outside the AS is the duty of the inter-domain SAV mechanism. Only deploying intra-domain SAV in a single AS can’t help the edge routers to get enough knowledge about which source IP addresses should be blocked from the Internet. This requirement seems to be a goal quite hard to achieve. [after ietf 115]

Dan Li: For the boundary between intra-domain SAV and inter-domain SAV, the current drafts take the following way. For intra-domain SAV, the SAV mechanisms are only needed to deploy within the domain (AS). For inter-AS SAV, the SAV mechanisms need interaction between domains (ASes). This is the reason why we put “blocking spoofed traffic from outside the AS which spoofs the addresses of the AS itself” as an intra-domain requirement. Because this purpose can be achieved if all the IP addresses of the domain are advertised to the boundary routers. Another problem which needs to be solved for intra-domain SAV is in the access networks of the domain, where multi-homing connection exists.

XiaoTianCan commented 1 year ago

Revision summary: Intra- and inter-domain SAVs are for different validation tasks. The updated drafts have included more descriptions of the two kinds of SAV.