Still more parts in my review. I have now read until the beginning of Section
6.3.1. Some of these comments may change as I have read to the end of the
document.
Technical:
When an ETR is misconfigured or compromised, it could return coarse
EID-prefixes in Map-Reply messages it sends. The EID-prefix could
cover EID-prefixes which are allocated to other sites redirecting
their traffic to the locators of the compromised site.
To solve this problem, there are two basic solutions that could be
used. The first is to have Map-Servers proxy-map-reply on behalf of
ETRs so their registered EID-prefixes are the ones returned in Map-
Replies. Since the interaction between an ETR and Map-Server is
secured with shared-keys, it is more difficult for an ETR to
misbehave. The second solution is to have ITRs and PTRs cache EID-
prefixes with mask-lengths that are greater than or equal to a
configured prefix length. This limits the damage to a specific width
of any EID-prefix advertised, but needs to be coordinated with the
allocation of site prefixes. These solutions can be used
independently or at the same time.
At the time of this writing, other approaches are being considered
and researched.
There are obvious remaining issues with these solutions. Map-Servers may also
be compromised, it is not clear that site prefix allocations have all equal
size, ETRs may still return prefixes for someone else, etc. Have these been
described in the security considerations section?
S: This is the Security bit. When set to 1 the field following the
Reserved field will have the following format. The detailed
format of the Authentication Data Content is for further study.
For further study, as in not defined by any of the LISP documents currently being published? It
might be more appropriate to say "This contents of this field are reserved for future use and
no current authentication data formats are defined." And the implications should be described
somewhere in security considerations section or the overall list of issues that need further work.
(Or if this is actually defined somewhere, say "The detailed format of the field is described
in [normative reference].")
And why is this definition different from other places where an authentication
data field was included?
2. An ITR may receive an ICMP Network or ICMP Host Unreachable
message for an RLOC it is using. This indicates that the RLOC is
likely down.
There is obviously a need to soften the impact spurious or spoofed ICMP
messages. There is probably a TCP RFC somewhere where you can copy some current
advise wrt. trusting ICMP error messages.
When a bit goes from 1 to 0, the ETR will
refrain from encapsulating packets to an RLOC that is indicated as
down.
Some considerations might be necessary for conflicting information. For
instance, what do you do if you receive a packet from a locator that is claimed
to be down by another ITR?
Also, I do not fully understand what happens when you include the map version
numbers in a LISP packet (V=1) and no nonce. Can off-the path attackers spoof a
packet that claims to come from an ITR and which changes the locator status
bits? That would open an ETR up for believe anyone in the Internet. Or am I
missing something?
Editorial:
10.0.0.0/8
10.1.0.0/16
10.1.1.0/24
10.1.2.0/24
A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
count of 1 to be returned with a mapping record EID-prefix of
10.1.1.0/24.
This is just a comment, but I would personally use the IPv4 example address
ranges for these sorts of examples, particularly given that both identifiers
and locators are normally globally reachable addresses.
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
