IETF 119 SAVNET Minute  (2024-03-19 13:00-15:00 AEST)

1.  Intra-domain Source Address Validation (SAVNET) Architecture (Lancheng Qin)

Chair: There are difference roles for routers from the protocol design perspective. Have you specifiy them?

Lancheng: We will clarify that the new solution is general for different routers.

2.  Inter-domain Source Address Validation (SAVNET) Architecture (Libin Liu)

Ben: Raise the same issue again. It uses RPKI based objects which is similar but not the same. That doesn't exist today.
If this is deployed, it will jeopardize the use of RPKI in routing secuirty. This is a big problem but not addressed.
We need new signed objects. I'm happy to help but no one proposes it. 

Kotikalapudi: Some comments on Slide 14 left figure.

Cary[?]: Does this cover a man-in-the-middle attack who can generate a prefix inside BGP With the right AS origin, but can hijack the path?
I can take it to the mailing list for discussion.

Libin: This is about security issue. We have considered several secuirty requirements in the draft for two types of threats: session and content.
Solutions will be in a separate draft. 

A[?]: Follow up the concern raside by Kaye. I don't think that we have a way of solving that using outbound signaling. We need source signing in band in packet header.

Chair: Solutions should be in separate documents. 

3.  General Source Address Validation Capabilities (Mingxing Liu)

4.  More Methods to Measure IP Source Outbound Spoofing on the Internet (Shuai Wang)

5. Intra-domain SAV Support via IGP, BGP, and use cases (Shengnan Yue)

Chair: If the flag is not necessary, you can use existing IGP/BGP based solution. Can you explain the reason the define the source prefix flags?

Shengnan: We use an optional flag to exend IGP. If we don't need the function, we don't extend IGP/BPG. If we don't extend the protocol, it may be more useful and simple.

Chair: The usecase doc is acutally the deployment scenario, consider to merge it into the architecutre doc.

Shengnan: We can do it as the next step.

6. Bicone Source Address Validation (Lancheng Qin)

Ben:An intersting idea but suffers from the same issue mentioned before. I think it gets more complicated when you have disjoint provider cone and customer cone.

Kotikalapudi:There seems a fundamental flaw in the design.

Lancheng: We have different assumpitons. We can improve the design.

Kotikalapudi: It doesn't answer my question.

Lancheng: That's why we need an allow list.

Kotikalapudi: No.

Ben: I think you are right. 

Lancheng: I'll present this in next session. 

Nan: Some corner scenarios should be considered. Another question: will this method introduce too much dataplane overhead on routers, because we may have a big provider cone. 

Lancheng: Will do some measurement.

7. Signed SAVNET-Peering Information (SiSPI) (Li Chen)

Yangfei: Page 5. What's the addess version? The address faimly should be defined.

Ben: Similar thoughts about the profile. Main question: what the minimal set of peers that one needs to have in order to make sure the necessary amount of information for the protocol to operate.

Li: Will include the discussion in the next revision. 

Ben: One more observation you should write down.

8. BGP Operations for Inter-domain SAV (Xueyan Song)

9. BGP Extensions for Source Address Validation Networks (BGP SAVNET) (Nan Geng)

10. YANG Data Model for Intra-domain and Inter-domain Source Address Validation (Changwang Lin)

Chair: a very early stage document and have enough time to improve. 

Meeting adjourned.