RE: [savnet] 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 Stephen,

If your concern is not "address" or "prefix", I am wondering what the main concern is. We have explained that the current solution does not expose user-level information. You may oppose any kind of solution which "exchanges more information between routers/ASes", or may oppose this kind of solution which "exchanges forwarding information among routers/ASes". 

If the former is the case: actually many protocol proposals in IETF are "exchanging more information between routers/ASes", including routing protocols. 

If the latter is the case: For intra-domain, "forwarding path" information should not be a privacy. For inter-domain, the proposed solution does not expose more privacy, because "whether selecting a neighboring AS as the next hop" can also be inferred by the neighboring AS today (by detecting whether receiving traffic). 

Best,
Dan 

-----邮件原件-----
发件人: savnet-bounces@xxxxxxxx <savnet-bounces@xxxxxxxx> 代表 Stephen Farrell
发送时间: 2022年6月4日 5:03
收件人: Joel Halpern <jmh.direct@xxxxxxxxxxxxxxx>; adrian@xxxxxxxxxxxx; 'Alvaro Retana' <aretana.ietf@xxxxxxxxx>; iesg@xxxxxxxx; 'IETF-Discussion' <ietf@xxxxxxxx>
抄送: savnet@xxxxxxxx
主题: Re: [savnet] WG Review: Source Address Validation in Intra-domain and Inter-domain Networks (savnet)


Hiya,

Sorry, I don't mean to be disruptive but I'm not at a point where I feel that me offering charter text is the right way to go - I clearly don't understand the proposal well enough for that.

On 03/06/2022 21:56, Joel Halpern wrote:
> If you want to suggest some edits to make clear that we are talking 
> about prefixes, please do so.  I am probably too close to the document 
> to see where that would be useful.
> 
> Yours,
> 
> Joel
> 
> On 6/3/2022 4:47 PM, Stephen Farrell wrote:
>>
>> Hi Joel,
>>
>> On 03/06/2022 21:38, Joel Halpern wrote:
>>> 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
>>
>> Clarifying question: if prefixes are what are being validated why 
>> does the name mention addresses and the text "current SAV mechanisms" 
>> (where A==address presumably)?

I'd still be interested in an answer to the above btw,

Cheers,
S.

PS: Dealing in prefixes may not of course make much of a difference as ISPs may hand out /56's which is the case for me. One'd also have to consider VPNs of various flavours maybe before understanding the privacy impacts. So, just to be clear, I'm not saying "addresses bad, prefixes good":-)


>>
>> Ta,
>> S.
>>
>>> they will be using as source address for packets they will be 
>>> forwarding. These are not the individual addresses of users. And, 
>>> conversely, this is exactly the information one needs to perform 
>>> source address spoof prevention.   (Whether the proposed / expected 
>>> mechanisms will actually provide improved information is part of 
>>> what has to be determined.)
>>>
>>> Further, we have specified that the problem and requirements will be 
>>> spelled out before any solutions are examined by the working group.
>>> So we can confirm that there is indeed a problem to solve.
>>>
>>> This is not "extend SAVI individual host registrations into ISPs."  
>>> I have no problem including privacy in the analysis. But I am much 
>>> less concerned than I was (and yes Stephen, I did take your concerns
>>> seriously) when we did the SAVI work.
>>>
>>> Yours,
>>>
>>> Joel





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

  Powered by Linux