Subject: [secdir] secdir review of draft-ietf-lisp-gpe

From: Christopher Wood <[email-masked]>
Date: Sun, 9 Sep 2018 11:26:18 -0700

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

   The summary of my review is: Ready with issues.

The proposed extension mechanism is simple to understand. However, my
main concern is regarding the nonce size reduction and implications on
LISP. While the threat models (on-path and off-path) do not change
with this extension, the probability of some off-path attacks might
change. Specifically, the probability of correctly guessing a 16 bit
nonce is not negligible. This might make attacks in which an adversary
tries to convince an ITR of reachability to an otherwise unreachable
ETR more likely. From [1], an ITR that sees the nonce echoed correctly
“knows that the path to and from the ETR is up.” Thus, I think some
discussion of this is necessary in the security considerations.

Beyond that, I have the following minor comments and nits:

- UDP checksums seem to be the only mechanism in place that give ITRs
and ETRs a means of checking datagram integrity. Of course, this means
an on-path adversary can muck with the g-Bit from Section 4.1 so as to
prevent use of the GPE mechanism. This is not new with this extension,
though a comment on the issue might be useful, e.g., in the security
considerations.
- It would be helpful to include packet diagrams similar to Figure 2
wherein (1) P and V are set and (2) only P is set. While I don’t find
the text misleading or confusing, a figure might help other readers.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |N|L|E|1|I|1|K|K|   Source MV   |    Dest MV    | Next Protocol |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Instance ID/Locator-Status-Bits               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|L|0|0|I|1|K|K|           ... 0 ...           | Next Protocol |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Instance ID/Locator-Status-Bits               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- In Section 4, where it states, "A LISP-GPE router MUST NOT
encapsulate non-IP packets to a non LISP-GPE capable router," I might
replace "to a non LIST-GPE capable router" with "when the P-bit is set
to 0."

[1] https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-16#section-10.1

---

From: Fabio Maino <[email-masked]>
Date: Wed, 12 Sep 2018 17:12:29 -0700

Hi Christopher,
thanks for your review. Please see below how I would like to address 
your comment.

> discussion of this is necessary in the security considerations.

Good point. I'll add the following text to the Security Section, after 
the very first paragraph:

"The Echo Nonce Algorithm described in [I-D.ietf-lisp-rfc6830bis] relies 
on the nonce to detect reachability from ITR to ETR. In LISP-GPE the use 
of a 16-bit nonce, compared with the 24-bit nonce used in LISP, 
increases the probability of an off-path attacker to correctly guess the 
nonce and force the ITR to believe that a non-reachable RLOC is 
reachable. However, the use of common anti-spoofing mechanisms such as 
uRPF prevents this form of attack."

> though a comment on the issue might be useful, e.g., in the security

I will add this paragraph to the security section:

"LISP-GPE, as many encapsulations that use optional extensions, is 
subject to on-path adversaries that by manipulating the g-Bit and the 
packet itself can remove part of the payload. Typical integrity 
protection mechanisms (such as IPsec) SHOULD be used in combination with 
LISP-GPE by those protocol extensions that want to protect from on-path 
attackers."

> the text misleading or confusing, a figure might help other readers.

I'd prefer to use diagrams that are congruent with those used in 
RFC6830bis. I'll defer this comment to the authors of RFC6830bis, and 
follow whatever convention they will decide to follow.

> replace "to a non LIST-GPE capable router" with "when the P-bit is set

I will use the following text:

"A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the 
P-bit set to 1) to a non-LISP-GPE capable router."

Thanks,
Fabio

---

From: Christopher Wood <[email-masked]>
Date: Fri, 14 Sep 2018 06:29:59 -0700

Hi Fabio,

Thanks for the quick response! Your proposed additions address my
concerns. I assume you all will work out what is best for the
diagrams.

Best,
Chris