ipsec---icmp: ipsec中icmp的处理

#
# This doc describe:
#
#       ipsec special handling to icmp
#


---------------------------------------------------------------------------------------------------------------


#
# [*] RFC descriptions about fragment / PMTU discovery / icmp, are kind of comprehensive ( and little scary ), need to understand carefully, and keep focus. 
#
#           <<rfc4301---Security Architecture for the Internet Protocol.txt>>
#
#               6.  ICMP Processing
#
#               7.  Handling Fragments (on the protected side of the IPsec boundary)
#
#               8.  Path MTU/DF Processing
#
#               Appendix D: Fragment Handling Rationale
#
#
# [*] While some ipsec books description is not accurate ( quite not accurate, seems writer himself doesn't understand fully when writting books ), don't trust them.
#
#           <<VPNs.Illustrated.Tunnels.VPNs.and.IPsec>>
#
#               10.7.3. ICMP Processing
#
#           
#           <<IPSec.The.New.Security.Standard.2nd.Edition>>
#
#               4.6. Fragmentation
#
#               4.7. ICMP
#
#               9.3. Fragmentation and PMTU
#
#               9.4. ICMP Processing
#
#
#   Here, I am not interested in correct those inaccurate ( or wrong) description on books. 
#
#   Such as:
#
#        In the ICMP error packet, the first 64 bits of the data are the SPI and sequence number values of the ESP header. When RA receives the ICMP packet, it cannot determine the actual source because either A1 or A2 could have generated the packet. This is because the same SPI is used to secure all packets originating from network 1.1.1/24 and destined to 4.4.4/24.
#
#           --- This is not accurate, we could see RFC ( quote in the following doc ).
#
#   see:
#
#       <<L3---icmp.txt>>
#
#           => icmp error message ( internally contains inner error packet portion, the portion length is differnet between ip4 and ip6 )       
#




===============================================================================================================


--- index:


---------------------------------------------------------------------------------------------------------------


=> ipsec handle icmp non-error and error message differently    # like $(netfilter) $(conntrack) and $(nat)


---------------------------------------------------------------------------------------------------------------


=> icmp non-error message


---------------------------------------------------------------------------------------------------------------


=> icmp error message


    => transport mode: icmp error message handling


    => tunnel mode: icmp error message handling


        => icmp error message sent from unprotected side, might populate to protected side. # mainly icmp TooBig for PMTU discovery


        => icmp error message sent from protected side of remote SG.


---------------------------------------------------------------------------------------------------------------


=> <quote> from: <<rfc4301---Security Architecture for the Internet Protocol.txt>> / 6.  ICMP Processing


---------------------------------------------------------------------------------------------------------------


===============================================================================================================


@@ ipsec handle icmp non-error and error message differently    # like $(netfilter) $(conntrack) and $(nat)


As we see in:


    <<L3---icmp.txt>>


icmp messages are classified into 2 categories:


    error message       # dst-unreach, src-unreach, time-exceeded, parameter-error, redirect    # see icmp_error()


    non-error message   # any message types not error, like: echo, echo-reply, timestamp, timestamp-reply, info-request, infor-reply




like $(netfilter) $(conntrack) and $(nat), $(ipsec) handle icmp non-error and error messages differently:


    for icmp non-error message, handle it like regular traffic, define SP for it.


    for icmp error message, handle it in a different way.   # RFC describe it clearly.




===============================================================================================================


@@ icmp non-error message


<<rfc4301---Security Architecture for the Internet Protocol.txt>> / 6.  ICMP Processing


                                                    Disposition of
   non-error, ICMP messages (that are not addressed to the IPsec
   implementation itself) MUST be explicitly accounted for using SPD        # must explicitly define SP for icmp non-error message.
   entries.




===============================================================================================================


@@ icmp error message


#
# RFC description might be kind of comprehensive ( need focus ), while ipsec books are not accurate.
#
# So I can summerize them myself.
#


--- refer to:


    <<rfc4301---Security Architecture for the Internet Protocol.txt>>
    
        => 6.  ICMP Processing
    
            => 6.1.  Processing ICMP Error Messages Directed to an IPsec Implementation
        
                => 6.1.1.  ICMP Error Messages Received on the Unprotected Side of the Boundary
        
                => 6.1.2.  ICMP Error Messages Received on the Protected Side of the Boundary
        
            => 6.2.  Processing Protected, Transit ICMP Error Messages




