[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ICMP{,v6} type/code as a selector...
> While not listed in 2401 explicitly, couldn't one use ICMP/ICMPv6 type and
> code as a selector for a security association? The implementation wouldn't
> be that tough; just overload the already-there port fields for type and code.
I've had this extension implemented, although I didn't overload the
port fields, but wasted separate fields for them. However, if we want
to pass this through PFKEY without changing the structures, using the
port field seems ok.
There is a problem: 0 port is used "any/not-specified" in various
contexts. However, Type=0 and Code=0 appear as legal values. Could
also pack the type and code into single value as destination port (I
think there are some logical grounds not to split the type/code into
source and destination port). Even after packing, there would be
type=0,code=0 situation.
A while back I wondered about what to do with ICMP's generated from
upper layer for packets that have been decrypted by IPSEC. I've a
feeling, that it makes no sense in specifying some selector based on
ICMP error reply type/code to get the error message
encrypted. Instead, it might be more sensible to choose the IPSEC
bundle that applies for the ICMP errors based on the selector
information of the returned packet. Advantage
- the return error gets IPSECed with same rules that would apply to
the matching normal return traffic
Of course, this applies more naturally to IPv6 and ICMPv6, and
additionally I only look at the situation from HOST-HOST
viewpoint. ICMP specific selectors would be sesible for Type > 127
(non-error messages).
--
Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
References: