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

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

Karen,

Just one clarification below..
 
> >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.
> 
You mean "the selector fields in the enclosed packet match the selector
fields for an existing SA only if it is found". It is possible (and valid) to have an
SA for protocol = icmp, type,code but not for the enclosed packet.

-mohan

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

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