Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Sat, 29 September 2018 17:23 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DFB130E4A for <lisp@ietfa.amsl.com>; Sat, 29 Sep 2018 10:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f72Rh9YOYjpQ for <lisp@ietfa.amsl.com>; Sat, 29 Sep 2018 10:23:20 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CF3130DCB for <lisp@ietf.org>; Sat, 29 Sep 2018 10:23:19 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id r8-v6so8569199ljc.10 for <lisp@ietf.org>; Sat, 29 Sep 2018 10:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h+orkpAQpgv/TnLCmfsh9S5BIR4g2HfsoKg7lr2QR+k=; b=vb/rpWcEQVFcTIFnJ5Zv/XfTRZmonXptu2saNBWtlo/3EFR/0bpmQ7SQEIJxW/FZnB yZ8EGjDL447+OEzYY1kQkrXKekhGM5jJeErcxdwVtJZBDVJ6yBjkNJoLbq+PjE/XHESP 7n2T6Etd7EUO/2laEF//eYXPlXaurV52vNOENBYWEqAee+tewk++0hJK3cAz33+cIty5 obkVHRNAhX0Tmp6liDYHnvAmRikt9K5DfXhqDnoc0Ic8Mr3U1JbcJ5lnB8pX8jMjr+V1 pHRW56Ff8OFhc5RmuEWTWSrthz+xOr0GYomA0xRsXFlKdi3/NK7J0a1mPnmO/RwJx/Ad LL0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h+orkpAQpgv/TnLCmfsh9S5BIR4g2HfsoKg7lr2QR+k=; b=Aev9pFjm9T7vyHUfHrt39VLKyaFWaTDc6YIubPZaRAY4Q90gcitMk7XbztXLTDw5UH ovptJ5z8LbTDpiDvpQAcMG85R2/FvIxq3We+/AW+XB/TGfCOL0y6NguB91lJxRQ/dnrf SDgmH3UADrG0AGnFPzeNaQZBt5+zyvVABB7p5uaxcIQADlQo2D+MxOj5HKSAroH5GKxs Mgw4W6za2yFxdigvttkFA/5XOuRxpitkDFeZfBQCGhb1Ni/WOR/0gJoo4MROFU+K5EqD rBxb/WshXXH/v2d1W4Kvnk42Ab17UHcLnxSAzfIdI88chq/wyvyFvSpd/hhJ1Zt+bHtW TRCg==
X-Gm-Message-State: ABuFfoh2kIlw964XVOwQUWhQt03QMdlgXy7+fpLtvBHDHUNFeTVB/aNo RtScWF0tHI4FLsiz2mTv1JNEnFCnjo40FVz5g7piZg==
X-Google-Smtp-Source: ACcGV605i3my2uSE5xhUzjoBQSaEwUyRfciHPw4ZuBPvY+wmohaASo4X541bZUAIB4vsHhwvVuAfYT0iD9G7kGWseik=
X-Received: by 2002:a2e:2a43:: with SMTP id q64-v6mr1988761ljq.153.1538241798009; Sat, 29 Sep 2018 10:23:18 -0700 (PDT)
MIME-Version: 1.0
References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> <F1E6357D-0A02-4A2E-B98E-7B34D7AB5EA0@gmail.com> <CABcZeBMbAoo_UUjdhn0vU-cQrH9XQvs6VohBzs7q=BjbVi1BVQ@mail.gmail.com> <be404c1c-08b5-9c4e-015f-4afbb1f18f22@joelhalpern.com>
In-Reply-To: <be404c1c-08b5-9c4e-015f-4afbb1f18f22@joelhalpern.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 29 Sep 2018 10:22:41 -0700
Message-ID: <CABcZeBMDTHTsQE1q7QSDFFJnRp4T3J4yFh5Ee4HNMJ_0Dv+q0Q@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Dino Farinacci <farinacci@gmail.com>, IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f309a7057705d3ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/iqwidEhsbD5_WB6Gqdh0P_EMLJY>
Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Sep 2018 17:23:24 -0000

On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern <jmh@joelhalpern.com>
wrote:

> With regard to the m-bit, I would prefer that this document leave the
> bit reserved,


Just trying to think through the interop implications of this. Would it be
must be zero and must ignore? something else?

-Ekr

and the LISP mobile node document assign the bit fromthe
> registry.  That keeps a clean separation.
>
> Yours,
> Joel
>
> On 9/29/18 1:05 PM, Eric Rescorla wrote:
> >
> >
> > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci <farinacci@gmail.com
> > <mailto:farinacci@gmail.com>> wrote:
> >
> >     Thanks Eric for your great comments. Like I said in previous emails,
> >     I’ll address the simple things here and then handle all the security
> >     related stuff separately next week.
> >
> >     I will do the same with Benjamin’s comments as well. And in his
> >     reply, send a diff with changes that reflect both Eric and
> >     Benjamin’s comments.
> >
> >      > On Sep 27, 2018, at 5:16 AM, Eric Rescorla <ekr@rtfm.com
> >     <mailto:ekr@rtfm.com>> wrote:
> >      >
> >      > Rich version of this review at:
> >      > https://mozphab-ietf.devsvcdev.mozaws.net/D4115
> >      >
> >      >
> >      > IMPORTANT
> >      > S 5.2.
> >      >>     s: This is the SMR-invoked bit.  This bit is set to 1 when
> >     an xTR is
> >      >>        sending a Map-Request in response to a received SMR-based
> >     Map-
> >      >>        Request.
> >      >>
> >      >>     m: This is the LISP mobile-node m-bit.  This bit is set by
> >     xTRs that
> >      >>        operate as a mobile node as defined in [I-D.ietf-lisp-mn].
> >      >
> >      > This would appear to create a normative reference to this
> >     document. To
> >      > avoid that, you need to specify how I behave if I receive it but I
> >      > don't implement lisp-mn.
> >
> >     I am find making it a normative reference but need the lisp-chairs
> >     to comment. I am not sure what the implications of that are.
> >
> >
> > Me neither. Seems like it could go either way. My only interest is that
> > the protocol be unambiguous.
> >
> >
> >
> >      > S 5.5.
> >      >>        is being mapped from a multicast destination EID.
> >      >>
> >      >>  5.5.  EID-to-RLOC UDP Map-Reply Message
> >      >>
> >      >>     A Map-Reply returns an EID-Prefix with a prefix length that
> >     is less
> >      >>     than or equal to the EID being requested.  The EID being
> >     requested is
> >      >
> >      > How do I behave if I receive an EID-Prefix that is less than any
> >     of my
> >      > mappings. So, I might have mappings for 10.1.0.0/16
> >     <http://10.1.0.0/16> and 10.2.0.0/16 <http://10.2.0.0/16>
> >      > and someone asks me for 10.0.0.0/8 <http://10.0.0.0/8>?
> >
> >
> > I think I'm still unclear on this point.
> >
> >     Also, when you talk about prefix
> >      > length, I assume you mean the length fo the mask?
> >
> >     Yes, this is explained later in this section. Was that not helpful??
> >
> >
> > I found it a bit confusing. It seems to me like there are two lengths
> > involved here:
> >
> > - The length of the field (4 or 16)
> > - The parts of the field that are significant (i.e., the mask)
> >
> > I had thought that "prefix length" referred to the former, but it seems
> > like here it
> > refers to the latter.
> >
> >
> >      > S 5.6.
> >      >>     Authentication Data:  This is the message digest used from
> >     the output
> >      >>        of the MAC algorithm.  The entire Map-Register payload is
> >      >>        authenticated with this field preset to 0.  After the MAC
> is
> >      >>        computed, it is placed in this field.  Implementations of
> >     this
> >      >>        specification MUST include support for HMAC-SHA-1-96
> >     [RFC2404],
> >      >>        and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED.
> >      >
> >      > What prevents replay attacks here? I'm guessing it's the
> Map-Version-
> >      > Number, but as I understand it, I can set this to 0.
> >
> >     Well there are many. The nonce can change for each Map-Register
> >     sent. Same for Map-Version number as well as the key-id.
> >
> >
> > I think you need to describe the precise process of replay prevention
> here.
> >
> >      > S 6.1.
> >      >>     receives an SMR-based Map-Request and the source is not in
> the
> >      >>     Locator-Set for the stored Map-Cache entry, then the
> >     responding Map-
> >      >>     Request MUST be sent with an EID destination to the mapping
> >     database
> >      >>     system.  Since the mapping database system is a more secure
> >     way to
> >      >>     reach an authoritative ETR, it will deliver the Map-Request
> >     to the
> >      >>     authoritative source of the mapping data.
> >      >
> >      > If I'm understanding this correctly, this allows an ETR to
> prevent an
> >      > ITR from learning that it is no longer the appropriate ETR for a
> >      > prefix. The way this attack works is that before the topology
> >     shift, I
> >      > send SMRs, thus causing Map-Requests, which, because my entry is
> >      > cached, refresh the cache on the ITR past the topology shift. I
> can
> >      > keep doing this indefinitely. Am I missing something
> >
> >     Well if the ETR is being spoofed, then there is Map-Request load,
> >     but it won’t corrupt the ITR’s map-cache. The ITR always sends a
> >     verifying Map-Request to the mapping system to get the latest and
> >     authenticated RLOC-set for the mapping. Rate-limiting is necessary
> >     so each SMR received DOES NOT result in a Map-Requerst to the
> >     mapping system.
> >
> >
> > I'm probably just confused here: SMRs go through the mapping system, not
> > directly? If so, I agree that this wont' work.
> >
> >
> >      > S 5.
> >      >>       \ |           UDP Length          |        UDP Checksum
> >             |
> >      >>
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      >>         |
> >             |
> >      >>         |                         LISP Message
> >              |
> >      >>         |
> >             |
> >      >>
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      >
> >      > What do these two diagrams correspond to? v4 and v6? This needs
> >      > explanation.
> >
> >     It is th entire IP packet sent as a LISP control-message. The header
> >     before the diagrams indicate they are UDP packets.
> >
> >
> > A caption would probably help.
> >
> >      > S 5.2.
> >      >>     P: This is the probe-bit, which indicates that a Map-Request
> >     SHOULD
> >      >>        be treated as a Locator reachability probe.  The receiver
> >     SHOULD
> >      >>        respond with a Map-Reply with the probe-bit set,
> >     indicating that
> >      >>        the Map-Reply is a Locator reachability probe reply, with
> the
> >      >>        nonce copied from the Map-Request.  See RLOC-Probing
> >     Section 7.1
> >      >>        for more details.
> >      >
> >      > How am I supposed to handle this if I am a Map Server.
> >
> >     It should be ignored. I will add text to reflect this point. Good
> point.
> >
> >      >
> >      > S 5.2.
> >      >>        receipt.
> >      >>
> >      >>     L: This is the local-xtr bit.  It is used by an xTR in a
> >     LISP site to
> >      >>        tell other xTRs in the same site that it is part of the
> >     RLOC-set
> >      >>        for the LISP site.  The L-bit is set to 1 when the RLOC
> >     is the
> >      >>        sender's IP address.
> >      >
> >      > Is the xTR supposed to filter this on exiting the site.
> >
> >     Nope.
> >
> >
> > Won't this cause problems on ingress to another site?
> >
> >      > S 5.3.
> >      >>     originating Map-Request source.  If the RLOC is not in the
> >     Locator-
> >      >>     Set, then the ETR MUST send the "verifying Map-Request" to
> the
> >      >>     "piggybacked" EID.  Doing this forces the "verifying
> >     Map-Request" to
> >      >>     go through the mapping database system to reach the
> >     authoritative
> >      >>     source of information about that EID, guarding against
> >     RLOC-spoofing
> >      >>     in the "piggybacked" mapping data.
> >      >
> >      > This text here doesn't seem compatible with either of the two
> cases
> >      > listed in "EID-prefix" above.
> >
> >     I don’t understand the comment Eric. Maybe because I can’t find the
> >     exact reference to EID-prefix where you think there is a conflict.
> >     Please cite for me. Thanks.
> >
> > This does seem to have been assigned to the wrong text.
> >
> > I am referring to:
> >
> > "   A Map-Reply returns an EID-Prefix with a prefix length that is less
> >     than or equal to the EID being requested.  The EID being requested is
> >     either from the destination field of an IP header of a Data-Probe or
> >     the EID record of a Map-Request.  The RLOCs in the Map-Reply are
> > "
> >
> > versus
> >
> > "   EID-Prefix:  This prefix is 4 octets for an IPv4 address family and
> >        16 octets for an IPv6 address family when the EID-Prefix-AFI is 1
> >        or 2, respectively.  For other AFIs [AFI], the length varies and
> >        for the LCAF AFI the format is defined in [RFC8060].  When a Map-
> > "
> >
> > This is just the question of whether "prefix length" refers to the field
> or
> > the significant bits of the field.
> >
> >
> >
> >
> >      >
> >      > S 5.4.
> >      >>        'Nonce' field.
> >      >>
> >      >>     Record TTL:  This is the time in minutes the recipient of
> >     the Map-
> >      >>        Reply will store the mapping.  If the TTL is 0, the entry
> >     MUST be
> >      >>        removed from the cache immediately.  If the value is
> >     0xffffffff,
> >      >>        the recipient can decide locally how long to store the
> >     mapping.
> >      >
> >      > Am I supposed to merge this with previous mappings? REmove them?
> >
> >     No replace it. There is text that says this that is not in the
> >     packet format description section.
> >
> >
> > OK.
> >
> >
> >      > S 8.3.
> >      >>     of the mapping database protocols.
> >      >>
> >      >>  8.3.  Map-Server Processing
> >      >>
> >      >>     Once a Map-Server has EID-Prefixes registered by its client
> >     ETRs, it
> >      >>     can accept and process Map-Requests for them.
> >      >
> >      > This section is confusing because the introduction says that this
> >      > function is only performed by Map-Resolvers:
> >      > '
> >      > "The LISP Mapping Service defines two new types of LISP-speaking
> >      >   devices: the Map-Resolver, which accepts Map-Requests from an
> >      > Ingress
> >      >   Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping
> using a
> >      >   mapping database; and the Map-Server, which learns authoritative
> >      > EID-
> >      >   to-RLOC mappings from an Egress Tunnel Router (ETR) and
> publishes
> >      >   them in a database.”
> >
> >     The document does cover the operation of a Map-Resolver and a
> >     Map-Server. Some functions are performed only by Map-Resolvers only
> >     and other different functions are performed by Map-Servers only.
> >
> >     I am not sure what you don’t understand.
> >
> >
> > Sure: As I understand it, Map Resolvers process Map Requests, and Map
> > Servers do not (that's what the quoted text seems to say). However, this
> > sentence talks about a Map Server processing a Map Request.  That's
> > where I am confused.
> >
> > -Ekr
> >
> >
> >     Thanks,
> >     Dino
> >
>