Stephen Kent wrote: >> I can understand why this should be revisited, but it also requires a >> revision of RFC 2003. RFC 2401 already specifies some incompatible >> rules (e.g. for DF flag processing) that are in conflict with IPIP >> encapsulation as standardized in RFC 2003. (See >> draft-touch-ipsec-vpn-03.txt.) It may be useful to update 2401 and >> 2003 together. > > we already anticipate updating 2401 to describe appropriate ECN > handling. I also anticipate closer alignment with 2003; there has been a > view that tunnel mode was intentionally different from IP-in-IP > tunneling. I don't hold that view is necessarily true in all respects; > tunnel mode is different in terms of offering certain controls to a > security administrator to manage covert channels (which would not > normally be an issue) and in ensuring that the receiver examines the > right portions of the received packet re access controls. to the extent > that there are no adverse security implications, IP-in-IP processing > should be applicable in IPsec. I fully agree that additional restrictions on IPIP tunnels may be required when they are secured via IPsec, exactly for the reasons you mentioned. Since IPIP encapsulation is standardized in 2003, we must make sure that these extra mechanisms don't conflict with the existing standard. Some of them may tuen out useful for non-secured IPIP tunnels, and should maybe go into a revision of 2003 instead. (I'd really like to see 2401bis point off to 2003/2003bis for most tunneling aspects.) Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California
S/MIME Cryptographic Signature