[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAs that carry fragments Was: Re: Some IKEv2 issues
Nicolas Williams wrote:
> On Fri, Feb 20, 2004 at 04:15:14PM -0500, Stephen Kent wrote:
>
>>Nicolas,
>>
>>
>> <SNIP>
>>
>>>>>In BITW scenarios with SPDs that use port selectors this issue comes
>>>
>>>up,
>>>
>>>>>as it does in one side of SG/VPN scenarios, right?
>>>>
>>>>It used to be the case that transport mode was restricted to end
>>>>systems, but due to popular demand we have removed that restriction.
>>>>so, this used to be just a tunnel mode issue for SG scenarios, but it
>>>>might arise for transport mode too,under our new paradigm.
>>>
>>>I thought that SGs were allowed to use transport mode for administrative
>>>traffic where the SG is an end-point. Is this a misunderstanding of the
>>>new paradigm? If not then no issue here.
>>
>>The old model allowed SGs to use transport mode for admin traffic.
>>The new model allows SGs to use it for any traffic, e.g., so that an
>>overlay net that does IP-in-IP tunneling can use transport mode for
>>the already tunneled packets.
>
> But in that case the transport mode SAs would still be end-to-end and,
> outside the end-point fragmentation in BITS implementations, the clear
> packets would not be fragmented prior to application of transport-mode
> protection. Right?
The transport-mode SAs could be at the SGs. In that case, the clear
packets might be fragmented when tunneled (due to the additional
header), which would be before transport-mode processing.
> I meant an end-point receiver. Presumably an SG wouldn't have to
> reassemble packets it is tunnelling -- it would apply the fragment
> selector/id caching approach to select an SA for fragments (and then
> only if the SPD has entries that use selectors that can be obscured by
> fragmentation) as discussed.
I would expect that the IP tunnel dest. endpoint would reassemble, but
that would happen after receive SG transport-mode processing if using
transport + IPIP tunnels.
Joe