Hi, Rober and Dan,
In my opion, RFC 8955 is for disseminating the rules, and SAVNET is mainly for
generating the rules. If we run SAVNET in inter-domain scenario, RFC 8955 could
be used as a supporting mechanism. Also if we run SAVNET in intra-domain
scenario, RFC 8362 could be used as a supporting mechanism.
Best Regards,
Shu Yang
-----原始邮件-----
发件人:"Dan Li" <[email protected]>
发送时间:2022-05-11 22:23:53 (星期三)
收件人: "'Robert Raszuk'" <[email protected]>, [email protected], 'RTGWG'
<[email protected]>
抄送: 'Lizhenbin' <[email protected]>
主题: Re: [savnet] IPv6 and/or IPv4//RE: SAVNET WG charter
Hi Robert,
First, in the charter we do not specifically mention how to secure the new
protocol. We want to leave it to the architecture design document. But we have
widely discussed the security issue of protocol messages in the mailing list
before. Generally, the SAV message propagation direction is the inverse of BGP
routing advertisement messages, and SAV faces similar security problems as BGP
routing messages. So the security approaches adopted to BGP routing can also be
applied to secure SAV messages, such as BGPsec, RPKI, etc.
Second, RFC 8955 does not solve the problem of SAV. If we talk about BGP flow
spec, let’s focus on the inter-domain scenario of SAV. The idea of SAV protocol
is to let each AS advertise it’s prefixes along the “real” data-plane
forwarding path. Each AS in the path should make a decision on which
neighboring AS to propagate this message, based on its AS routing path it
chooses in the data plane. It’s not “broadcasting” to all neighboring ASes. BGP
flow spec protocol does not handle these issues.
Best,
Dan
发件人: Robert Raszuk <[email protected]>
发送时间: 2022年5月11日 21:39
收件人: Dan Li <[email protected]>; [email protected]; RTGWG <[email protected]>
抄送: Lizhenbin <[email protected]>
主题: Re: [savnet] IPv6 and/or IPv4//RE: SAVNET WG charter
Hi,
Could someone point me to the text (or charter section) describing how this new
protocol is going to be secured ?
In RFC5575/8955 we used BGP to automatically validate if the peer advertising
the DDoS vector is the same as the peer advertising IP reachability to those
src addresses subject to additional filtering.
How is SAVNET going to solve this ?
Also let me repeat one question which I asked before and have not seen reply to
.. What is missing in vanilla RFC8955 for SAVNET ? It is supported today by all
major vendors, deployed and in fact in use. Do we need a mirror of existing
solution ?
There is also ongoing work for Flowspec v2 if there is something missing in v1
- but for SAV I am not sure v2 would be needed.
Thx a lot,
Robert.
On Wed, May 11, 2022 at 1:31 PM Dan Li <[email protected]> wrote:
I agree with Eric and Joel. We may start from IPv6, and continue to work on
IPv4 if no reason to exclude it.
Best,
Dan
发件人:[email protected] <[email protected]> 代表 Joel Halpern
发送时间: 2022年5月11日 1:49
收件人: Lizhenbin <[email protected]>; [email protected]
主题: Re: [savnet] IPv6 and/or IPv4//RE: SAVNET WG charter
It seems to me that as long as the technique is designed to handle IPv6, and
specified to hanlde it, we will not get grief if the same technique is also
document for use with Ipv4.
Yours,
Joel
On 5/10/2022 1:16 PM, Lizhenbin wrote:
Hi,
Regarding the issue of IPv6 and/or IPv4, besides the number of types of
existing IGP routing protocols, it should be taken into account whether the
IPv4 should be supported for SAVNET if the existing routing protocol, such as
ISIS and BGP, can support both IPv4 and IPv6.
In the IAB Statement on IPv6
(https://www.iab.org/2016/11/07/iab-statement-on-ipv6/), the following is stated
“
Therefore, networking standards need to fully support IPv6. The IETF as well as
other SDOs need to ensure that their standards do not assume IPv4.
The IAB expects that the IETF will stop requiring IPv4 compatibility in new or
extended protocols. Future IETF protocol work will then optimize for and depend
on IPv6.
“
I am not sure if the statement should be applied for SAVNET. If YES, in the
charter, IPv6 should be the first.
Best Regards,
Robin
From: Dan Li [mailto:[email protected]]
Sent: Tuesday, May 10, 2022 10:05 PM
To: gengnan <[email protected]>; 'Weiqiang Cheng'
<[email protected]>; Lizhenbin <[email protected]>;
[email protected]; [email protected]
Subject: RE: [savnet] Regarding reusing existing routing protocols for SAV//RE:
SAVNET WG charter
Thank Nan for the consideration. My thoughts about these issues are as follows.
1. For IGP, SAV propagation can indeed leverage some existing types of
messages of IGP routing protocol, such as advertising the IP prefixes attached
to a router. But of course we need to add other types of messages in IGP to
support SAV propagation. So I think it is reasonable to extend IGP routing
protocol to add the SAV functionality.
2. It is interesting to discuss whether we only need to support IPv6. It
is true that the number of existing IGP routing protocols is too many. But if
want to defend against IP address spoofing in the entire Internet, we need a
reason to exclude IPv4.
3. Since the current solution supports partial deployment, it does not
matter that some routers do not run IGP. In this case, we can either assume
that manual configuration like ACL-based SAV will be used in these undeployed
routers (given that they already use static routing), or just assume that no
SAV functionality is enabled in these routers.
Best,
Dan
发件人: gengnan <[email protected]>
发送时间: 2022年5月10日 17:58
收件人: Weiqiang Cheng <[email protected]>; 'Dan Li'
<[email protected]>; Lizhenbin <[email protected]>; [email protected];
[email protected]
主题:答复: [savnet] Regarding reusing existing routing protocols for SAV//RE:
SAVNET WG charter
Hi,
It sounds reasonable to put protocol extension work to the corresponding WGs.
Here are some thoughts on the extensions of IGP for SAV:
a) The propagation manner of SAV messages is different from the original IGP
messages. How to make a good separation from existing IGP mechanisms is also a
problem.
b) Extending all the existing protocols can be a heavy task. Would it be better
to focus on pure ipv6 scenarios first?
c) Some devices may not run IGP. Instead, some static route rules are
configured for packet forwarding. How to enable SAV in these devices can be
considered.
Best,
Nan
发件人: savnet [mailto:[email protected]] 代表 Weiqiang Cheng
发送时间: 2022年5月5日 10:22
收件人: 'Dan Li' <[email protected]>; Lizhenbin <[email protected]>;
[email protected]; [email protected]
主题: Re: [savnet] Regarding reusing existing routing protocols for SAV//RE:
SAVNET WG charter
Hi,
It sounds reasonable.
The proposed WG works for the SAVNET specific architecture and solutions and
the work related to the existed protocols should be done in the corresponding
WGs.
The comment for the charter text as follows:
OLD:
4) Solutions to implementing SAVNET architecture by defining extensions of
existing routing protocols. These will be done in coordination with the WGs
supervising those protocols.
NEW:
4) Solutions to implementing SAVNET architecture by defining extensions of
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 on OSPF and IS-IS extensions
* idr for BGP extensions
…
B.R.
Weiqiang Cheng
发件人: savnet [mailto:[email protected]] 代表 Dan Li
发送时间: 2022年5月5日 08:54
收件人: 'Lizhenbin'; [email protected]; [email protected]
主题: Re: [savnet] Regarding reusing existing routing protocols for SAV//RE:
SAVNET WG charter
Hi Robin,
Thanks for putting the texts of the WG charter in this email thread, which will
help new people who read this email.
1) For inter-domain network. Yes we plan to extend BGP protocol by a new SAFI.
We talked with some other people, such as Igor Lubashev from Akami and Keyur
Patel from Arrcus, and they share the same idea. I think the high-level
architecture design will be done in the SAVNET WG, but the specific protocol
extension will go to IDR WG.
2) For intra-domain network. I think we will use the same way as for
inter-domain network. The high-level architecture design will be done in the
SAVNET WG. Specifical protocol extension to OSPFv2, OSPFv3, IS-IS, BGP SPF,
RIFT will go to the corresponding WGs.
3) For wide coverage of different scenarios, I guess we need to extend all the
existing routing protocols as mentioned above. Hence, we need an independent WG
for the SAVNET usecase/requirements/architecture/management design, while also
need to well cooperate with the other corresponding WGs.
Best,
Dan
发件人: Lizhenbin <[email protected]>
发送时间: 2022年5月5日 0:42
收件人:[email protected]; [email protected]
抄送: Dan Li <[email protected]>
主题: Regarding reusing existing routing protocols for SAV//RE: [savnet] SAVNET
WG charter
Hi Dan and all,
In order for convenience, I directly put the text of the charter in the mail.
I understand the importance of reusing existing routing protocols for SAV which
is described in the charter. But I truly have doubt about it. The following is
some thinking:
1. SAV in inter-domain networks: because BGP is the only existing routing
protocol for inter-domain networks, does it mean BGP is determined for SAV in
inter-domain networks? Because the information distributed for SAV is different
from the existing information distributed by BGP, is it appropriate to take use
of BGP for SAV? If it is necessary to evaluate it, where is the work to be
done, in the SAVNET WG or in the IDR WG?
2. SAV in intra-domain networks: 1) The first issue is the similar as BGP. Are
the existing IGPs appropriate for SAV in intra-domain networks? How to evaluate
and where to evaluate? 2) There are multiple types of IGPs, ISIS, OSPFv2 and
OSPFv3. If IGP can be used for the SAV, do we extend all these IGPs or only
choose one? 3) There is also RIFT and BGP SPF as IGPs. Will RIFT WG and LSVR WG
also be involved besides LSR WG?
3. For both SAV in inter-domain networks and in intra-domain network, how many
existing routing protocols should be extended? BGP + One or more IGPs? BGP for
both inter-domain and intra-domain since BGP-SPF can also be used for
intra-domain?
Best Regards,
Robin
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 working groups 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. This includes 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 extensions of
existing routing protocols. These will be done in coordination with the WGs
supervising those protocols.
The SAVNET WG will coordinate and collaborate with other WGs as needed.
Specific expected interactions include (but may not be limited to): lsr and idr.
From: Dan Li [mailto:[email protected]]
Sent: Monday, May 2, 2022 11:30 PM
To:[email protected]
Cc: Lizhenbin <[email protected]>; [email protected]
Subject: RE: [savnet] SAVNET WG charter
Thank Robin for the remind. I am sending this email to colleagues in the RTGWG
to introduce the SAVNET work.
In IETF 113, we held the SAVNET BOF in the INT Area , with a focus on
intra-domain and inter-domain source address validation (SAV) technologies. The
basic motivation is to overcome the problem of improper block or improper
permit in uRPF-based SAV mechanisms. A control-plane solution was presented in
the BoF. The basic idea is: 1) each node notifies its attached source prefixes
along the real forwarding path, and the routers along the path accordingly
build the correct SAV table; 2) the notification messages are processed in the
control-plane via a hop-by-hop manner, and various methods are used to reduce
the message overhead; 3) following the routing architecture, the notification
is divided into an intra-domain part and an inter-domain part. Given that this
solution is highly related to routing architecture, after the BoF it was
suggested to apply for a WG in the Routing Area.
More materials of the BOF can be found from
https://datatracker.ietf.org/meeting/113/materials/agenda-113-savnet-01.
Enclosed please find the drafted WG charter, which will be improved based on
the feedback we get from the community.
I also hope that RTGWG colleagues who have interest in this topic can join the
SAVNET mailing list (https://www.ietf.org/mailman/listinfo/savnet), which will
be the main channel for future discussions.
Best,
Dan
发件人: Lizhenbin <[email protected]>
发送时间: 2022年5月2日 17:34
收件人: Dan Li <[email protected]>; [email protected]
主题: RE: [savnet] SAVNET WG charter
Hi Dan,
Since the BOF was held in the INT area, maybe not all of the experts from the
RTG area register the mailing list of SAVNET and they are not aware of the work.
I suggest you could forward it to the mailing list of RTGWG and briefly
introduce the design concept and progress of the SAVNET work.
Best Regards,
Zhenbin (Robin)
From: savnet [mailto:[email protected]] On Behalf Of Dan Li
Sent: Thursday, April 28, 2022 4:50 PM
To:[email protected]
Subject: [savnet] SAVNET WG charter
Dear colleagues,
One month has passed since the SAVNET BOF in IETF 113. In the IESG/IAB meeting,
it was concluded that the problem is well-defined and was suggested that SAVNET
be moved to the Routing Area.
After discussing with the ADs in the Routing Area, we decide to apply for
forming a WG with a relatively narrower scope. Specifically, the potential WG
will focus on intra-domain and inter-domain SAV mechanisms by extending
existing routing protocols.
Enclosed please find the drafted WG charter. We would like to get the feedback
from our community.
Best,
Dan
--
savnet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/savnet
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
