On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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 protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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> and 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>?
>
>
> 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
>
