SAVNET-ProblemStatement-Architecture Inter-domain-SAVNET-Architecture issues

SAVNET-ProblemStatement-Architecture / Inter-domain-SAVNET-Architecture

0 stars 0 forks source link

issues

Newest

Newest Most commented Recently updated Oldest Least commented Least recently updated

42. Comments on the trustworthiness of communicated SAV-specific information

#42 LibinLiu0189 opened 1 week ago
0
41. Comments on the guidance for conducting new potential SAV solutions

#41 LibinLiu0189 opened 1 week ago
1
40. Comments on SAV-specific information and communication mechanism

#40 LibinLiu0189 opened 1 week ago
1
39. Comments on comparisons of different SAV-related information

#39 LibinLiu0189 opened 1 week ago
1
38. Comments on priority recommendations of SAV information sources

#38 LibinLiu0189 opened 1 week ago
0
37. Aijun: In the architecture document, we should only provide some requirements for the solution to cover more specific scenarios in one general manner. (After IETF 120)

#37 LibinLiu0189 opened 1 week ago
0
36. Aijun: Suggest the following revisions to make the descriptions understood more easily (Aijun): SAVNET operation /s SAVNET performance analysis, Inter-domain SAVNET provisioning /s Inter-domain SAVNET deployment provisioning, and explain them with detailed illustrations. (After IETF 120)

#36 LibinLiu0189 opened 1 week ago
0
35. Aijun: There are proposals to use the controllers, but there is no such descriptions within the current architecture document. Should we consider to add the controller component within the architecture document? Then we can encompass all the possible solution together. (After IETF 120)

#35 LibinLiu0189 opened 1 week ago
0
34. Alvaro: A neighbor discovery mechanism that is independent of existing protocols might be a non-starter in an inter-domain scenario...specially in cases where others may glean the information (IXPs, for example).

#34 LibinLiu0189 opened 5 months ago
0
33. Alvaro: Using "effortlessly" to describe a technical outcome is not ideal: the amount of effort is relative to the operator's abilities, experience, the protocol, etc.

#33 LibinLiu0189 opened 5 months ago
0
32. Alvaro: What does it mean to "ensure support for partial/incremental deployment"? I'm sure it doesn't mean that all the functions have to be supported (as we discussed above), so you might want to s/.../solution should consider partial/incremental deployments...

#32 LibinLiu0189 opened 5 months ago
0
31. Alvaro: Assuming the cases above, how would AS1 become aware of a failure, for example, in the connectivity between the AS parallel to AS2 and ASX? It needs this information to update its SAV-specific messages.

#31 LibinLiu0189 opened 5 months ago
0
30. Alvaro: As you well know, the operator can manually override the BGP decision. It is also possible to install a static route (which has no path information) pointing towards AS2. In this case, the path information could still be derived from BGP. You don't need a solution (yet) -- for this document all you need is to recognize that some cases may not work as expected until a wider deployment is achieved.

#30 LibinLiu0189 opened 5 months ago
0
29. Alvaro: Figure 9 in Section 7.1 shows SAV-specific messages ("(P1, AS 2), (P6, AS 2)") that indicate <Prefix, Incoming Direction>. For the sample topology, how does AS1 know that AS2 will be the incoming direction from ASX's point of view? In the simple topology, it is relatively straight forward and AS2 is connected to both AS1 and ASX. But in more complex topologies it is not as easy; for example, consider another AS between AS1 and AS2, or between AS2 and ASX -- neither implementing the SAV mechanisms.

#29 LibinLiu0189 opened 6 months ago
1
28. Olaf: Forwarding and processing packets correctly is the basic task of a device. If the mechanism is just copied from there to here, then perhaps it doesn’t need to state more about the consequence that the mechanism will cause on the network. The new architecture introduced in this draft also cloud not meet the requirements ultimately concluded in draft “draft-ietf-savnet-inter-domain-problem-statement-04”.

#28 LibinLiu0189 opened 6 months ago
0
27. Ben: Follow up the concern raised by Kaye. I don't think that we have a way of solving that using outbound signaling. We need source signing in band in packet header. [during ietf119]

#27 LibinLiu0189 opened 6 months ago
0
26. Keyur: Does this cover a man-in-the-middle attack who can generate a prefix inside BGP With the right AS origin, but can hijack the path? I can take it to the mailing list for discussion. [during ietf119]

#26 LibinLiu0189 opened 6 months ago
0
25. Ben: Raise the same issue again. It uses RPKI based objects which is similar but not the same. That doesn't exist today. If this is deployed, it will jeopardize the use of RPKI in routing security. This is a big problem but not addressed. We need new signed objects. I'm happy to help but no one proposes it. [during ietf119]

#25 LibinLiu0189 opened 6 months ago
0
24. Aijun Wang: We need a component on the receiver to validate the received SAV-specific information. [during ietf 118]

#24 LibinLiu0189 opened 11 months ago
0
23. Joel Halpern: A suggestion, not refer MD5. [during ietf 118]

#23 LibinLiu0189 opened 11 months ago
0
22. Antoin Verschuren: How you can trust the ASes which send you information. [during ietf 118]

#22 LibinLiu0189 opened 11 months ago
0
21. Yangyang Wang: As I understood, the SAV-specific messages are used to propagate the next incoming hops along real forwarding paths. In Section 4.2, in the statement "The SAV-specific message processor also checks the destination addresses of the SAV-specific messages...". What are the destination addresses of SAV-specific messages. Are they the destination addresses included in the SAV-specific messages, or the destination addresses of the IP headers of the SAV-specific messages? If they are the destination addresses included in the SAV-specific messages, are these destination addresses expressed in the form of prefixes? And, how to generate the original destination addresses (or destination prefixes) in SAV-specific messages. [after ieft 117]

