[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RFC 2401 section 5.2.1



I think you're asking about when source address checks are disabled on
inbound packets.  My interpretation of this is that it's for ICMP error
messages in Tunnel Mode that are generated by a router other than the
Security Gateway that is the ingress point of the tunnel (see RFC 2401
section 6).  Something like this:

H0 ---- SG0 ==== SG1 ---- R1 ---- H1

If SG0 and SG1 have established a tunnel between themselves specifically for
non-host generated ICMP error messages, and R1 detects an error in a packet
going from H0 to H1, the ICMP error message will be carried on the tunnel
between SG0 and SG1 even though the (inner) source address (R1) doesn't
match the SA's source address (SG1).  If SG0 doesn't disable source address
checks for this specific case the error message will be discarded because
the source address check will fail.

I'd be curious to hear from folks out there if

(1) they agree this situation was the intent of RFC2401
(2) they agree this is a compliant way to handle non-host generated ICMP
error messages
(3) their Security Gateway product implements this feature
(4) how (else) their Security Gateway product handles non-host generated
ICMP error messages

Best Regards,
Joseph D. Harwood
jharwood@vesta-corp.com
www.vesta-corp.com

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Francis Dupont
> Sent: Sunday, November 19, 2000 10:49 AM
> To: ipsec@lists.tislabs.com
> Cc: Richard Draves
> Subject: RFC 2401 section 5.2.1
>
>
> In the inbound processing section 5.2.1 the RFC 2401 (IPsec architecture)
> specifies:
>            1. Use the packet's destination address (outer IP header),
>               IPsec protocol, and SPI to look up the SA in the SAD.  If
>               the SA lookup fails, drop the packet and log/report the
>               error.
>
>            2. Use the SA found in (1) to do the IPsec processing, e.g.,
>               authenticate and decrypt.  This step includes matching the
>               packet's (Inner Header if tunneled) selectors to the
>               selectors in the SA.  Local policy determines the
>               specificity of the SA selectors (single value, list,
>               range, wildcard).  In general, a packet's source address
>               MUST match the SA selector value.
>               ...
>               Do (1) and (2) for every IPsec header until a Transport
>               Protocol Header or an IP header that is NOT for this
>               system is encountered.  Keep track of what SAs have been
>               used and their order of application.
>
> How this was intepreted in current implementations:
>  - is the packet's the source address checked in transport mode?
>  - is the packet's outer source address checked in destination mode?
>  - when are the checks done (before, ie. at the end of the lookup
>    routine, after, ie. after the processing of all IPsec headers)?
> If you know it, what is the rationale?
>
> Regards
>
> Francis.Dupont@enst-bretagne.fr
>
> PS: with the exception of KAME (no check), all open source implementations
> I have seen are a bit paranoic, ie. they check all source addresses
> as soon as possible.
>
BEGIN:VCARD
VERSION:2.1
N:Harwood;Joseph;D.
FN:Joseph D. Harwood
ORG:Vesta Corporation
ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa Clara;CA;95054
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:(408) 838-9434=0D=0A5201 Great America Parkway, Suite 320=0D=0ASanta Clara, =
CA 95054
URL:
URL:http://www.vesta-corp.com
EMAIL;PREF;INTERNET:jharwood@vesta-corp.com
REV:20001011T162328Z
END:VCARD

References: