Thanks for the response, no worries on the slow follow-up. I have cut out some email text.
>>> >> >> The control-plane does’t try to send MTU size packets. It depends on IP >> fragmentation/reassembly. But an implementation should know it cannot build >> a LISP message larger than 65535 bytes. > > I’m not convinced relying on IP fragmentation is a good idea. In the best > case, loss of a fragment results in loss of the entire packet, multiplying > the effective loss rate. There can also be middleboxes that drop fragments. > It would be better if the control place could fragment to MTU size packets > (either the actual MTU, or a typical MTU – 1280 octets perhaps). Well an implementation can certainly build messages of effective MTU length which in most cases is 1280/1500 as well. > >>> The draft does not mention congestion control, but many of the messages are >>> rate limited. If the intent of the rate limits is that no further congestion >>> control is needed, then it needs to be made explicit that this is the case, >>> and >> >> Yes, that is the intent. >> >>> some justification needs to be added to explain why it is safe. This could, >>> perhaps, take the form of an appendix that analyses the expected control >>> plane >>> traffic that will flow over a particular path when the protocol is in use, >>> and >>> demonstrates that this will be low enough rate not to be problematic. In any >>> case, the draft needs some discussion of how congestion control is >>> addressed. >> >> The flow-control is coupled with protecting caches as well as request and >> register load on map-resolvers and map-servers. > > Sure, but as I mentioned, the draft needs some justification for why this is > safe from a congestion control viewpoint. Can you suggest some simple text that would be sufficient. We have done the analysis in other drafts. Would simply pointing a reference to them be sufficient you think? > >>> It’s unclear what messages need to be retransmitted if they’re lost, and >>> how to >>> determine if a message is lost (e.g., what is the timeout) and what is the >>> retransmission schedule. This may be clear to a reader with an in-depth >>> understanding of LISP, but it would be helpful to provide more explicit >>> statements about loss detection and retransmission. >> >> Map-Registers are sent periodically but the text says that if Map-Notify >> messages are desired for acknowledgement, the Map-Registers can be >> transmitted more quickly in the case of loss. >> >> Map-Notify messages are obviously acknowledgement by Map-Notify-Ack. That >> was an added message to RFC6833bis. >> >> Map-Requests and Map-Replies are reliability sent for cache population. And >> the nonce is used for both security purproses and to associated a Map-Reply >> to a previous sent Map-Request, which is rate-limited. >> >> That is pretty much it and I think is explained in pretty much detail. So if >> you have any specific comments, please provide them. Thanks. > > I perhaps missed it, but didn’t see any discussion of timeouts to detect > loss, retransmission frequency, how often retransmissions should be retried > before giving up, and what might happen if the retransmissions fail. It’s not > sufficient to just say a response is retransmitted, without saying how loss > is detected and how retransmissions work. > >>> Many of these issues could perhaps be addressed by running the control plane >>> over TCP rather than UDP, as is beginning to happen with the DNS. I >>> understand >>> that this would be a significant late change to the protocol. >> >> We have a draft that is considering running the LISP control-plane over >> TCP/QUIC with the addition of encryped security TLS/QUIC. But not as a >> replacement to UDP but so an LISP control-plane implementation cam be >> simplfied. > > I’d encourage this work, with the goal of eventually replacing the UDP-based > transport. Fabio and Marc have been working on it. A draft expired, so I don’t know their status. I agree with you. > >>> The control plane messages contain embedded IP addresses. Does this cause >>> any >>> issues in the presence of NAT boxes, either by leaking information about >>> private addressing or by distributing addresses that are unreachable outside >>> their realm? I noticed there is a mention of an individual draft on LISP NAT >>> Traversal in Section 5.6, but the embedded addresses are included in more >>> places. >> >> We want private addresses to be inside of LISP control-plane packet payload >> because there are cases where two xTRs want to determine if they are behind >> the same NAT, so they can encapsulate directly to each other with those >> private addresses. For xTRs that are not behind this common NAT, >> RLOC-probing will tell them they cannot reach the private address. > > That’s fine, there should be some discussion of the privacy implications of > exposing those addresses. The WebRTC community has run into considerable > issues due to leaking IP addressing information – perhaps this is not a > concern for LISP, but the issue should be considered, if only to add a note > explaining why it’s not a concern. This only happens in the NAT-traversal cases. I think it should go in the Security Consideration section of that draft. Not this draft. The standardization effort at this point in time is not including NAT-traversal mechanisms because that draft has not been accepted as a working group draft yet. > Is there a need to protect the addresses? STUN uses XOR-mapping of embedded > IP addresses, because NATs were found that tried to translate embedded IP > addresses, outside of the IP header, and broke the protocol. Does LISP need > something similar? No it doesn’t but as we evolved the NAT-traversal draft, we will consider this. Thanks for the heads-up. Thanks again, Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
