[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




>>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
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec