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 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]>> 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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