===============================================================================================================


@@-@ transport mode: icmp error message handling


The icmp error messages for ipsec packet is from intermediate routers or destination host to source host. no difference
than that of regular packet.




And icmp handling at source host, is just regular:


        $(icmp)


            icmp error message handler


                parse internal bad packet, know it is about a ipsec packet ( from L4 protocol ID of internal bad packet L3 header ).


                then, deliver to ipsec protocol error handler, for further processing.      # "net_protocol->err_handler()"
    


===============================================================================================================


@@-@ tunnel mode: icmp error message handling   # [*][*] Normally, would not populate to protected side.


The icmp error message for ipsec packet is from intermediate routers to source SG. no difference
than that of regular packet.




And icmp handling at source SG, is just regular:


        $(icmp)


            icmp error message handler


                parse internal bad packet, know it is about a ipsec packet ( from L4 protocol ID of internal bad packet L3 header ).


                then, deliver to ipsec protocol error handler, for further processing.      # "net_protocol->err_handler()"




------------------------------------------------------


[*][*][*] Normally, icmp error message is handled by SG, would not populate to inner packet source host in protected side behind it.  Often no need, because icmp error message is for SG, not for inner packet source host.    # a exception is PMTU discovery TooBig message, see other doc.




[*][*][*] Another thing, icmp error message contains "Internet Header + 64 bits of Data Datagram":      # icmpv4 case:


               Internet Header + 64 bits of Data Datagram
            
                  The internet header plus the first 64 bits of the original
                  datagram's data.  This data is used by the host to match the
                  message to the appropriate process.  If a higher level protocol
                  uses port numbers, they are assumed to be in the first 64 data
                  bits of the original datagram's data.     


        for the inner packet.


        For "64 bit of Data Datagram", it ccould over ipsec header, but can not cover inner packet.


        Therefore, SG does not know which source host sent this inner packet. 


            --- By 'SPI' value, can not know.




        So SG can not forward this icmp error message to source host.




--- Some ipsec books are quite not accurate about icmp error message handling. And ipsec RFCs don't talk about this in detail.
    


===============================================================================================================


@@-@-@ icmp error message sent from unprotected side, might populate to protected side. # mainly icmp TooBig for PMTU discovery


see:


    <<(__theory)---ipsec.processing---fragment---PMTU.discovery.txt>>


        => 'DF' bit in tunnel mode outter packet, causing icmp TooBig error message, could affect inner packet. # SG would send a icmp TooBig error message to source host in protected side.




The normal condition is like above, that is:


        icmp TooBig error message for outter packet, would decrease PMTU value on SG.


        then, SG perform fragmentation to outter packet.


        the lost inner packet would be re-transmitted by its source host on protected side.




However:


------------------------------------------------------


--- <quote> from <<rfc4301>> / 8.1.  DF Bit


   All IPsec implementations MUST support the option of copying the DF
   bit from an outbound packet to the tunnel mode header that it emits,
   when traffic is carried via a tunnel mode SA.  This means that it
   MUST be possible to configure the implementation's treatment of the
   DF bit (set, clear, copy from inner header) for each SA.  This
   applies to SAs where both inner and outer headers are IPv4.


------------------------------------------------------


In this case,


    The normal condition does not work.




So it works this way:


    Internet routers send a icmp TooBig error message, to SG.


    SG update the routing entry of outter packet.


        --- This is the same as normal mechanism.




    SG also update the routing entry of inner packet.


    
    Next time, when source host on protected side send a inner packet again, hit the routing entry of inner packet, then
    SG send a icmp TooBig error message to source host.


        --- [*][*] This mechanism may affect PMTU of all the source hosts in protected side.




===============================================================================================================


@@-@-@ icmp error message sent from protected side of remote SG.


--- refer to:


    <<rfc4301>> / 6.2.  Processing Protected, Transit ICMP Error Messages


        => IPsec senders and receivers MUST support the following processing for ICMP error messages that are sent and received via SAs.


            => outbound ICMP error message, # how to match SA


            => inbound ICMP error message   # on an SA


