Hello! > > In fact this is a serious bug. Because we don't take saddr into account, > > we will end up rejecting valid SPIs from remote peers should two different > > peers choose the same SPI. > > Scratch that. I misunderstood the way the SPI is determined. It's the > destination host that determines the SPI and not the source. Actually, keying by (daddr,spi,proto) is really important, but only for multicasting, when many of sources share one SA. Normally, (daddr,spi,proto) maps to SA which has some saddr assigned as a part of SA data. So, unless SA is established to have wildcard source, we should check for its validity. > way to model it so that we do not deviate from the paradigm that each > SA corresponds to a (daddr, spi, proto) triple. This is right, of course. But I think it would be not so stupid not to bind to IPsec semantics too much. One day some transformation may want to lookup for some another fields: flowlabel, dsfield, even transport header fields. So, the way in direction of extension spi does not look very good from this viewpoint. Alexey - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
