Just add to Joel ‘s comments.
In the SAVNET BOF in IETF 113, we presented the problem statement / gap analysis staff of the SAVNET work. Many people think that the problem is well defined, which was echoed by Eric’s conclusion email sent to the mailing list.
BTW, the privacy issue was also discussed in the BOF. People who did not attend the BOF can find our presentation slides from https://datatracker.ietf.org/meeting/113/materials/slides-113-savnet-dsav-framework-01. The privacy discussion is in Page 29.
Best,
Dan
发件人: savnet-bounces@xxxxxxxx <savnet-bounces@xxxxxxxx> 代表 Joel Halpern
发送时间: 2022年6月4日 6:00
收件人: Robert Raszuk <robert@xxxxxxxxxx>
抄送: The IESG <iesg@xxxxxxxx>; IETF-Discussion <ietf@xxxxxxxx>; savnet@xxxxxxxx
主题: Re: [savnet] WG Review: Source Address Validation in Intra-domain and Inter-domain Networks (savnet)
If every operator were doing accurate uRPF filtering at their edges, then I would expect there to be little benefit to this work. I would also expect there to be little need for the ISOC MANRS initiative, or for all the other efforts to remind folks to do BCP 38 filtering. Evidence tells us that it is not deployed by anywhere near every operator. (I will not specualte on which operators are "decent".)
One of the stated goals is to improve deployability so as to help address that gap.
And no, I did not expect the BoF to reach technical conclusions about the answers, or even technical conclusions about the detailed needs. That is for the working group.
Yours,
Joel
On 6/3/2022 5:53 PM, Robert Raszuk wrote:
Hi Joel,
> Robert, I believe that issue falls well within the topics that need to be described in the problem / requirements work.
I was under the impression that BOF should answer that before WG get's created.
> Note that reachability advertisements are not the same as sourcing advertisements, particularly in the presence of assymetric preferences.
And that is precisely what worries me the most here.
And frankly I am not sure what is wrong with uRPF filtering on the edge just like every decent operator is doing it already today. I heard the desire to move it up the ASNs ... well this is simply going to hurt more then help (IMHO).
Thx
Robert.
On Fri, Jun 3, 2022 at 11:43 PM Joel Halpern <jmh.direct@xxxxxxxxxxxxxxx> wrote:
Robert, I believe that issue falls well within the topics that need to be described in the problem / requirements work.
If we conclude that the cost of providing and enforcing more detailed / accurate information is higher than the benefit, then we (the WG chairs and the WG) will have to stop at that point.
Note that reachability advertisements are not the same as sourcing advertisements, particularly in the presence of assymetric preferences. That is part of why we need to be clear about what this work is doing.
Yours,
Joel
On 6/3/2022 5:23 PM, Robert Raszuk wrote:
Joel,
While working groups can do all sorts of things, the expected results of
this work would be a new or extended mechanisms for routers to tell
other routers what address prefixes they will be using as source address
for packets they will be forwarding.
+
> For the primary work of this WG, what we are concerned with is providing
> the prefix information to use in that validation step.
I am still concerned with the scope of this effort.
IP reachability advertisement is nothing else then indicating what src addresses belong to a given site or ISP.
From what I have understood so far, the objective of this WG was to further trim that IP prefix to indicate a more granular IP address or even ports.
Therefore aside from privacy issues or exposing addresses and active ports for easy attacks I am still very concerned about cutting the ability to fallback to any other end to end routing path in the event of failures or even brownouts.
I have seen responses - Oh we will support backup and multipath. But this does not satisfy my concern as those will be still far less limited to what is available today - which is any node as long as it has reachability or default route can forward packets towards destination.
Thx,
R.
Dan,
Slide 5:
"Discovering the real data-plane forwarding path
via hop-by-hop prefix notification, and
generating SAV tables in routers along the path
"
That is overly restrictive for proper operation of any network. I would suggest to refocus this entire effort to make edge uRPF easy (or easier) to apply.
Many thx,
R,.
On Sat, Jun 4, 2022 at 12:15 AM Dan Li <tolidan@xxxxxxxxxxxxxxx> wrote:
