Re: Proposed text changes to ESPbis and AHbis for multicast support

[Stephen Kent <kent@xxxxxxx>]

Mark,

I'll try to condense the text to that this message does not grow to 
unmanageable proportions.


> I agree and think think that the source address, and only the source 
> address, should be a MUST.

I'm glad we agree on the need to be clear on what is needed. I 
presume the plan would be to mandate support for using the source 
address for SA demuxing ONLY for SSM SAs, right?  We would not change 
this for unicast SAs, not has there been a good argument for why any 
other form of mutlicast SA needs to make use of this value, so far as 
I can tell. If my interpretation is correct, then the IPsec WG needs 
to decide whether we mandate that all IPsec implementations support 
SSM, or if we say that IF you support SSM, then this is how to do it.



> This is primarily a group controller issue and not a sender issue as 
> described in section 2.1 of the I-D.

The I-D includes text that talks expressly about SSM, and text that 
talks about multiple controllers, without an indication of whether 
the latter text is SSM-specific or applicable to any multicast 
mechanism. I have interpreted it as the latter, and your comment 
suggests this is the desired interpretation.

> I think the I-D states what it needs to:  A group controller 
> maintains the key for the group and the members (senders and 
> receivers) interact with the group controller to establish the group 
> key.  A single multicast group can support multiple SSM groups, each 
> can be in a separate administrative domain with a separate group 
> controller.


> These controllers need not and do not coordinate to do anything.  No 
> such protocol exists to my knowledge, at least not in the public 
> domain.

I think I see the problem in terminology here. The term "group" is 
beong used to refer to a multicast address, and to the set of folks 
who transmit and receive traffic using the address. For security 
purposes, the latter set is the relevant one, wether it's SSM or some 
other multicast method, right? My comments about multiple controllers 
for a multicast group are expressed relative to this latter 
construct. So, for exmaple, I understand that different SSM groups, 
ecah with its own controller, have no assumed relationship among the 
controllers, despiet the fact that they may all make use of the same 
multicast address.  What I was referring to was the more general 
case, where there were multiple controllers for a single group, where 
all the group members shared a key for transmission/reception. 
Perhaps this is the source of much confusion re multiple controllers 
for a "multicast group."  I suggest revised terminology to avoid this 
confusion in the future.


> > why are they unable to coordinate on assigning a single SPI for a 
> > multicast SA? Thus this latter argument for having to use some 
> > parameter other than the destination address and SPI for SA 
> > demuxing is not persuasive.
>
> Maybe the I-D is not clear enough.  There can be N SSM groups for an 
> IP multicast group and there can be as many as N group controllers 
> operating independently.

Yes, the I-D is NOT clear enough in this regard, because of the reuse 
of the term "group."


> It's a matter of SA lookup.  The second paragraph wants to redefine 
> SA lookup, which is the point of the I-D.

I now see what is trying to be expressed, but it is said poorly. Do 
you want to say that an SSM multicast SA (if this applies to ALL 
forms of multicast SAs that would be cleaner, but I've yet to see the 
right arguments for this broad-based characterization) is defined by 
the pair of source IP address plus Destination IP address? Is there a 
need to use the SPI here too, i.e., can there be more than one SA 
from a given transmitter to a single multicast address?  If so, then 
we need to use the triple Source/Destination/SPI for these SAs, but 
that requirement needs to be made clear.

> This is the same issue as above because the text was copied.

right.

> > I agree in principle with the intent of this notion, but the 
> > sticking point is that we have not yet agreed on a way to 
> > accommodate this requirement. Your ID states that requiring an SA 
> > per sender is unacceptable,
>
> Where does it state that?

I infer that this is the underlying assumption, otherwise there would 
be no need to make the explicit statement about per-sender receive 
windows, since each SA provides this facility already and thus does 
not merit repetition here. If I am wrong that's fine, and we just 
need to reword this.

> > and alludes to some scenario that motivates this statement, but 
> > provide no details to support the assertion. The text above has the 
> > flavor of a placeholder, rather than a useful spec to guide 
> > developers in producing interoperable implementations. The text 
> > imposes a vague requirement without any supporting analysis of the 
> > problems imposed by the requirement.
>
> The requirement was stated in a note posted by Bill Fenner to this 
> list last Spring.  The replacement text allows multi-sender SAs, 
> it's clear that this is a change from ESPbis, and designates key 
> management as the entity that determines whether or not a replay 
> window is kept in the receiver.

The IPsec list gets lots of traffic and much of it never affects 
standards, in the final analysis. The I-D you co-authored should 
provide a concise rationale for the proposed changes, which it seems 
to try to do in places.  Anyway, if the intent here is to propose 
allowing multi-sender SAs WITHOUT anti-replay, and mandating 
per-sender SA's when anti-replay is used, then it could be stated 
much, much better.  So, what exactly are your suggesting?


> > We changed the term for good reasons. First, the ICV acronym 
> > expands to "Integrity Check Value" and it has been there since 
> > before the previous set of RFCs. Second, the function really does 
> > provide integrity.  Authentication is a side effect that results 
> > from knowing the identity of the holder of the key used to generate 
> > the ICV, as noted above.
>
> It's not suitable for multicast source authentication.  I think this 
> is explained adequately in section 3.3 of the I-D.

I don't think we are communicating, again.  The field "ICV" has been 
there for years and we just clarified the function it provides in the 
recent revised I-Ds. The comment " It's not suitable for multicast 
source authentication" is without antecedent and needs explanation. 
Are you trying to say that for multicast SAs this field will carry a 
value that provides authentication in a fashion that makes the 
integrity/authentication distinction meaningless? Are you arguing 
that we were wrong to make the distinction even for unicast SAs and 
the current, default HMAC function?  I can't tell from the I-D, or 
from your responses, what you are trying to say here.


> I hope you'll work with us to address the issues that you have identified.
>
> Mark

I'm trying.

Steve