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

[Fabio Maino <[e-mail]>]

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

On 9/9/18 11:26 AM, Christopher Wood wrote:
> 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.

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."

>
> 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.

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."


> - 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               |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

>
> - 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."

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


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