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

[Christopher Wood <[e-mail]>]

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

On Wed, Sep 12, 2018 at 5:12 PM Fabio Maino <[e-mail]> wrote:
>
> 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
>
>