[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-rfc2401bis-01: editorial nits
At 18:56 +0000 3/2/04, Michael Roe wrote:
>(1) On page 14: "There are two nominal databases in this model ..."
> "A third database, the Peer Authorization Database ..."
>
> Wouldn't it be better to say that there are THREE nominal
>databases in the model?
> (Unless you think that the PAD is somehow not part of the model).
just a "plus or minus 1 bug" :-) we'll fix this text to say three in
both places.
>
>(2) On page 33: "Note: The source address that appears in the encapsulating
> tunnel header MUST be the one that was negotiated during the SA
>establishment
> process."
>
> Should this be the destination address, not the source address?
>(Dst addr + SPI
> will uniquely identify the SA unless it's multicast)
this text is a carry over from 2401. in retrospect, it should be
removed. for a tunnel mode SA, the outer addresses have no security
significance in terms of the receiver, for unicast traffic. for
multicast we now say that either or both of these addresses might be
used for demuxing, and in that case it is important to ensure
consistency over the lifetime of the SA. so we might add a note to
that effect. it also was observed that one might perform some form of
address-based filtering on inbound IPsec traffic prior to demuxing,
and that would also motivate using the same source address, but such
filtering is outside the scope of IPsec.
Steve