[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