Hi Mohit, Thanks for the review. Please find inline my responses. I have included your comments as well as additional nits in [1]. As soon as we believe the version addresses your concerns a new version will be published.
Yours, Daniel [1] https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/47f1351b1928ba687af18e75e253e98720448e8e On Sat, Mar 20, 2021 at 5:12 AM Mohit Sethi M <mohit.m.sethi= 40ericsson....@dmarc.ietf.org> wrote: > I am now preparing the shepherd writeup for draft-ietf-lwig-minimal-esp. > I wanted to clarify and double check a few things: > > - If the SPI is not random and is chosen by some application specific > method -> it can reveal the application using ESP. > <mglt> It is correct that the use of non random SPI may have some privacy impacts and one of these impacts is that in some cases, a SPI may be used to track an application. Note that our intention was to make it clear that when SPI are non randomly generated, there are some privacy implications to consider as well as that randomly generated SPI is preferred. In general an application rarely selects the SPI value to be used. Instead, the system is rather in charge of applying the security policies and selects the SPI according to its implementation. Suppose a system is running X applications and uses Y > X SPI that are not randomly generated out of the 2**32 possible values. The X applications may be tunneled over one security association. In that case, the traffic of a specific application X0 will not be identified from the traffic of the other applications. So in order to identify one application with an SPI value, the security association needs to be set for that application specifically. This may happen in some cases where the device is only running one application and with a very limited number of SPI. In that case, the distribution of SPI may have some values that are over-represented. Note that the draft defined one (common way) to generate the SPI value that is using a random generator to generate this SPI value. All other means fall into the category of using deterministic functions. This does not necessarily mean that a fix of predefined SPI will necessarily be used. This includes for example the fact that only 2**16 or 2**24 values may be candidates. The case where one device has a very limited number of SPI is quite extreme. In any case, it should be estimated how much the SPI leaks more information than the IP destination and the use of IPsec as well as the pattern associated with the traffic. Typically a destination to www.mytemperature.com every 5 minutes with a fixed size is likely to reveal the presence of a temperature sensor, independently of the SPI value. As a conclusion, I am inclined to say, there are some cases when using nonrandomly generated SPI over 32 bytes may reveal the presence of a given application. However, when this occurs, other conditions need to be met. It seems to me the document mentions clearly that privacy implication needs to be considered when these alternative methods are considered. If there is anything that appears not to be clear, I am happy to clarify it. </mglt> > > - I assume a resource-constrained device would not have many inbound > connections. Would it make sense to generate a byte of randomness > instead of entire 32-bit SPI? At least some APIs allow asking for a byte > of randomness (randomByte()). This is assuming an upper limit on the > number of inbound connections. > <mglt> The text opposes the 32 bit random SPI versus other ways to generate the SPI. The alternative you propose falls into that category. It seems to me that the confusion may come from discussions where we discussed the use of a fixed small number of SPIs. This specific case has been generalized to any subset of the 2**32 possible SPIs. I mention the text below from the current draft that I think should address your concern, but I am fine making it clearer. """ However, for some constrained nodes, generating and handling 32 bit random SPI may consume too much resource, in which case SPI can be generated using predictable functions or end up in a using a subset of the possible values for SPI. In fact, the SPI does not necessarily need to be randomly generated. A node provisioned with keys by a third party - e.g. that does not generate them - and that uses a transform that does not need random data may not have such random generators. However, non random SPI and restricting their possible values MAY lead to privacy and security concerns. As a result, this alternative should be considered for devices that would be strongly impacted by the generation of a random SPI and after understanding the privacy and security impact of generating non random SPI. """ </mglt> > > - When sequence numbers are time -> won't it reveal the time at which > the packet was sent. > > <mglt> First the use of time is primarily driven to have a always increasing function, more than the value of the time itself. This could be used with a clock that is 2 years back in the past or in the future. It is correct that a few packet analysis may reveal how synchronized the clock of the device is. Regarding the time the packet has been sent, it seems to me this is relatively close to the time the time is captured, but maybe I am missing how this could be used or any specific cases where delay tolerant networks are involved. So I am inclined to say that yes this may leak some information, but this information may already be leaked. </mglt> > - Are we comfortable with the recommendation: 'A node MAY drop > anti-replay protection provided by IPsec, and instead implement its own > internal mechanism.'? What might this internal mechanism look like? > > <mglt> Enabling anti reply protection is no mandatory, so that is the default. RFC4303 mentions: """ The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA. """ Some mechanisms that come to my mind are implementations that receive packets in a very deterministic manner. Note that the document recommends to enable anti-replay. </mglt> > A few typos: > > ----- > > Section 3: > > Please expand SAD on first usage. > <mglt> fixed. Thanks for raising that issue. </mglt> > > Section 4: > > Typo: In a constrainted environment -> In a constrained environment > > <mglt> fixed. I also check there are no other occurrence and it seemed that was the only occurrence. </mglt> I looked at old RFCs and they seem to use both crypto-suite and > cryptosuite. I have a preference for the later. Perhaps we can remove > the hyphen. > > <mglt> I have removed the occurrences I found of crypt-suite and replaced them by cryptosuite. </mglt> > ----- > > --Mohit > > > > _______________________________________________ > Lwip mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
