Here “port” means the physical port (interfaces) of routers, not the “port number” of user’s applications. We never touch any validation on “source address + port number” tuple. Best, Dan 发件人: Robert Raszuk <robert@xxxxxxxxxx>
发送时间: 2022年6月4日 7:34
收件人: Dan Li <tolidan@xxxxxxxxxxxxxxx>
抄送: Stephen Farrell <stephen.farrell@xxxxxxxxx>; Joel Halpern <jmh.direct@xxxxxxxxxxxxxxx>; Adrian Farrel <adrian@xxxxxxxxxxxx>; Alvaro Retana <aretana.ietf@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, > We have explained that the current solution does not expose user-level information. If your slides state that validation will be done based on the tuple src+port then you are already exposing my ports. That is no good as it directly opens my endpoints for targetted attacks. And how can you not reveal my address and just expose site prefix if everyone would be serving on different ports and using different services ? Leave alone that for sites doing dynamic v4 NAT ports are very random by design. Not to even mention that to detect in a timely fashion what ports are used (when ports are dynamic) is not a simple exercise. 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
|
