[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