------------------------------------------------------


this is to talk about the following conditions:
    
    host #1 --- { local SG } --- { Internet cloud } --- { remote SG } --- host #2 ( or any internal router )


        ------- outbound -------- tunneled packet ------- inbound ------->


    
        <------ inbound --------- tunneled packet ------- outbound -------  icmp error message.




then, the handling is like this:


    either: explicitly have SP for icmp error message.


    or: use the internal bad packet as selector, to choose SP and SA.   # this one is prefered.




===============================================================================================================


@@ <quote> from: <<rfc4301---Security Architecture for the Internet Protocol.txt>> / 6.  ICMP Processing


6.  ICMP Processing


(
#
# Disposition of non-error, ICMP messages (that are not addressed to the IPsec implementation itself) MUST be explicitly accounted for using SPD entries.
#
)


   This section describes IPsec handling of ICMP traffic.  There are two
   categories of ICMP traffic: error messages (e.g., type = destination
   unreachable) and non-error messages (e.g., type = echo).  This
   section applies exclusively to error messages.  Disposition of
   non-error, ICMP messages (that are not addressed to the IPsec
   implementation itself) MUST be explicitly accounted for using SPD
   entries.




   The discussion in this section applies to ICMPv6 as well as to
   ICMPv4.  Also, a mechanism SHOULD be provided to allow an
   administrator to cause ICMP error messages (selected, all, or none)
   to be logged as an aid to problem diagnosis.




6.1.  Processing ICMP Error Messages Directed to an IPsec Implementation


6.1.1.  ICMP Error Messages Received on the Unprotected Side of the
        Boundary


   Figure 3 in Section 5.2 shows a distinct ICMP processing module on
   the unprotected side of the IPsec boundary, for processing ICMP
   messages (error or otherwise) that are addressed to the IPsec device
   and that are not protected via AH or ESP.  An ICMP message of this
   sort is unauthenticated, and its processing may result in denial or
   degradation of service.  This suggests that, in general, it would be
   desirable to ignore such messages.  However, many ICMP messages will
   be received by hosts or security gateways from unauthenticated
   sources, e.g., routers in the public Internet.  Ignoring these ICMP
   messages can degrade service, e.g., because of a failure to process
   PMTU message and redirection messages.  Thus, there is also a
   motivation for accepting and acting upon unauthenticated ICMP
   messages.


   To accommodate both ends of this spectrum, a compliant IPsec
   implementation MUST permit a local administrator to configure an
   IPsec implementation to accept or reject unauthenticated ICMP
   traffic.  This control MUST be at the granularity of ICMP type and
   MAY be at the granularity of ICMP type and code.  Additionally, an
   implementation SHOULD incorporate mechanisms and parameters for
   dealing with such traffic.  For example, there could be the ability
   to establish a minimum PMTU for traffic (on a per destination basis),
   to prevent receipt of an unauthenticated ICMP from setting the PMTU
   to a trivial size.


   If an ICMP PMTU message passes the checks above and the system is
   configured to accept it, then there are two possibilities.  If the
   implementation applies fragmentation on the ciphertext side of the
   boundary, then the accepted PMTU information is passed to the
   forwarding module (outside of the IPsec implementation), which uses
   it to manage outbound packet fragmentation.  If the implementation is
   configured to effect plaintext side fragmentation, then the PMTU
   information is passed to the plaintext side and processed as
   described in Section 8.2.




6.1.2.  ICMP Error Messages Received on the Protected Side of the
        Boundary


   These ICMP messages are not authenticated, but they do come from
   sources on the protected side of the IPsec boundary.  Thus, these
   messages generally are viewed as more "trustworthy" than their
   counterparts arriving from sources on the unprotected side of the
   boundary.  The major security concern here is that a compromised host
   or router might emit erroneous ICMP error messages that could degrade
   service for other devices "behind" the security gateway, or that
   could even result in violations of confidentiality.  For example, if
   a bogus ICMP redirect were consumed by a security gateway, it could
   cause the forwarding table on the protected side of the boundary to
   be modified so as to deliver traffic to an inappropriate destination
   "behind" the gateway.  Thus, implementers MUST provide controls to
   allow local administrators to constrain the processing of ICMP error
   messages received on the protected side of the boundary, and directed
   to the IPsec implementation.  These controls are of the same type as
   those employed on the unprotected side, described above in Section
   6.1.1.




