On Sat, Sep 29, 2018 at 10:24 AM Joel M. Halpern <[email protected]
<mailto:[email protected]>> wrote:
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.
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 9/29/18 1:22 PM, Eric Rescorla wrote:
>
>
> On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern
<[email protected] <mailto:[email protected]>
> <mailto:[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]>>
> > <mailto:[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]>>
> > <mailto:[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>
> > <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
> >
>
