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

From: Mark Duffy <[email-masked]>
Date: Mon, 03 May 2004 18:32:44 -0400

>>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?

I'll go for the "MAY" if that's the best I can get :-)   If the authors and 
wg think the check should be there, so be it.  But to me it seems inelegant 
that an implementation should be called upon to make these 
somewhat-arbitrary checks beyond the negotiated access control policy.  IMO 
if the SA is negotiated for protocol=icmp, with SA, DA, type, and code 
selectors, that 5-tuple is what should be enforced and no more.

--Mark

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Mark Duffy <[email-masked]>
Date: Mon, 03 May 2004 18:32:44 -0400

--Mark

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 7 May 2004 13:07:16 -0700

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.
> 
> >   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.
> 
> >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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 7 May 2004 13:07:16 -0700

Karen,

-mohan