Hi Robert, As for the definition of “valid”, it is the same as uRPF. Specifically, if there exists a feasible “forwarding path” from the “source prefix” to the incoming interface of a router, then the router regard the incoming packet as having a “valid incoming interface”. The only difference between SAVNET and uRPF is how to check the “forwarding path”, which is also the reason why uRPF has inaccuracy problem. Best, Dan 发件人: Robert Raszuk <robert@xxxxxxxxxx>
发送时间: 2022年6月4日 5:36
收件人: Dan Li <tolidan@xxxxxxxxxxxxxxx>
抄送: Joel Halpern <jmh@xxxxxxxxxxxxxxx>; Adrian Farrel <adrian@xxxxxxxxxxxx>; Alvaro Retana <aretana.ietf@xxxxxxxxx>; Stephen Farrell <stephen.farrell@xxxxxxxxx>; 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) Dan, That is true ... but isn't the overall goal to restrict forwarding by additional filtering only over "valid" paths. I am questioning that very definition of "valid". Apologies if I sounded like you are planning to touch IP reachability propagation - I do know you are not. But I am looking at the holistic view. Hi Robert, As for “the objective of this WG was to further trim that IP prefix to indicate a more granular IP address or even ports”, it is not the case. The prefix information exchanged by the proposed solution is just the same as what is exchanged in routing protocols, without “finer-grained ” prefix information. Best, Dan 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.
|
