Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15

["Brian Trammell (IETF)" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>> 
>> 
>