Minutes IETF119: savnet
minutes-119-savnet-01

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.