hi Dino, > On 28 Aug 2018, at 18:49, Dino Farinacci <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
