The milestones in the charter seem very aggressive.
"Milestones:
Jul 2022, Adopt the use case document;
Jul 2022, Adopt the problem statement document;
Jul 2022, Adopt the first intra-domain architecture document;
Nov 2022, Adopt the first inter-domain architecture document;
..."
It is better to adopt the use case and problem statement first and then the
others.
Should the "first" be removed? Do we have any "second" intra-domain and
inter-domain architectures?
Best Regards,
Huaimo
________________________________
From: rtgwg <rtgwg-boun...@ietf.org> on behalf of Dan Li
<toli...@tsinghua.edu.cn>
Sent: Sunday, May 8, 2022 9:26 AM
To: sav...@ietf.org <sav...@ietf.org>; 'RTGWG' <RTGWG@ietf.org>
Subject: updated SAVNET WG charter
Dear colleagues,
>From the feedback within and beyond the mailing list, we modify the SAVNET WG
>charter by adding the specific cooperation with other WGs and adding some
>tentative milestones. In what follows you can find the updated WG. We are
>looking forward to further comments from the community.
Best,
Dan
Charter for SAVNET Working Group
Source address validation (SAV) is important to mitigate source address
spoofing attacks. To improve the effectiveness, SAV mechanisms should be
applied as close to the source as possible. Therefore, it is desired to deploy
SAV in both intra-domain and inter-domain networks. However, existing SAV
mechanisms like uRPF-related technologies may improperly permit spoofed traffic
or improperly block legitimate traffic.
The "Source Address Validation in Intra-domain and Inter-domain Networks
(SAVNET)" working group will define a protocol-independent architecture and
procedures to overcome the limitations of existing SAV mechanisms.
Specifically, the SAVNET WG will define procedures that allow nodes to
accurately determine valid incoming ports for specific source prefixes taking
into account information not currently included in routing protocols.
The scope of the SAVNET WG includes the SAV function in both intra-domain and
inter-domain networks, and the validation of both IPv4 and IPv6 addresses. The
WG is expected to address intra-domain solutions first. SAVNET should avoid
packet modification in the data plane. Where possible, existing control and
management plane protocols must be used within existing architectures to
implement the SAV function. Any modification of or extension to existing
architectures, or control or management plane protocols, must be done in
coordination with the WGs responsible for the architecture, or control or
management plane protocol.
The SAVNET WG is chartered for the following list of items:
1) Description of problem statement and use cases for SAVNET, including the
requirements that need to be taken into account by the SAVNET architecture.
2) Definition of SAVNET architecture and new procedures, including both
intra-domain and inter-domain networks.
3) Definition of operation and management mechanisms needed to operate and
manage SAV-related configurations.
4) Solutions to implementing SAVNET architecture by defining modification of
or extensions to existing routing protocols. For those, the SAVNET WG will
coordinate and collaborate with other WGs as needed. Specific expected
interactions include (but may not be limited to):
* lsr for OSPFv2, OSPFv3 and IS-IS extensions
* idr for BGP extensions
* lsvr for BGP SPF extensions
* rift for RIFT extensions
Milestones:
Jul 2022, Adopt the use case document;
Jul 2022, Adopt the problem statement document;
Jul 2022, Adopt the first intra-domain architecture document;
Nov 2022, Adopt the first inter-domain architecture document;
Mar 2023, submit the problem statement document;
Mar 2023, Adopt the operational consideration document;
Jul 2023, submit the intra-domain architecture document;
Jul 2023, Adopt the YANG model document;
Nov 2023, submit the inter-domain architecture document;
Mar 2024, submit the operational consideration document;
Mar 2024, submit the YANG model document.
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
