pasi.ero...@nokia.com writes: > Tero Kivinen wrote: > > > > But now Bob cannot meet the requirement "new SA MUST NOT be narrower > > > than the old one", because it would violate his policy. > > > > This depends which happens first, algorithm selection or narrowing. In > > most cases the first thing happens that traffic selectors are used to > > find suitable policy entry from SPD and then algorithms and traffic > > selectors are selected based on that. > > > > In most case I would not expect Bob to create the old SA that way at > > all, as it would require it to combine two SPD rules together when > > accepting such entry. As the SPD entries are ordered list that would > > mean it was combining two entries which had different locations in the > > list, and I am not sure if combining two SPD entries when creating SA > > is actually allowed by the RFC4301. > > Well, nothing in RFC 4301 requires implementing the SPD internally as > an ordered list of entries; some kind of tree or associative array > data structure could work, too. The requirement for ordered list of > entries applies to the management UI, not the internals. > > So I think an implementation that treats the following two policies > equivalently *is* allowed by RFC 4301 and 4306: > > Policy A: > traffic on UDP ports 1000 MUST use ESP w/AES > traffic on UDP ports 1001 MUST use ESP w/AES > > Policy B: > traffic on UDP ports 1000-1001 MUST use ESP w/AES
Perhaps, but it should not consider following policies equivalently: Policy A: traffic on UDP ports 1000 MUST use ESP w/AES or w/3DES traffic on UDP ports 1001 MUST use ESP w/AES Policy B: traffic on UDP ports 1000-1001 MUST use ESP w/AES meaning that it should delete the Child SA immediately when the one of the policy entries in the policy A was changed to include 2 algorithms. > My main concern was whether this (new SA MUST NOT be narrower than old > one, but MAY be wider) is a new requirement compared to RFC 4306... Does that really matter even if it is new requirement or not? Is there something wrong with that requirement, i.e what is the reason why we should not add that MUST NOT in document? As we have already argued quite long about whether it is new requirement or not, that really says that there was nothing that said it was clearly allowed before. I.e. mostly RFC4306 was silent about the issue, and by interpreting other MUSTs in RFC4301 and RFC4306 I think we can derive same "MUST NOT" requirement we added there. I.e. we are just clarifying RFC4306 to explicitly say something that could have beeen derived from very complex text combination from RFC4301 and RFC4306. I do not think we really must add that text, as I still think it can be derived from other part of specifications, but I think it would make it easier to understand how rekeying child SA is supposed to work. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
