Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages

[Karen Seo <kseo@bbn.com>]

Hi Mark,

>I understand how, as you describe, this processing of icmp error 
>messages might protect against certain DOS attacks.  But it seems to 
>me to be overzealous in your approach #2.
>
>In your approach #1 the icmp error message is being sent on an SA 
>pair implied by the enclosed packet in the icmp payload.  In that 
>case I think it makes perfect sense for both IPsec devices to 
>evaluate the SPD policy for that enclosed packet.
>
>But in #2 the icmp error message is being sent on an SA negotiated 
>for protocol=icmp, type=<mumble> and code=<mumble>.  It seems to me 
>to be an impropriety for the IPsec implementation to check the 
>enclosed packet.  This would be checking that goes beyond the 
>negotiated selectors -- AFAIK there is no other comparable thing 
>done elsewhere in IPsec.

	Hmmm...  ICMP messages can more directly cause problems
	than regular data traffic.  They could be used to
	redirect traffic, change the PMTU, etc.  So it seemed
	to us that additional checking was warranted.

>   Should an IPsec implementation also check for invalid combinations 
>of control bits in a tcp header?  Or for packets with src addr == 
>dest addr?  These are also checks that could protect against attacks 
>but they oughtn't IMO to be part of the *IPsec* processing.

	I think I understand what you're saying but verifying that
	the packet enclosed in an ICMP message could have legitimately
	come from an entity behind the local IPsec implementation seems
	appropriate given the risks.  I would like to at least leave
	this check in as a note with a MAY.  What do you think?  Do
	you want this check removed entirely?

>P.S. Comments on the wording:
>  -  Regardless of what behavior is chosen, it would be better if the 
>text does not describe a fast path and a slow path, and what is done 
>in each.  I don't think there is anything gained by including such 
>implementation assumptions.

	OK.  Will do.

>  -  The phrase "to ensure that the enclosed packet is consistent 
>with its source" could use some elaboration.

	Good point.  Consistent --> the selector fields in the enclosed
	packet match the selector fields for an existing SA.

Karen

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