hi Dino,
> On 28 Aug 2018, at 18:49, Dino Farinacci <farinacci@xxxxxxxxx> wrote:
>
>> I'd suggest inserting a new paragraph after paragraph 2 of section 5, something like:
>>
>>
>> NEW:
>>
>> As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs across the Internet, implementors should be aware of the provisions of [RFC8085], especially those given in section 3.1.11 on congestion control for UDP tunneling.
>
> Consider it added to Section 5 “LISP Encapsulation Details”, last paragraph.
Looks good, thanks!
>> Ah. Okay, so two things:
>>
>> (1) By "integrity protection" I mean "cryptographic integrity protection", in the sense of "preventing on-path attackers or off-path spoofers from being able to influence ITR/ETR state through crafted LISP headers to the detriment of the traffic of others". Looking over 8061, it seems to only cover confidentiality of the data-plane payload, which is extremely useful but not sufficient to prevent these attacks.
>
> Well at this point in the generation of LISP, the only text I think to mitigate LISP header corruption is to indicate that a LISP ITR can use an outer IPsec header if protection of the UDP and LISP headers need protection. Or is that not a strong enough statement?
We're talking past each other here, I think.
There are, as I see it, two completely separate problems here:
(1) The document permits/recommends zero UDP checksum on IPv6 outer packets. This leaves the IPv6 header unprotected against inadvertent corruption. To prevent this, LISP should follow the guidelines in section 3.4.1 of 8085, specifically:
Use of the UDP checksum with IPv6 MUST be the default
configuration for all implementations [RFC6935]. The receiving
endpoint MUST only allow the use of UDP zero-checksum mode for
IPv6 on a UDP destination port that is specifically enabled.
and
A UDP application MUST check that the source and destination IPv6
addresses are valid for any packets with a UDP zero-checksum and
MUST discard any packet for which this check fails. To protect
from misdelivery, new encapsulation designs SHOULD include an
integrity check at the transport layer that includes at least the
IPv6 header, the UDP header and the shim header for the
encapsulation, if any [RFC6936].
See also Magnus' tsvart review on lisp-gpe; his issue A is basically the same problem.
None of this, however, defends against the second problem:
(2) Any on-path attacker, or any off-path attacker who knows the addresses of the xTRs, can guess the current state of mappings, and can spoof packets from one of them, can send packets with valid LISP headers (and, indeed, valid checksums if they so choose) which will change xTR state in ways which can lead to denial of service conditions. A cryptographic integrity check over the LISP header would prevent the on-path attacks. I *think* the nonce echo functionality can be used to prevent off path attacks, or at least allows an endpoint that suspects it is under attack to challenge
Indeed, the security considerations section (and 7835 on which it is based) acknowledges most of this, and it seems that work is ongoing to fix this (draft-ietf-lisp-sec-15), so I guess you can simply take my comment on the second problem as encouragement to get lisp-sec done (subject, of course, to the warnings in draft-trammell-optional-security-not).
Cheers,
Brian
>> The attacks seem to be well enumerated in 6830bis, but the lack of a stated mitigation beyond "be careful" seems to suggest that the mitigation is "don't use LISP", which is of course less than desirable. I'm trying to understand whether the deployment scenarios envisioned for LISP make these attacks less likely (for instance, because the ITR/ETR path itself is generally cryptographically protected with its own outer tunnel), or whether this is something that this document (or a future companion to 8061) needs to worry about.
>
> I think so because of 8061.
>
>> (2) Checksums provide what I'd call "corruption protection". On "setting the outer UDP checksum to zero", please be aware that this may have undesirable interactions with IPv6 headers; see also section 3.4 (Checksum Guidelines) of 8085.
>
> If we don’t go IPsec route, we go with the checksum route. What do you think? Meaning, that if LISP header protection is desiriable, use UDP checksums.
>
>> Thanks, cheers,
>>
>> Brian
>
> Thanks for the commentary and discussion,
> Dino
Attachment:
signature.asc
Description: Message signed with OpenPGP