#21 LibinLiu0189 opened 1 year ago
0
20. Yangyang Wang: It is not clear which ASes deploy SAV-specific protocol in Figure 3. [after ieft 117]

#20 LibinLiu0189 opened 1 year ago
0
19. Yuanyuan Zhang: Section “4.1 SAV Information Base” says “SAV at the interface Itf.2 permits P1 and P2 according to the rows with indexes 1 and 2 in the SIB, SAV at the interface Itf.3 permits P6 according to the row with index 5 in the SIB”. Does it mean P6 is blocked by Itf.2, and P1 is blocked by Itf.3? If so, this could result in SAV false positives. [after ieft 117]

#19 LibinLiu0189 opened 1 year ago
0
18. Yuanyuan Zhang: Additionally, I think by using SAV-specific information, AS4 should learn that both Itf.2 and Itf.3 are legal incoming interfaces for P1 and P6. Should “SAV-specific information” also be included in the column of “SAV Information Source” for the row with index 3 and 4? [after ieft 117]

#18 LibinLiu0189 opened 1 year ago
0
17. Yuanyuan Zhang: In figure 4, the row with index 5 indicates prefix P6's valid incoming interface is Itf.3, and the information is from both SAV-specific information and general information. I think AS 4 can’t get route “P6[AS 1]” from Itf.3 because of NO_EXPORT. Is the general information here an error? [after ieft 117]

#17 LibinLiu0189 opened 1 year ago
0
16. Yuanyuan Zhang: In section “4.1 SAV Information Base”, the priorities for “RPKI ROA Obj. and ASPA Obj.”, “RIB” and “FIB” are 2, 3, 4 respectively. The reason behind this is not clarified. Some explanation here would be helpful. [after ieft 117]

#16 LibinLiu0189 opened 1 year ago
0
15. Yuanyuan Zhang: If general information like RIB/FIB is used to generate the SAV Information Base, considering the large size of the inter-domain RIB/FIB (nearing 1 million entries for FIB and much more for RIB), the SAV Information Base might be significantly larger due to its multiple information sources. Would it be a heavy burden for the router? [after ieft 117]

#15 LibinLiu0189 opened 1 year ago
0
14. Yuanyuan Zhang: “SAV-specific Message Processor” mentioned in Section 4.2 seems to be important in handling SAV-specific messages, should it be included in Figure 1 “the inter-domain SAVNET architecture”? Furthermore, how is general information transformed into the SAV Information Base? Is there an equivalent mechanism like “general message processor”? [after ieft 117]

#14 LibinLiu0189 opened 1 year ago
0
13. Igor: It is valuable to make a distinction between Static "General Information" (such as information from registries or manual configs) and Dynamic "General Information" (such as information from RIB). Dynamic is the only kind of information that can be used to discover the real forwarding paths, because real forwarding paths can change at any time. It should be noted that depending on the implementation, a change of a real forwarding path may be reflected in the SIB with a delay. Therefore, it is more robust to use Static General Information for discovering permissible paths, especially for inter-domain solutions. [during ietf 117]

#13 LibinLiu0189 opened 1 year ago
0
12. Igor: The section differentiates between "SAV-specific Information" (information developed exclusively for SAV) and "General Information" (other information). It does not anticipate "dual-use" information -- information developed for both SAV and non-SAV purposes. While "SAV-specific Information" would, indeed, require a new protocol to disseminate, the "dual use" information may be disseminated using an existing protocol. [during ietf 117]

#12 LibinLiu0189 opened 1 year ago
0
11. Alvaro: If existing routing protocol is used to transmit the SAV information, it is needed to note that existing routing mechanism cannot be affected. [during ietf 117]

#11 LibinLiu0189 opened 1 year ago
0
10. Alvaro: The “forwarding path information” seems to indicate the routing or forwarding information, rather than SAV information. [during ietf 117]

#10 LibinLiu0189 opened 1 year ago
0
9. Alvaro: What type of information is the SAV information? [during ietf 117]

#9 LibinLiu0189 opened 1 year ago
0
8. Igor: Section 8. Security Considerations: It is noted in Section 4 that an attack on the routing infrastructure can interfere with the propagation of SAV information. This should be reflected in Security Considerations instead. This is a different case than "Session integrity destruction" by a malicious router. [during ietf 117]

#8 LibinLiu0189 opened 1 year ago
0
7. Igor: Section 3. Design Goals: should this section even exist, given that we have the Problem Statement? The section should at least reference the Problem Statement document here. [during ietf 117]

#7 LibinLiu0189 opened 1 year ago
0
6. Sriram: You will include the forwarding path in the SAV-specific message. Does it contain an AS path? [during ieft 117]

#6 LibinLiu0189 opened 1 year ago
0
5. Joel: need to distinguish between incremental deployment of support for the SAV protocol and its information incremental deployment of acting on the SAV information. [during ietf 117]

#5 LibinLiu0189 opened 1 year ago
0
4. Jeff: should add the considerations for the convergence and scalability. [during ietf 117]

#4 LibinLiu0189 opened 1 year ago
0
3. Jeff: should discuss what incremental means in deployment considerations. [during ietf 117]

#3 LibinLiu0189 opened 1 year ago
0
2. Ben: SAV-specific protocol should not be used to distribute information for forwarding. [during ietf 117]

#2 LibinLiu0189 opened 1 year ago
0
1. Rudiger: whether or when a basic model of SAV-specific message content is introduced? [during ietf 117]

#1 LibinLiu0189 opened 1 year ago
0