Re: WG Review: Source Address Validation in Intra-domain and Inter-domain Networks (savnet)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi,

I oppose the creation of this working group on the basis
that it makes no mention of privacy. Extending the kind
of privacy-unfriendly source address validation mechanisms
(unwisely IMO) used, to something deployed at Internet-scale,
could be a major error.

In this case, IMO the *first* and only step so far should be
a privacy analysis including the potential ill effects of
current schemes even when only deployed in smaller networks.
And when that stage is completed, there should be a decision
point as to whether to abandon the effort entirely if it
remains privacy-unfriendly.

Cheers,
S.

On 03/06/2022 18:50, The IESG wrote:
A new IETF WG has been proposed in the Routing Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (iesg@xxxxxxxx) by 2022-06-13.

Source Address Validation in Intra-domain and Inter-domain Networks (savnet)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
   Joel Halpern <jmh@xxxxxxxxxxxxxxx>

Assigned Area Director:
   Alvaro Retana <aretana.ietf@xxxxxxxxx>

Routing Area Directors:
   Alvaro Retana <aretana.ietf@xxxxxxxxx>
   John Scudder <jgs@xxxxxxxxxxx>
   Andrew Alston <andrew-ietf@xxxxxxxxxxx>

Mailing list:
   Address: savnet@xxxxxxxx
   To subscribe: https://www.ietf.org/mailman/listinfo/savnet
   Archive: https://mailarchive.ietf.org/arch/browse/savnet/

Group page: https://datatracker.ietf.org/group/savnet/

Charter: https://datatracker.ietf.org/doc/charter-ietf-savnet/

Charter for SAVNET Working Group

Source address validation (SAV) is one important way to mitigate source
address spoofing attacks in the data plane.  Therefore, it is desirable to
deploy SAV in intra-domain and inter-domain networks.  However, existing SAV
mechanisms like uRPF-related technologies may improperly permit spoofed
traffic or block legitimate traffic.

The "Source Address Validation in Intra-domain and Inter-domain Networks
(SAVNET)" working group will define routing protocol-independent architectures
and procedures to accurately determine the valid incoming router interfaces
for specific source prefixes.  The accuracy of the enhancements is expected
to improve upon current SAV mechanisms.

The scope of the SAVNET WG includes the SAV function for both intra-domain and
inter-domain networks and the validation of both IPv4 and IPv6 addresses.  The
WG will address intra-domain solutions first and focus on routing protocol-
based mechanisms.  SAVNET should avoid packet modification in the data plane.
Existing control and management plane protocols should 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
carried out in the working groups responsible for them and in coordination
with this working group.

The SAVNET WG is chartered for the following list of items:

(1) Problem Statement, Use Cases, and Requirements

     This document should include an analysis of the current solutions and
     their limitations.  This item may require one document to address
     intra-domain SAV and another to address inter-domain SAV.

     This document may not necessarily be published as an IETF Stream RFC, but
     may be maintained in draft form or on a collaborative Working Group space
     to support the efforts of the Working Group and help newcomers.

(2) SAVNET Architecture Documents

     This item requires one document to address intra-domain SAV and another to
     address inter-domain SAV.  Each document must describe the conditions
     under which the architecture can improve accuracy or performance with
     respect to existing SAV mechanisms without assuming pervasive adoption.
     Each document must also include the threat model addressed by the
     proposed architecture and a comparison to existing SAV mechanisms.

(3) Definition of routing protocol-independent operation and management
     mechanisms to operate and manage SAV-related configurations.

After each of the items above has reached WG consensus, a discussion about
whether it is appropriate to continue must occur.  The discussion can consider
topics related to the accuracy of the mechanism and the types of attacks it
can prevent.  The WG Chairs will define the specific criteria and determine
that rough consensus has been reached before continuing.  The WG may be
rechartered or closed if rough consensus is not reached.

The SAVNET WG will coordinate and collaborate with other WGs as needed.
Specific interactions may include (but are not limited to):
         * lsr for OSPFv2, OSPFv3 and IS-IS extensions
         * idr for BGP extensions
         * lsvr for BGP SPF extensions
         * rift for RIFT extensions

Each of these other WGs can independently determine the applicability and
priority of SAV to their deployments.

Milestones:

Nov 2022: Adopt the Problem Statement, Use Cases, and Requirements document

Jul 2023: Adopt the Intra-Domain Architecture document

Mar 2024: Submit the Intra-Domain Architecture document to the IESG for
publication

Mar 2024: Adopt operations and management for Intra-domain networks document

Mar 2024: Adopt the Inter-Domain Architecture document

Jul 2024: Submit operations and management for Intra-domain networks document
to the IESG for publication

Nov 2024: Submit the Inter-Domain Architecture document to the IESG for
publication

Nov 2024: Adopt operations and management for Inter-domain networks document

Mar 2025: Submit operations and management for Inter-domain networks document
to the IESG for publication

_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce

Attachment: OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux