Agreed on both points. Those milestones are pretty aggressive. Also,
until we have actually progressed the problem statement I do not see how
a working group could adopt a solution.
So, in light of the discussion about avoiding assuming answer, i think
the interesting target would be a date after use case / problem
statement adoption where the WG has to reach rough consensus that even
if not done, the document(s) are stable and represent the working rough
consensus of the WG. At which point we should explicitly discuss if we
think the problem is solvable and what properties a solution has to
have. Before we adopt a solution draft.
Yes, that slows things down. We have had the problem for years, maybe
decades. A few extra calendar quarters to make sure of what we are
proposing seems a good idea.
Yours,
Joel
On 5/10/2022 5:50 PM, Huaimo Chen wrote:
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 <[email protected]> on behalf of Dan Li
<[email protected]>
*Sent:* Sunday, May 8, 2022 9:26 AM
*To:* [email protected] <[email protected]>; 'RTGWG' <[email protected]>
*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
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
