Re: [Last-Call] Secdir last call review of draft-ietf-ippm-stamp-on-lag-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tianran,

Even if they are not issues, it should be stated as such…with some explanation as to why

they are not issues.  Even identifiers that are not direct, e.g. a MAC address, they can be

used to track and establish communication patterns (independent of IP addresses) that

can lead to providing an attack vector.  Is that the potential case here?

 

My interpretation of this draft: this is more to help with measurements which can lead to a change

In how logical links are created.  If an attacker can learn the grouping thru this instrumentation,

Can they do harm especially by forcing such a grouping change?  If not, then that should be explained.

 

From a privacy consideration, having a note to state that while these are identifiers, based on

Rfc6973, one could state that these are identifiers that do not disclose personal information

As it is down at the network layer.

 

Best, Nancy.

 

From: Tianran Zhou <zhoutianran@xxxxxxxxxx>
Date: Monday, December 11, 2023 at 4:20
PM
To: Nancy Cam-Winget (ncamwing) <ncamwing@xxxxxxxxx>, secdir@xxxxxxxx <secdir@xxxxxxxx>
Cc: draft-ietf-ippm-stamp-on-lag.all@xxxxxxxx <draft-ietf-ippm-stamp-on-lag.all@xxxxxxxx>, ippm@xxxxxxxx <ippm@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: RE: Secdir last call review of draft-ietf-ippm-stamp-on-lag-05

Hi Nancy,

Thanks very much for this expert review from the security point of view.
I am not sure if the confidentiality and privacy are really issues in this proposal.
Because the "Sender Micro-session ID" in the message is not really the sender hardware id. It's assigned by the controller.
There is mapping between "Sender Micro-session ID" and "Sender member link identifiers".
So you can see there is text in Section 3.2:
"The mapping between a micro STAMP session and the Sender/Reflector member
   link identifiers can be configured by augmenting the STAMP YANG
   [I-D.ietf-ippm-stamp-yang]."
And the configuration channel is secured by TLS.

Best,
Tianran

-----Original Message-----
From: Nancy Cam-Winget via Datatracker [mailto:noreply@xxxxxxxx]
Sent: Tuesday, December 12, 2023 7:14 AM
To: secdir@xxxxxxxx
Cc: draft-ietf-ippm-stamp-on-lag.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx
Subject: Secdir last call review of draft-ietf-ippm-stamp-on-lag-05

Reviewer: Nancy Cam-Winget
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.


This document defines an extension to the Simple Two-Way Active Measurement Protocol (STAMP) to facilitate performance measurement on every member link of a tag.  As such, the proposed extension is to define a Micro-session identifier and a Session-Reflector member link identifier.

Issue:
As this draft is now exposing identifiers to the actual nodes in the link, there must be inclusions that describe the potential exposure of these nodes given their identifiers are now explicitly communicated.
RFC 8762 only addresses the integrity not the confidentiality of the information disclosed which with the session identifier now needs to be considered.  In addition, privacy considerations describing the potential consequences of this disclosure can lead to.


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

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

  Powered by Linux