6.2.  Processing Protected, Transit ICMP Error Messages


   When an ICMP error message is transmitted via an SA to a device
   "behind" an IPsec implementation, both the payload and the header of
   the ICMP message require checking from an access control perspective.
   If one of these messages is forwarded to a host behind a security
   gateway, the receiving host IP implementation will make decisions
   based on the payload, i.e., the header of the packet that purportedly
   triggered the error response.  Thus, an IPsec implementation MUST be
   configurable to check that this payload header information is
   consistent with the SA via which it arrives. (This means that the
   payload header, with source and destination address and port fields
   reversed, matches the traffic selectors for the SA.) If this sort of
   check is not performed, then, for example, anyone with whom the
   receiving IPsec system (A) has an active SA could send an ICMP
   Destination Unreachable message that refers to any host/net with
   which A is currently communicating, and thus effect a highly
   efficient DoS attack regarding communication with other peers of A.
   Normal IPsec receiver processing of traffic is not sufficient to
   protect against such attacks.  However, not all contexts may require
   such checks, so it is also necessary to allow a local administrator
   to configure an implementation to NOT perform such checks.


   To accommodate both policies, the following convention is adopted.
   If an administrator wants to allow ICMP error messages to be carried
   by an SA without inspection of the payload, then configure an SPD
   entry that explicitly allows for carriage of such traffic.  If an
   administrator wants IPsec to check the payload of ICMP error messages
   for consistency, then do not create any SPD entries that accommodate
   carriage of such traffic based on the ICMP packet header.  This
   convention motivates the following processing description.


(
#
# IPsec senders and receivers MUST support the following processing for ICMP error messages that are sent and received via SAs.
#
)
   IPsec senders and receivers MUST support the following processing for
   ICMP error messages that are sent and received via SAs.




(
#
# outbound ICMP error message,  # how to match SA
#
)
   If an SA exists that accommodates an outbound ICMP error message,
   then the message is mapped to the SA and only the IP and ICMP headers
   are checked upon receipt, just as would be the case for other
   traffic.  If no SA exists that matches the traffic selectors
   associated with an ICMP error message, then the SPD is searched to
   determine if such an SA can be created.  If so, the SA is created and
   the ICMP error message is transmitted via that SA.  Upon receipt,
   this message is subject to the usual traffic selector checks at the
   receiver.  This processing is exactly what would happen for traffic
   in general, and thus does not represent any special processing for
   ICMP error messages.


   If no SA exists that would carry the outbound ICMP message in
   question, and if no SPD entry would allow carriage of this outbound
   ICMP error message, then an IPsec implementation MUST map the message
   to the SA that would carry the return traffic associated with the
   packet that triggered the ICMP error message.  This requires an IPsec
   implementation to detect outbound ICMP error messages that map to no
   extant SA or SPD entry, and treat them specially with regard to SA
   creation and lookup.  The implementation extracts the header for the
   packet that triggered the error (from the ICMP message payload),
   reverses the source and destination IP address fields, extracts the
   protocol field, and reverses the port fields (if accessible).  It
   then uses this extracted information to locate an appropriate, active
   outbound SA, and transmits the error message via this SA.  If no such
   SA exists, no SA will be created, and this is an auditable event.




(
#
# inbound ICMP error message    # on an SA
#
)
   If an IPsec implementation receives an inbound ICMP error message on
   an SA, and the IP and ICMP headers of the message do not match the
   traffic selectors for the SA, the receiver MUST process the received
   message in a special fashion.  Specifically, the receiver must
   extract the header of the triggering packet from the ICMP payload,
   and reverse fields as described above to determine if the packet is
   consistent with the selectors for the SA via which the ICMP error
   message was received.  If the packet fails this check, the IPsec
   implementation MUST NOT forwarded the ICMP message to the
   destination.  This is an auditable event.




===============================================================================================================


@@ end