Re: [Ipsec] new ICMP text for 2401bis

[Stephen Kent <kent@bbn.com>]

Mark,

	<SNIP>
>Ahh, I looked only at figure 1 before speaking; I should have dug deeper :-)
>But, let me then pose a more basic question:  *Why* is the reception 
>of inbound ICMP traffic done outside the IPsec boundary?  IKE is 
>inside the boundary.  Why should ICMP be different?  And what about 
>other protocols destined to the IPsec device itself, such as tcp and 
>ospf?  The figure doesn't show where these are, but I would 
>hope/expect that they are also inside the IPsec boundary.
>
>As far as applying other restrictions such as min PMTU size, agreed 
>that such checks cannot be expressed via the SPD.  But that doesn't 
>mean they can't be checked "behind" (after, inside) the SPD.


I placed the processing for unauthenticated ICMP traffic directed to 
the IPsec device on the unprotected side of the boundary because it 
seemed like the right thing to do, based on having implemented high 
assurance systems this way for the last 25 years :-)  It could be 
moved to the other side of the boundary, but the sorts of checks that 
one will perform are not the sort that we can describe in the SPD, so 
bypassing this traffic doesn't accomplish anything useful. Also, the 
effects are often local to the unprotected side of the IPsec 
implementation. So, if one were to perform the processing on the 
protected side, then we would have to signal over to the unprotected 
side to effect changes, etc. Also, the ICMP module on the unprotected 
side deals with all ICMP traffic, not just error messages, so things 
like ICMP ECHO processing are done there. It just seems to be 
appropriate to localize the processing there, for this traffic.


	<SNIP>
>ok.  perhaps the text can be clarified.
>
>I guess it should clarify that:
>
>  -- the statement "a compliant IPsec implementation MUST permit a 
>local administrator to configure an IPsec implementation to accept 
>or reject unauthenticated ICMP traffic" refers only to ICMP 
>addressed to the implementation itself (the SPD is already 
>sufficient to handle this for transit bypassed ICMP).
>
>  -- the extra "SHOULD" checks (like min PMTU) apply only to ICMP 
>addressed to the implementation itself.
>
>Are those in line with your intent?

yes. we can clarify the text.

	<SNIP>

>>My revised text makes the ability to do this a MUST, but also 
>>recognizes that one can choose to configure the SPD so that this 
>>will not happen.
>
>But, I don't think it should really let them choose in that manner. 
>In fact the rest of the text doesn't say 'let them choose', it says 
>essentially 'always do the icmp payload check when forwarding icmp 
>error messages on an SA where they don't match the selectors, but 
>never check the icmp payload when forwarding the error messages on 
>an SA where the ICMP packets do match the selectors'.

yes, that was my intent. The idea is that if you want to let the ICMP 
traffic go through without the payload checks, then you configure the 
SPD to allow it to pass under the normal checking procedure.  If you 
want to impose the checks, then don't create SPD entries that allow 
the ICMP error traffic to pass, and that will force the checks.

>I think the source of the confusion here, for me anyway, is that the 
>2nd paragraph in 6.2 ("Both the payload...") describes the possible 
>attack and then makes some requirements for checking the icmp 
>payload (such as your reworded text above) but then the following 
>paragraphs (correctly I believe) call for doing this check only in 
>the case where the ICMP packets are forwarded on an SA where they 
>don't match the selectors.  I'd recommend that 6.2 include something 
>like:
>
>     For ICMP messages sent on an SA with selectors that match the 
>ICMP packet itself, an IPsec implementation MUST NOT verify the ICMP 
>Payload information.
>
>     For ICMP messages sent on an SA with selectors that do not match 
>the ICMP packet, an IPsec implementation MUST be configurable to 
>verify that the ICMP payload information is consistent with packets 
>that would be sent on the SA pair on which the ICMP message was 
>received.
>
>Or better yet, omit all that and just move all discussion about 
>checking the ICMP payload to inside the description of the case 
>where ICMP messages are sent on an SA with selectors that do not 
>match the ICMP packet.

The configuration choice re payload checking does not apply when the 
error packets don't match the SA selectors. It occurs when the SPD 
entry is created to accommodate or not accommodate ICMP error packets 
explicitly. So the text above is not what I hand in mind. However, if 
the WG wants this additional level of configuration, we could change 
the text.


	<SNIP>
>>My rationale was that since we are talking about ICMP error 
>>messages, they should never cause an SA to be created, because they 
>>should be sent only in response to receipt of a packet that arrived 
>>over an SA, causing the error in question. Hence I did mean that we 
>>should never create an SA to carry these messages.
>
>I can understand the motivation, but suppose you have an SPD like this:
>
>     1. SA=a, DA=b, protocol=tcp, SP=*, DP=*   --> protect
>     2. SA=a, DA=b, protocol=icmp, type=*, code=*   --> protect
>
>or even like this:
>
>     1. SA=a, DA=b, protocol=tcp, SP=*, DP=*   --> protect
>     2. SA=a, DA=b, protocol=*   --> protect
>
>Then a tcp session starts up and an SA is opened under rule #1. 
>Then an ICMP is generated for a tcp packet in that session.  As 
>written, the text would not permit an SA to be opened under rule #2 
>to forward that ICMP.  This seems wrong to me, unless we have a rule 
>in IPsec that says "never open a new SA for an IPsec error message".
>
>I do agree that if the SPD contains only rule #1, a new SA under 
>rule #1 should not be opened merely to forward an ICMP error message.

I see your point. I'll change the text to say that Iits OK to create 
an SA to carry an ICMP error message IF there is an SPD entry that 
matches the ICMP header. This means that such messages will be 
transmitted over extant SAs based on payload header matching ONLY if 
there is no SPD entry that would otherwise accommodate transmission 
of ICMP error traffic.

Steve

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec