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

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Sep 2018 05:16:00 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-lisp-rfc6833bis-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This DISCUSS is somewhat arbitratrily on 6833bis, but many
of the same issues apply to 6830bis.

I concur with Ben's DISCUSS. I do not believe that these documents
have adequate security to advance to Proposed Standard.

I thought it might be helpful for me to lay out my starting
assumptions and threat model and what I think the appropriate standard
is here. That gives us an opportunity to discuss them prior to
getting into the specific security issues I raise below.

SYSTEM ARCHITECTURE
Per offline discussion, I understand that despite some of the
introductory material, LISP is not currently intended to be Internet
scale but rather to run in what seem to be fairly tightly controlled
environments. Thus, I am assuming the following facts about
the system:

- The Mapping Service itself is secure and trusted.  For the purposed
  of this discussion, I'm modelling all the entities in the services
  as one trusted element.

- The ETRs have a preconfigured relationship with the Mapping Service,
  which includes some sort of shared key and an ACL on the Mapping
  Service which tells it which EIDs anm ETR can advertise. How
  this gets established is out of scope of this discussion.

Note that neither of these assumptions would be reasonable in
an Internet scale system, but I'm assuming that the text about
that in these documents will be removed.

Because it's not in the document set before us, nor is it a normative
reference, I am disregarding LISP-SEC and only analyzing the system as
specified in these documents.

THREAT MODEL
I'm assuming the usual RFC 3552 threat model, I.e.,

- All non-Map Server elements in the system (specifically, endpoints
  and the xTRs are potentially malicious).

- Aside from the links between the Map Server elements, the network
  is controlled by the attacker.

Against this background, my expectation is that the attacker
should not be able to affect traffic in any fashion significantly
more effective than tampering with the data plane. For instance,
it's clearly the case that an on-path attacker between two xTRs
can drop all the packets or forward them to some third xTR, but
it should not be able to send a small number of packets which
would then affect the routing of a large number of packets.

I do not expect that the data plane should have better security
than native (non-IPsec) traffic. Given the nature of LISP and
the existence of a mapping system, it seems like it's kind of
a missed opportunity to deploy a credentials system that would
support IPsec-style data plane security, but given that this
isn't a generally safe assumption for IP traffic, and therefore
you need to provide some sort of transport or application security
anyway, I don't think it's the right standard to hold LISP to.

ATTACKS
LISP appears to be vulnerable to a number of routing attacks that
I claim above it should not be subject to. For example:

1. An on-path attacker can forge Map Replys to the ITR,
   thus redirecting traffic.

2. An ETR can perform an "overclaiming" attack in which it
   claims to be responsible for EIDs which it is not actually
   responsible for.

3. An off-path attacker can temporarily reroute traffic by exploiting
   the "gleaning" feature to cache poison an ITR. In addition, the
   "echo noncing" feature does not appear to have a sufficiently strong
   nonce to protect against forgery, and thus turning this into a
   long-term attack

4. An attacker may be able to perform a number of cache invalidation
   and contamination attacks by exploiting the Map-Version and
   Locator-Status bits. This may lead to DoS.

5. An attacker who was at time T responsible for an EID block
   can probably prolong its ability to respond for that block
   even after it is no longer responsible.

6. A number of the components appear to be subject to various replay
   attacks.

I note that many of these attacks are documented in the Security
Considerations for these documents. Also, I doubt this list is
exhaustive. As noted above, I have spent no time on the data plane
protocol.

DEFENSES
When looking at attacks, it's important to determine whether there are
plausible defenses. For most of these, I believe that the answer is
"yes", at varying levels of cost. As noted above, LISP-SEC appears to
be intended to address a number of these issues, so it's possible that
requiring LISP-SEC would go a fair ways towards addressing these
issues. A cursory look at LISP-SEC turns up some somewhat concerning
design choices, so I would have to examine it more closely to give a
real opinion.

I do not believe that LISP-SEC will address the attacks that do not
involve the Mapping Server. For instance, the gleaning
contamination/nonce attacks (3) would not appear to be fixed by
LISP-SEC. However, it's probably possible to fix them by lengthening
the nonce.

With that said, I tend to think that the overall authentication
architecture here would benefit from a rethink. At a high level, the
source of most of these problems is the "non-transferability" of the
mapping information from the Map Server. If the Map Server instead had
an asymmetric key pair which it used to sign mappings, then almost all
of these attacks would not work. Specifically:

- The map server could send signed Map Replys so forgery wouldn't work

- Map Replys from ETRs would be signed, so you couldn't overclaim

- Gleaning attacks would sort of work, but because the probe would
  elicit a Map Reply, you couldn't persist them

- Map Versions could be tied to signed objects, so you couldn't do
  cache invalidation by version. You'd probably need some other
  approach for Locator Status bits.

And so on.

Detailed review below, with some duplication....

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.

S 5.2.
>      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].
>
>      I: This is the xTR-ID bit.  When this bit is set, what is appended to
>         the Map-Request is a 128-bit xTR router-ID.  See LISP PubSub usage
>         procedures in [I-D.ietf-lisp-pubsub] for details.

here too you seem to be creating a normative reference.

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 and 10.2.0.0/16
and someone asks me for 10.0.0.0/8? Also, when you talk about prefix
length, I assume you mean the length fo the mask?

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.

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

S 8.2.
>      authentication data, so prior to sending a Map-Register message, the
>      ETR and Map-Server SHOULD be configured with a shared secret or other
>      relevant authentication information.  A Map-Server's configuration
>      SHOULD also include a list of the EID-Prefixes for which each ETR is
>      authoritative.  Upon receipt of a Map-Register from an ETR, a Map-
>      Server accepts only EID-Prefixes that are configured for that ETR.

How does it know?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 5.
>        \ |           UDP Length          |        UDP Checksum           |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |                                                               |
>          |                         LISP Message                          |
>          |                                                               |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What do these two diagrams correspond to? v4 and v6? This needs
explanation.

S 5.2.
>      Type:   1 (Map-Request)
>
>      A: This is an authoritative bit, which is set to 0 for UDP-based Map-
>         Requests sent by an ITR.  It is set to 1 when an ITR wants the
>         destination site to return the Map-Reply rather than the mapping
>         database system.

I don't understand this sentence, as literally it would say that you
should not return "the mapping database system" but that doesn't make
any sense.

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.

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.

S 5.2.
>
>      Nonce:  This is an 8-octet random value created by the sender of the
>         Map-Request.  This nonce will be returned in the Map-Reply.  The
>         security of the LISP mapping protocol critically depends on the
>         strength of the nonce in the Map-Request message.  The nonce
>         SHOULD be generated by a properly seeded pseudo-random (or strong

This seems like it needs to be a MUST.

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.

S 5.4.
>
>      Nonce:  This is a 24-bit value set in a Data-Probe
>         [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request
>         is echoed in this 'Nonce' field of the Map-Reply.  When a 24-bit
>         value is supplied, it resides in the low-order 64 bits of the
>         'Nonce' field.

Nit: a 64-bit quantity doesn't really have low-order bits if it's not
numeric. Do you mean "rightmost"? Also, what are the other bits.

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?

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

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 29 Sep 2018 09:30:32 -0700

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 <[email-masked]> wrote:
> 

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.

> here too you seem to be creating a normative reference.

LISP-chairs?

> length, I assume you mean the length fo the mask?

Yes, this is explained later in this section. Was that not helpful??

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

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

>>     Server accepts only EID-Prefixes that are configured for that ETR.

It is provisioned by the mapping service provider (MSP). When the LISP site is allocated an EID-prefix, it configures all the xTRs that connect that site. And then the LISP site (the admins at the site), shop for an MSP and tell them what EID-prefixes, they will be registering. That is when the shared-key between the LISP site and MSP is exchanged via a manul out-of-band business process.

> What do these two diagrams correspond to? v4 and v6? This needs

It is th entire IP packet sent as a LISP control-message. The header before the diagrams indicate they are UDP packets.

> should not return "the mapping database system" but that doesn't make

This was already fixed in a later revision. Now says:

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.  It is set to 1 when an ITR wants the
      destination site to return the Map-Reply rather than the mapping
      database system returning a Map-Reply.

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

> Is the xTR supposed to filter this on exiting the site.

Nope.

> This seems like it needs to be a MUST.

Yes, I agree. I cannot remember why we made it a SHOULD.

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

> numeric. Do you mean "rightmost"? Also, what are the other bits.

Really good point. I’ll fix.

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

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

Thanks,
Dino

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Sep 2018 10:05:49 -0700

On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci <[email-masked]> 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.
>
> 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.

> > and someone asks me for 10.0.0.0/8?

I think I'm still unclear on this point.

> Also, when you talk about prefix

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.

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

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

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

> > Is the xTR supposed to filter this on exiting the site.

Won't this cause problems on ingress to another site?

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

> format description section.

OK.

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Sep 2018 13:18:45 -0400

With regard to the m-bit, I would prefer that this document leave the 
bit reserved, 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 <[email-masked] 
> <mailto:[email-masked]>> 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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>     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.
>      > 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>? 
> 
> 
>     Well there are many. The nonce can change for each Map-Register
>     sent. Same for Map-Version number as well as the key-id.
> 
> 
>     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 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.
> 
>     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.
> 
> sentence talks about a Map Server processing a Map Request.  That's 
> where I am confused.
> 
> -Ekr
> 
> 
>     Thanks,
>     Dino
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Sep 2018 10:22:41 -0700

On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern <[email-masked]>
wrote:

> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Sep 2018 13:24:52 -0400

Like any other flag bits that are not assigned, this would be MBZ on 
transmission, must be ignored on reception.  Once assigned, 
implementations that support the assignment would do whatever the 
assigning document says.  Very normal procedure.

Yours,
Joel

On 9/29/18 1:22 PM, Eric Rescorla wrote:
> 
> 
> On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Just trying to think through the interop implications of this. Would it 
> be must be zero and must ignore? something else?
> 
> -Ekr
> 
>      > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >      > On Sep 27, 2018, at 5:16 AM, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>> 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.
>      >
>      >      > 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>
>     <http://10.2.0.0/16>
>      >      > and someone asks me for 10.0.0.0/8 <http://10.0.0.0/8>
>     <http://10.0.0.0/8>?
>      >
>      >
>      >      > length, I assume you mean the length fo the mask?
>      >
>      >      > 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.
>      >
>      >      > 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
>      >
>      >      > S 5.
>      >      >>       \ |           UDP Length          |        UDP
>     Checksum
>      >      >>
>      >      >>         |
>      >      >>         |                         LISP Message
>      >      >>         |
>      >      >>
>      >      >
>      >      > What do these two diagrams correspond to? v4 and v6? This
>     needs
>      >      > explanation.
>      >
>      >      > 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.
>      >
>      >      >
>      >      > 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.
>      >
>      >
>      >      > 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.
>      >
>      >      >
>      >      > 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?
>      >
>      >      > 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.”
>      >

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Sep 2018 10:30:56 -0700

> assigning document says.  Very normal procedure.

OK, I haven't read the -mn- draft so I don't know if that will have a clean
upgrade path.

-Ekr

> >      >      >>     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
> >      >      >>     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
> >      >      > and someone asks me for 10.0.0.0/8 <http://10.0.0.0/8>
> >     <http://10.0.0.0/8>?
> >      >
> >      >
> >      >      >>     Authentication Data:  This is the message digest used
> >     from
> >      >     the output
> >      >      >>        computed, it is placed in this field.
> >     Implementations of
> >      >     this
> >      >      >>        specification MUST include support for
> HMAC-SHA-1-96
> >      >     [RFC2404],
> >      >      >>     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
> >      >      > prefix. The way this attack works is that before the
> topology
> >      >     shift, I
> >      >      >>       \ |           UDP Length          |        UDP
> >      >      >>     P: This is the probe-bit, which indicates that a
> >     Map-Request
> >      >     SHOULD
> >      >      >>        be treated as a Locator reachability probe.  The
> >     receiver
> >      >     SHOULD
> >      >      >>        nonce copied from the Map-Request.  See
> RLOC-Probing
> >      >     Section 7.1
> >      >      >>        for more details.
> >      >      >
> >      >      >>     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.
> >      >      >
> >      >      >>     originating Map-Request source.  If the RLOC is not
> >     in the
> >      >     Locator-
> >      >      >>     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.
> >      >      >
> >      >      >>     Once a Map-Server has EID-Prefixes registered by its
> >     client
> >      >     ETRs, it

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Sep 2018 13:42:02 -0400

This draft explicitly states that the m-bit can be ignored by nodes that 
do not support  the lisp mobile node behavior.  Which seems pretty clear 
that it is nicely separable.

Yours,
Joel

On 9/29/18 1:30 PM, Eric Rescorla wrote:
> 
> 
> On Sat, Sep 29, 2018 at 10:24 AM Joel M. Halpern <[email-masked] 
> OK, I haven't read the -mn- draft so I don't know if that will have a 
> clean upgrade path.
> 
> -Ekr
> 
> 
>     Yours,
>     Joel
> 
>      > On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >      > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> 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
>     <[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> 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>
>      >     <http://10.1.0.0/16>
>      >      >     <http://10.1.0.0/16> and 10.2.0.0/16
>     <http://10.2.0.0/16> <http://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> <http://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
>      >      >
>      >
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Sep 2018 10:42:46 -0700

OK.

-Ekr

> >      >      > <mailto:[email-masked] <mailto:[email-masked]>
> >      >      >     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
> >      >      >      > On Sep 27, 2018, at 5:16 AM, Eric Rescorla
> >      >      >     <mailto:[email-masked] <mailto:[email-masked]>
> >      >      >      > 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.
> >      >      >
> >      >      > Me neither. Seems like it could go either way. My only
> >     interest
> >      >     is that
> >      >      >      >>     than or equal to the EID being requested.  The
> >     EID being
> >      >      >     requested is
> >      >      >      >
> >      >      >     <http://10.1.0.0/16> and 10.2.0.0/16
> >      >      >      > and someone asks me for 10.0.0.0/8
> >      >      >     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:
> >      >      >
> >      >      > I had thought that "prefix length" referred to the former,
> >     but it
> >      >     seems
> >      >      > like here it
> >      >      > refers to the latter.
> >      >      >
> >      >      >
> >      >      >      > S 5.6.
> >      >      >      >>        of the MAC algorithm.  The entire
> Map-Register
> >      >     payload is
> >      >      >      >>        authenticated with this field preset to 0.
> >     After
> >      >     the MAC is
> >      >      >      >>        and support for HMAC-SHA-256-128 [RFC4868]
> is
> >      >     RECOMMENDED.
> >      >      >      >
> >      >      >      > What prevents replay attacks here? I'm guessing
> >     it's the
> >      >     Map-Version-
> >      >      >      >>     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-
> >      >      >      > 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
> >      >      >     authenticated RLOC-set for the mapping. Rate-limiting
> is
> >      >     necessary
> >      >      > I'm probably just confused here: SMRs go through the
> mapping
> >      >     system, not
> >      >      >      >>       \ |           UDP Length          |
> UDP
> >      >      >      > 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
> >      >      >      >>        respond with a Map-Reply with the probe-bit
> >     set,
> >      >      >     indicating that
> >      >      >      >>        the Map-Reply is a Locator reachability
> probe
> >      >     reply, with the
> >      >      >     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
> >      >      >      >>     "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
> >      >      >      > This text here doesn't seem compatible with either
> >     of the
> >      >     two cases
> >      >      >     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.
> >      >      > "   A Map-Reply returns an EID-Prefix with a prefix length
> >     that
> >      >     is less
> >      >      > "   EID-Prefix:  This prefix is 4 octets for an IPv4
> address
> >      >     family and
> >      >      >        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
> >      >      >      >>        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.
> >      >      >      > This section is confusing because the introduction
> says
> >      >     that this
> >      >      >      >   devices: the Map-Resolver, which accepts
> Map-Requests
> >      >     from an
> >      >      >      > Ingress
> >      >      >      >   to-RLOC mappings from an Egress Tunnel Router
> >     (ETR) and
> >      >     publishes
> >      >      >      >   them in a database.”
> >      >      >
> >      >      > Sure: As I understand it, Map Resolvers process Map
> >     Requests, and
> >      >     Map