Hi all
Thanks for all the comments, from my understanding of this thread the
following list of items *seem* to have rough consensus (all except B -
change definitions for EID and RLOC).
Joel, Luigi->How should we proceed now?
Albert
---
A.- Remove definitions of PA and PI
C.- In section 5.3, change the description of the encap/decap
operation concerning how to deal with ECN and DSCP bits to (new
text needs to be validated by experts):
When doing ITR/PITR encapsulation:
o The outer-header 'Time to Live' field (or 'Hop Limit'
field, in the case of IPv6) SHOULD be copied from the
inner-header 'Time to Live' field.
o The outer-header 'Differentiated Services Code Point'
(DSCP) field (or the 'Traffic Class' field, in the case of
IPv6) SHOULD be copied from the inner-header DSCP field
('Traffic Class' field, in the case of IPv6) considering the
exception listed below.
o The 'Explicit Congestion Notification' (ECN) field (bits 6
and 7 of the IPv6 'Traffic Class' field) requires special
treatment in order to avoid discarding indications of
congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit
'ECN' field from the inner header to the outer header.
Re-encapsulation MUST copy the 2-bit 'ECN' field from the
stripped outer header to the new outer header.
When doing ETR/PETR decapsulation:
o The inner-header 'Time to Live' field (or 'Hop Limit'
field, in the case of IPv6) SHOULD be copied from the
outer-header 'Time to Live' field, when the Time to Live value
of the outer header is less than the Time to Live value of the
inner header. Failing to perform this check can cause the
Time to Live of the inner header to increment across
encapsulation/decapsulation cycles. This check is also
performed when doing initial encapsulation, when a packet
comes to an ITR or PITR destined for a LISP site.
o The inner-header 'Differentiated Services Code Point'
(DSCP) field (or the 'Traffic Class' field, in the case of
IPv6) SHOULD be copied from the outer-header DSCP field
('Traffic Class' field, in the case of IPv6) considering the
exception listed below.
o The 'Explicit Congestion Notification' (ECN) field (bits 6
and 7 of the IPv6 'Traffic Class' field) requires special
treatment in order to avoid discarding indications of
congestion [RFC3168]. If the 'ECN' field contains a congestion
indication codepoint (the value is '11', the Congestion
Experienced (CE) codepoint), then ETR decapsulation MUST copy
the 2-bit 'ECN' field from the stripped outer header to the
surviving inner header that is used to forward the packet
beyond the ETR. These requirements preserve CE indications
when a packet that uses ECN traverses a LISP tunnel and
becomes marked with a CE indication due to congestion between
the tunnel endpoints.
Note that if an ETR/PETR is also an ITR/PITR and chooses to
re-encapsulate after decapsulating, the net effect of this is
that the new outer header will carry the same Time to Live as
the old outer header minus 1.
Copying the Time to Live (TTL) serves two purposes: first, it
preserves the distance the host intended the packet to travel;
second, and more importantly, it provides for suppression of
looping packets in the event there is a loop of concatenated
tunnels due to misconfiguration. See Section 18.3 for TTL
exception handling for traceroute packets.
D.- Simplify section ‘Router Locator Selection’ stating that the
data-plane MUST follow what´s stored in the map-cache (priorities
and weights), the remaining text should go to an OAM document.
E.- Rewrite Section “Routing Locator Reachability” considering the
following changes:
* Keep bullet point 1 (examine LSB), 6 (receiving a
data-packet) and Echo-Nonce
* Move to 6833bis bullet point 2 (ICMP Network/Host
Unreachable),3 (hints from BGP),4 (ICMP Port Unreachable),5
(receive a Map-Reply as a response) and RLOC probing
F.- Move Solicit-Map-Request to 6833bis
G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
Considerations), 18 (Traceroute Consideration) to a new OAM document
On Fri, Jan 26, 2018 at 8:20 PM, Dino Farinacci <[email protected]
<mailto:[email protected]>> wrote:
Thanks for the detail review Padma. A new update to -09 is
enclosed with a diff file. I will wait until next week to post.
I have reflected all of your comments and most of Luigi’s
comments. The only issues open are:
(1) Section movement from RFC6830 to RFC6833.
(2) If an OAM document is needed.
Waiting for more working group concensus on this.
> Dear Dino and Albert
>
> The doc reads well.
> Please find thereafter some comments on the version- 09 you posted on the
list
>
> Page 4
> "Client-side: Client-side is a term used in this document to indicate a
connection initiation attempt by an EID."
> PPE 1: Strictly speaking the EID is just an identifier and does not
initiate anything. Suggest something like this.
>
> "Client-side: Client-side is a term used in this document to
indicate a connection initiation attempt by the end system
(represented by an EID)”
Fixed. Put in your suggestion.
> Page 6
> The source EID is obtained via existing mechanisms used to set a host's
"local" IP address. An EID used on the public Internet must have the same
properties as any other IP address used in that manner; this means, among other things, that
it must be globally unique.
>
> PPE 2: Shouldn't these two be MUST rather than must? Suggestion below
>
> The source EID is obtained via existing mechanisms used to set a host's
"local" IP address. An EID used on the public Internet MUST have the same
properties as any other IP address used in that manner; this means, among other things, that
it MUST be globally unique.
Changed.
> Page 8
> An EID maps to one or more RLOCs.
> PPE 3: Seems to contradict earlier explanation on negative mapping entry
where it is possible that an EID has NO RLOC.
I changed to “zero or more RLOCs.”.
> Page 8
> When using multiple mapping database systems, care must be taken to not
create re-encapsulation loops through misconfiguration.
>
> PPE 4: Suggest to add "re-encapsulation" in the list in Security
Considerations section as this is an exploit possibility.
I have removed the sentence. Because it actually is not true. If
you use different mapping systems and circuitious forwarding
occurs. The packet travels only until its TTL reaches 0. Using the
rules for copy inner to outer and outer to inner during RTR
re-encapsulation applies.
> Page 13
> "gleaned" mapping
>
> PPE 5: Suggest adding “glean mapping” in the definition section.
Changed.
> Page 17
> "The KK-bits are a 2-bit field used when encapsualted packets are
encrypted."
>
> PPE 6: Nit - Typo "encapsualted" -> “encapsulated"
Fixed.
>
> Page 20
> "When the lookup succeeds, the locator-set retrieved from the map-cache is
used to send the packet to the EID's topological location."
>
> PPE 7: Nit - Suggest capitalize L and S of "locator-set" for consistency
with rest of document.
Thanks. Done.
>
> Page 23
> "The server-side sets a Weight of 0..."
> PPE 8: Nit - For consistency in text change to "Weight of zero”.
Changed.
> Page 23
> "Control is shared by the server- side determining the list and the client
determining load distribution."
>
> PPE 9: Suggest use of "Client-side"
>
> "Control is shared by the server- side determining the list and
the client-side determining load distribution.”
Done.
> Page 24
> When a verified Map-Cache entry is stored, data gleaning no longer occurs
for subsequent packets that have a source EID that matches
> the EID-Prefix of the verified entry.[PE1] This "gleaning" mechanism is
OPTIONAL.
>
> PPE 10: In section 16.2 later gleaning is used as a solution. Changes in
the gleaned info could be an interesting way to update the cache fast …however
this text make it sound that this is not an option after first packet.
It is an option when the ETR has no mapping to return packets.
Once a mapping is cache, there is no point to glean since the
mapping system verified the information the same as in the map-cache.
>
> Page 25
> "Note that trusting ICMP messages may not be desirable, but neither is
ignoring them completely. Implementations are encouraged to follow current best practices in
treating these conditions."
>
> PPE 11: A reference would be useful if possible.
Added draft-ietf-opsec-icmp-filtering.
> Page 25
> "An ITR that participates in the global routing system can determine that an
RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP
address."
>
> PPE 12: Isn't this true for any protocol entry not just a BGP entry? We
are really trying to determine if there is no route whatever the protocol.
Yes, we can generalize this. I changed text.
> Page 38
> "For a more detailed networkd design deployment recommendation, refer to
[RFC7215]."
>
> PPE 13: Nit typo "netword"-> “network"
Changed.
> Page 40
> "By having the PE be the first router on the path to encapsulate, it can
choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for a new
encapsuluation path to the destination end site."
>
> PPE 14: Nit Typo "encapsuluation" -> “encapsulation"
Changed.
> Page 43
> "If the attacker spoofs the source RLOC, it can mount a DoS attack by
redirecting traffic to the spoofed victim;s RLOC, potentially overloading it."
>
> PPE 15: Nit typo "victim;s" -> “victim’s”
Changed.
Dino
