hi Dino, Almost. How about:
OLD: When the UDP and LISP headers require integrity protection, the methods of using UDP checksums in [RFC8085] can be considered. NEW: Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085]. Specifically, when the UDP, LISP, and outer IPv6 headers require protection against corruption, the use of non-zero UDP checksums is RECOMMENDED. Thanks, cheers, Brian > On 29 Aug 2018, at 20:18, Dino Farinacci <[email protected]> wrote: > > Brian, see the second reference to RFC 8085 in the diff file below. Let me > know if this could satisfy your comment. Thanks. > > Dino > > <rfcdiff.html> > >> On Aug 29, 2018, at 10:17 AM, Dino Farinacci <[email protected]> wrote: >> >>> 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. >> >> This issue has come up at least once or twice every 2 years. We suggest a >> zero checksum no matter what the outer header is because we wanted to be >> practical with respect to what implementations do. No matter what the IETF >> says, the industry has moved forward and not only do not check checksums for >> UDP based tunnels but if they wanted to they can’t because many hardware >> does not have the entire packet buffer in the forwarding engine that does >> header processing. >> >> So I would not want to change our text at this point. We are very aware this >> is controversial but it is emotionally packed as well. UDP packets in all >> probability will not be missed forward because layer-2 chips do a very good >> job at CRC. So if its bit errors one worries about, that is very rare. If it >> is packet corruption due to MITM, that is another story. >> >> We can make a reference to 8085 with respect to checksums but we have to >> craft the text carefully because I really don’t want to release a spec that >> doesn’t reflect reality. So if you can help us craft a couple sentences, we >> can consider putting it in. >> >>> >>> 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 >> >> They cannot if the inner header is encrypted. The EIDs will be obfuscated. >> All that is known is that one location is sending to another location and >> not who is sending to who. >> >>> 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 >> >> For this context, the key-id field in the LISP header is the only precious >> entity. All other bits could be MITM attacked and the ETR could verify if >> the settings are real or not (at some expense). If the key-id field is >> changed, then the ETR will get decryption or ICV errors and drop packets. >> Yes, I know that is a DoS. >> >> To resolve this, I’d be willing to refer to 8085 and use checksum when users >> believe they need to protect the UDP and LISP headers. >> >> What do you think? >> >>> 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, >> >> What do you think of my suggestion? >> >> Dino >> >> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
