Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Hi, Thanks for the feed back, please see inline my response. BR, Daniel On Thu, Feb 6, 2014 at 11:07 AM, Timo Teras timo.te...@iki.fi wrote: On Thu, 6 Feb 2014 09:20:08 +0100 Daniel Migault mglt.i...@gmail.com wrote: Thanks for the feed back. We are happy you provide requirements over dynamically routing subnets as a MUST. ADVPN responds to the requirements listed in RFC7018. If there is a requirement that does not match you opinion, can you please point it out? Just to make it clear this 1 day time has never been mentioned in the draft and is your assumption. The use of TTL does not impose a 1 day and ADVPN can take advantage of the Redirect Mechanism or MOBIKE for multihoming. As you can see the ADVPN solution can take advantage of all previous and future featured designed for IKEv2. As you point out the key characteristic of our design is its flexibility. It was Praveen's suggestion in the email I replied. My point was that having that sort of default TTL does not sound good. And to me it sounds like having very low TTL (in level of seconds or minutes) is too heavy to be used in practice. So the TTL mechanism does not really sound feasible to me. Fine so TTL is a simple way to provide resilience, but not an optimized one. MOBIKE address this issue for IPsec. RFC5685 is not limited to client-gateway, the second line of the section 10 you pointed out says: [...] the mechanism can also be used between any two IKEv2 peers. So no additional specification are required. You missed the next sentance: However, the mechanism can also be used between any two IKEv2 peers. But this protocol is asymmetric, meaning that only the original responder can redirect the original initiator to another server. Suppose A establish an IPsec session with node B. B can use a Redirect not A. If A has not the capacity to handle the communication it should not initiate it, and let C initiate the communication. This may be a disadvantage is A and B are equal, but in that case A and B should be organized as clusters and redirect may not be the best way. Spoke A established tunnel to spoke B. A is thus original initiator. But the routing change is on spoke B subnet. B cannot send Redirect according to the above. You'd need to specify additional mechanism for that, or re-specify the original one. I believe this restriction is due to security considerations for client-gateway type connectivity. You mention load balancing may be an issue. Can you please specify the issue you see? Could you specify how in practice I could implement one subnet to be load-balanced to spoke nodes? If I correctly understand your scenario, you are looking at load balancing the traffic of your private network between two spokes. Any IP-load balancer could split and load balance the traffic between the two spokes. On the other hand you might also want to have multiple spokes under a given IP address. In that case, load balancing is performed according to the hash of the IP addresses or according to values of the SPI. Solution like cluster IP load balance the traffic between the two spokes [1]. [1] http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability One last point to clarify. it seems that you are trying to say ADVPN misses some features provided by routing protocols. In fact ADVPN can take advanatge of ALL of these features as ANY routing protocol can run on the top of ADVPN. This was a MUST requirement of RFC5685. If you see a scenrio that you think does not fit ADVPN, please document it so we can address your specific issue. I thought the advantage was to _not_ run routing protocol. You are right ADVPN does not necessarily need routing protocol. It can have one or not, it is up to the scenarios you want to address. If running routing protocol is supported, can you please specify how a routing protocol is to be integrated with the IKE traffic exchange? Yes, it is possible, but non-trivial, thus I would like to see some specification mapping how to do that mapping. I do not see the issue. Can you point out the issue more specifically. And like someone else asked, how is MPLS routed? Maybe you could encapsulates MPLS traffic in GRE/IP. Everything possible with DMVPN is possible with ADVPN. Thanks, Timo -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Hi, On Wed, 19 Feb 2014 21:57:26 +0100 Daniel Migault mglt.i...@gmail.com wrote: On Thu, Feb 6, 2014 at 11:07 AM, Timo Teras timo.te...@iki.fi wrote: On Thu, 6 Feb 2014 09:20:08 +0100 Daniel Migault mglt.i...@gmail.com wrote: RFC5685 is not limited to client-gateway, the second line of the section 10 you pointed out says: [...] the mechanism can also be used between any two IKEv2 peers. So no additional specification are required. You missed the next sentance: However, the mechanism can also be used between any two IKEv2 peers. But this protocol is asymmetric, meaning that only the original responder can redirect the original initiator to another server. Suppose A establish an IPsec session with node B. B can use a Redirect not A. If A has not the capacity to handle the communication it should not initiate it, and let C initiate the communication. This may be a disadvantage is A and B are equal, but in that case A and B should be organized as clusters and redirect may not be the best way. But if A original had the capacity and was intended to establish it, but then later on routing protocol or administrative action made the prefix to be removed from A. A would then need to inform of this somehow. You mention load balancing may be an issue. Can you please specify the issue you see? Could you specify how in practice I could implement one subnet to be load-balanced to spoke nodes? If I correctly understand your scenario, you are looking at load balancing the traffic of your private network between two spokes. Any IP-load balancer could split and load balance the traffic between the two spokes. On the other hand you might also want to have multiple spokes under a given IP address. In that case, load balancing is performed according to the hash of the IP addresses or according to values of the SPI. Solution like cluster IP load balance the traffic between the two spokes [1]. [1] http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability This generally works by requiring single virtual IP that is then later on load-blanced. How about I have two ISP connection with separate public IPs. Haw can I loadbalance over them? This is relatively simple to achieve in DMVPN. One last point to clarify. it seems that you are trying to say ADVPN misses some features provided by routing protocols. In fact ADVPN can take advanatge of ALL of these features as ANY routing protocol can run on the top of ADVPN. This was a MUST requirement of RFC5685. If you see a scenrio that you think does not fit ADVPN, please document it so we can address your specific issue. I thought the advantage was to _not_ run routing protocol. You are right ADVPN does not necessarily need routing protocol. It can have one or not, it is up to the scenarios you want to address. If running routing protocol is supported, can you please specify how a routing protocol is to be integrated with the IKE traffic exchange? Yes, it is possible, but non-trivial, thus I would like to see some specification mapping how to do that mapping. I do not see the issue. Can you point out the issue more specifically. There is a lot of things involved. First question is already explained in this (see above) and the previous mails. What happens when routing protocol withdraws a subnet from one gateway, and it needs to tell everyone that it's no longer available from it, but may be available through other nodes. And like someone else asked, how is MPLS routed? Maybe you could encapsulates MPLS traffic in GRE/IP. Everything possible with DMVPN is possible with ADVPN. This is one step closer to dmvpn. But how would the SHORTCUT mechanism work then? 4.1. says protected domain can contain only INTERNAL_IP4_SUBNET (13) and INTERNAL_IP6_SUBNET (15). You'd need to specify additional record types to all possible protocols ever needed to run over GRE. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
On Thu, 6 Feb 2014 09:20:08 +0100 Daniel Migault mglt.i...@gmail.com wrote: Thanks for the feed back. We are happy you provide requirements over dynamically routing subnets as a MUST. ADVPN responds to the requirements listed in RFC7018. If there is a requirement that does not match you opinion, can you please point it out? Just to make it clear this 1 day time has never been mentioned in the draft and is your assumption. The use of TTL does not impose a 1 day and ADVPN can take advantage of the Redirect Mechanism or MOBIKE for multihoming. As you can see the ADVPN solution can take advantage of all previous and future featured designed for IKEv2. As you point out the key characteristic of our design is its flexibility. It was Praveen's suggestion in the email I replied. My point was that having that sort of default TTL does not sound good. And to me it sounds like having very low TTL (in level of seconds or minutes) is too heavy to be used in practice. So the TTL mechanism does not really sound feasible to me. RFC5685 is not limited to client-gateway, the second line of the section 10 you pointed out says: [...] the mechanism can also be used between any two IKEv2 peers. So no additional specification are required. You missed the next sentance: However, the mechanism can also be used between any two IKEv2 peers. But this protocol is asymmetric, meaning that only the original responder can redirect the original initiator to another server. Spoke A established tunnel to spoke B. A is thus original initiator. But the routing change is on spoke B subnet. B cannot send Redirect according to the above. You'd need to specify additional mechanism for that, or re-specify the original one. I believe this restriction is due to security considerations for client-gateway type connectivity. You mention load balancing may be an issue. Can you please specify the issue you see? Could you specify how in practice I could implement one subnet to be load-balanced to spoke nodes? One last point to clarify. it seems that you are trying to say ADVPN misses some features provided by routing protocols. In fact ADVPN can take advanatge of ALL of these features as ANY routing protocol can run on the top of ADVPN. This was a MUST requirement of RFC5685. If you see a scenrio that you think does not fit ADVPN, please document it so we can address your specific issue. I thought the advantage was to _not_ run routing protocol. If running routing protocol is supported, can you please specify how a routing protocol is to be integrated with the IKE traffic exchange? Yes, it is possible, but non-trivial, thus I would like to see some specification mapping how to do that mapping. And like someone else asked, how is MPLS routed? Thanks, Timo ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
On Mon, 20 Jan 2014 18:14:58 + Praveen Sathyanarayan pravee...@juniper.net wrote: 1.2 What happens when a prefix administratively changes from behind one branch to another ? How do servers get notified about that ? [PRAVEEN] That’s an interesting point Fred, and thanks for bringing it up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN sections (3.6 and 3.9, respectively) of http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03. As a general rule, each spoke can download updated PROTECTED_DOMAIN information periodically, which advertises everything behind the hub and all other spokes combined. Of course, this does not change if some subnet has moved from behind spoke A to behind another spoke, B. However, the Lifetime attribute of the ADVPN_INFO payload is key here. We could see this being employed in a straightforward manner to allow for this transition: a) the subnet can disappear and be unreachable for one Lifetime, or b) the original spoke can redirect to the new spoke. We don't think this matters much in the real world, because people don't just move entire subnets instantaneously. Typically, folks stop using a subnet in one place, then begin using it in another. This makes a lot of sense for several operational reasons, as you would imagine. In fact, experience shows that since routing doesn't update across the world immediately, best practice would, for instance, indicate that it’s best to wait a day between stopping using the subnet in one place and starting to use it in another place. In this case, a Lifetime of one day or less should be just fine (and we’re thinking that, in fact, an hour would be a reasonable Lifetime value in practice). We would indeed argue that using Lifetime allows us to make the basic implementation of ADVPN handle a transition from one administrative domain to another in a straightforward manner. A redirection based on RFC5685 re-uses an already defined mechanism and makes the transition immediate, if/when necessary. This is one more argument for draft-sathyanarayan-ipsecme-advpn as it illustrates the modularity of our ADVPN proposal _and_ keeps the implementation simple. I disagree. IMGO, dynamically routing subnets is a MUST. Multiple scenarios exist. But to name one: I have complex site with multiple internal links and dynamic internal routing connected to ADVPN via two or more spokes (connected via different ISP lines). All the spokes can route to all subnets inside that site to provide redundancy, and in some cases load balancing. If one spoke's ISP line dies, or if the internal routing protocol decides other wise (e.g. intra-site link fails), the spokes should dynamically move the subnet from one to another. Having a failover time of _a day_ is unacceptable. The redirect mechanism seems to be limited to client-gateway connections, and only the gateway can send it (rfc5685 point 10). This is not true in advpn context as any spoke may want to later on redirect the SA of subnet it originally initiated. Using redirect would need additional specifications to be usable. Then there is also the case of load balancing... etc. I do agree that subnets should be authorized to be routed. I do that in existing dmvpn install, by means of automatically filtering the announced routes based on the presented certificate. That is, the certificate tells which subnets it can announce. - Timo ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Hi Praveen, thanks for taking the time to respond. I have read the ADVPN proposal with attention and these points need a much deeper dive as I do not think the specification is so straightforward. I will split the QA's for easier follow up as the thread will be very quickly unreadable. regards, fred On 20 Jan 2014, at 19:14, Praveen Sathyanarayan pravee...@juniper.net wrote: Hi Fred, Many thanks for the good comments. We're happy to clarify the fine details and nuances in our proposal further. As you could imagine, there are two ways that one can deploy ADVPN, as described in our draft. First, you can use the IPSec rules as defined on a per system/zone/virtual-system basis. Alternatively, one can bind the negotiated traffic-selectors during the negotiation (i.e. bind them to a virtual tunnel interface; in vendor-speak, I guess Cisco calls this a VTI interface, while Juniper refers to it as st0 interface). In general we consider this primarily an implementation decision. That is, different vendors may opt for either way, depending on what said vendor wants to bring into production. Both approaches are viable in the field and have their respective advantages. For example, if a tunnel-interface based approach is adopted, this allows us to run standard routing protocols to manage a large network, or achieve load-balancing in ECMP-based next hops. If someone choose rule based approach, they get better granularity and better security management. The take-home message here is that our draft (draft-sathyanarayan-ipsecme-advpn) is flexible enough to allow any vendor (commercial, open-source, and even academic) to go for whichever approach they prefer to implement according to their own considerations. With respect to commercially-oriented vendors, in particular, we expect that they can easily adopt our draft to provide an open solution without compromising their business goals. (This may not be the case for the other two drafts, but never mind for now). We would like to highlight once again that our draft does _not_ require the use of another tunneling mechanism just for establishing a shortcut tunnel between two endpoints. That is, one can simply extend their existing IPsec implementation to support shortcuts. Please see inline below for further answers and comments to your questions. Thanks, Praveen On 1/13/14, 8:07 AM, Frederic Detienne (fdetienn) fdeti...@cisco.com wrote: Hi, In reviewing the discussions over the past few weeks, there appear to be a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that require further clarification. It would be useful for the working group if the following aspects of draft-sathyanarayan-ipsecme-advpn-03 were clarified: 1. scaling general networking: 1.1 It does appear this proposal has a limit of 256 networks. Is this correct ? How do nodes negotiate SA's when there are more than 256 prefixes on each side ? For reference, RFC5996 does not offer the ability to negotiate more than 256 prefixes in the TSi TSr payloads. [PRAVEEN] The value you mention (256) is on a per shortcut tunnel basis. Nothing prevents you from having multiple shortcuts between the same shortcut partners. If a tunnel-interface approach is chosen, a routing protocol can be employed to manage, say, a large network. Based on the authors’ own implementation experience of IKE (i.e. without the ADVPN implementation in), you can always negotiate a single range (read: single subnet without narrowing). In other words, setting up an IPsec tunnel that is not tied to a VTI is pretty cheap and simple. It's just one round-trip in IKEv2 and, by default, involves no heavy crypto - just an encrypted CCSA packet and a KDF. 1.2 What happens when a prefix administratively changes from behind one branch to another ? How do servers get notified about that ? [PRAVEEN] That’s an interesting point Fred, and thanks for bringing it up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN sections (3.6 and 3.9, respectively) of http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03. As a general rule, each spoke can download updated PROTECTED_DOMAIN information periodically, which advertises everything behind the hub and all other spokes combined. Of course, this does not change if some subnet has moved from behind spoke A to behind another spoke, B. However, the Lifetime attribute of the ADVPN_INFO payload is key here. We could see this being employed in a straightforward manner to allow for this transition: a) the subnet can disappear and be unreachable for one Lifetime, or b) the original spoke can redirect to the new spoke. We don't think this matters much in the real world, because people don't just move entire subnets instantaneously. Typically, folks stop using a subnet in one place, then begin using it in
Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Hi Fred, Many thanks for the good comments. We're happy to clarify the fine details and nuances in our proposal further. As you could imagine, there are two ways that one can deploy ADVPN, as described in our draft. First, you can use the IPSec rules as defined on a per system/zone/virtual-system basis. Alternatively, one can bind the negotiated traffic-selectors during the negotiation (i.e. bind them to a virtual tunnel interface; in vendor-speak, I guess Cisco calls this a VTI interface, while Juniper refers to it as st0 interface). In general we consider this primarily an implementation decision. That is, different vendors may opt for either way, depending on what said vendor wants to bring into production. Both approaches are viable in the field and have their respective advantages. For example, if a tunnel-interface based approach is adopted, this allows us to run standard routing protocols to manage a large network, or achieve load-balancing in ECMP-based next hops. If someone choose rule based approach, they get better granularity and better security management. The take-home message here is that our draft (draft-sathyanarayan-ipsecme-advpn) is flexible enough to allow any vendor (commercial, open-source, and even academic) to go for whichever approach they prefer to implement according to their own considerations. With respect to commercially-oriented vendors, in particular, we expect that they can easily adopt our draft to provide an open solution without compromising their business goals. (This may not be the case for the other two drafts, but never mind for now). We would like to highlight once again that our draft does _not_ require the use of another tunneling mechanism just for establishing a shortcut tunnel between two endpoints. That is, one can simply extend their existing IPsec implementation to support shortcuts. Please see inline below for further answers and comments to your questions. Thanks, Praveen On 1/13/14, 8:07 AM, Frederic Detienne (fdetienn) fdeti...@cisco.commailto:fdeti...@cisco.com wrote: Hi, In reviewing the discussions over the past few weeks, there appear to be a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that require further clarification. It would be useful for the working group if the following aspects of draft-sathyanarayan-ipsecme-advpn-03 were clarified: 1. scaling general networking: 1.1 It does appear this proposal has a limit of 256 networks. Is this correct ? How do nodes negotiate SA's when there are more than 256 prefixes on each side ? For reference, RFC5996 does not offer the ability to negotiate more than 256 prefixes in the TSi TSr payloads. [PRAVEEN] The value you mention (256) is on a per shortcut tunnel basis. Nothing prevents you from having multiple shortcuts between the same shortcut partners. If a tunnel-interface approach is chosen, a routing protocol can be employed to manage, say, a large network. Based on the authors’ own implementation experience of IKE (i.e. without the ADVPN implementation in), you can always negotiate a single range (read: single subnet without narrowing). In other words, setting up an IPsec tunnel that is not tied to a VTI is pretty cheap and simple. It's just one round-trip in IKEv2 and, by default, involves no heavy crypto - just an encrypted CCSA packet and a KDF. 1.2 What happens when a prefix administratively changes from behind one branch to another ? How do servers get notified about that ? [PRAVEEN] That’s an interesting point Fred, and thanks for bringing it up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN sections (3.6 and 3.9, respectively) of http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03. As a general rule, each spoke can download updated PROTECTED_DOMAIN information periodically, which advertises everything behind the hub and all other spokes combined. Of course, this does not change if some subnet has moved from behind spoke A to behind another spoke, B. However, the Lifetime attribute of the ADVPN_INFO payload is key here. We could see this being employed in a straightforward manner to allow for this transition: a) the subnet can disappear and be unreachable for one Lifetime, or b) the original spoke can redirect to the new spoke. We don't think this matters much in the real world, because people don't just move entire subnets instantaneously. Typically, folks stop using a subnet in one place, then begin using it in another. This makes a lot of sense for several operational reasons, as you would imagine. In fact, experience shows that since routing doesn't update across the world immediately, best practice would, for instance, indicate that it’s best to wait a day between stopping using the subnet in one place and starting to use it in another place. In this case, a Lifetime of one day or less should be just fine (and we’re thinking that,
Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Hi, I would like to re-iterate the importance of clarifying the points below as it is not possible to assess the performances, relevance and interoperability of draft-sathyanarayan-ipsecme-advpn-03 at this stage - - these are all important issues to potential users of this techology. Thank you, Frederic Detienne On 13 Jan 2014, at 17:07, Frederic Detienne (fdetienn) fdeti...@cisco.com wrote: Hi, In reviewing the discussions over the past few weeks, there appear to be a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that require further clarification. It would be useful for the working group if the following aspects of draft-sathyanarayan-ipsecme-advpn-03 were clarified: 1. scaling general networking: 1.1 It does appear this proposal has a limit of 256 networks. Is this correct ? How do nodes negotiate SA's when there are more than 256 prefixes on each side ? For reference, RFC5996 does not offer the ability to negotiate more than 256 prefixes in the TSi TSr payloads. 1.2 What happens when a prefix administratively changes from behind one branch to another ? How do servers get notified about that ? 1.3 How is VLSM taken into consideration (Variable Length Subnet Masking). E.g. long prefix behind one branch and a short prefix behind another 1.4 How does a hub decide which Security Association to use when to spoke devices decide to advertise the same prefix ? 2. multicast: 2.1 There does not appear to be a specification of Multicast in this proposal. This is a key requirement for some of the ADVPN sponsors. How does multicast work ? 2.2 How are SA's negotiated and how do applications request multicast traffic to be sent ? 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not mention how a server/hub learns about networks behind other servers 3.1 what are the steps a server should take to establish a network with other servers 3.2 how is topology and reachability information exchanged between servers Thank you, Frederic Detienne ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Hi Fred, All of our co-authors are currently busy, as we need to catch up with many post holidays pending works. We will get back to you soon. -- Praveen On 1/17/14 1:56 AM, Frederic Detienne (fdetienn) fdeti...@cisco.com wrote: Hi, I would like to re-iterate the importance of clarifying the points below as it is not possible to assess the performances, relevance and interoperability of draft-sathyanarayan-ipsecme-advpn-03 at this stage - - these are all important issues to potential users of this techology. Thank you, Frederic Detienne On 13 Jan 2014, at 17:07, Frederic Detienne (fdetienn) fdeti...@cisco.com wrote: Hi, In reviewing the discussions over the past few weeks, there appear to be a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that require further clarification. It would be useful for the working group if the following aspects of draft-sathyanarayan-ipsecme-advpn-03 were clarified: 1. scaling general networking: 1.1 It does appear this proposal has a limit of 256 networks. Is this correct ? How do nodes negotiate SA's when there are more than 256 prefixes on each side ? For reference, RFC5996 does not offer the ability to negotiate more than 256 prefixes in the TSi TSr payloads. 1.2 What happens when a prefix administratively changes from behind one branch to another ? How do servers get notified about that ? 1.3 How is VLSM taken into consideration (Variable Length Subnet Masking). E.g. long prefix behind one branch and a short prefix behind another 1.4 How does a hub decide which Security Association to use when to spoke devices decide to advertise the same prefix ? 2. multicast: 2.1 There does not appear to be a specification of Multicast in this proposal. This is a key requirement for some of the ADVPN sponsors. How does multicast work ? 2.2 How are SA's negotiated and how do applications request multicast traffic to be sent ? 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not mention how a server/hub learns about networks behind other servers 3.1 what are the steps a server should take to establish a network with other servers 3.2 how is topology and reachability information exchanged between servers Thank you, Frederic Detienne ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thanks Praveen! fred On 17 Jan 2014, at 18:01, Praveen Sathyanarayan pravee...@juniper.net wrote: Hi Fred, All of our co-authors are currently busy, as we need to catch up with many post holidays pending works. We will get back to you soon. -- Praveen On 1/17/14 1:56 AM, Frederic Detienne (fdetienn) fdeti...@cisco.com wrote: Hi, I would like to re-iterate the importance of clarifying the points below as it is not possible to assess the performances, relevance and interoperability of draft-sathyanarayan-ipsecme-advpn-03 at this stage - - these are all important issues to potential users of this techology. Thank you, Frederic Detienne On 13 Jan 2014, at 17:07, Frederic Detienne (fdetienn) fdeti...@cisco.com wrote: Hi, In reviewing the discussions over the past few weeks, there appear to be a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that require further clarification. It would be useful for the working group if the following aspects of draft-sathyanarayan-ipsecme-advpn-03 were clarified: 1. scaling general networking: 1.1 It does appear this proposal has a limit of 256 networks. Is this correct ? How do nodes negotiate SA's when there are more than 256 prefixes on each side ? For reference, RFC5996 does not offer the ability to negotiate more than 256 prefixes in the TSi TSr payloads. 1.2 What happens when a prefix administratively changes from behind one branch to another ? How do servers get notified about that ? 1.3 How is VLSM taken into consideration (Variable Length Subnet Masking). E.g. long prefix behind one branch and a short prefix behind another 1.4 How does a hub decide which Security Association to use when to spoke devices decide to advertise the same prefix ? 2. multicast: 2.1 There does not appear to be a specification of Multicast in this proposal. This is a key requirement for some of the ADVPN sponsors. How does multicast work ? 2.2 How are SA's negotiated and how do applications request multicast traffic to be sent ? 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not mention how a server/hub learns about networks behind other servers 3.1 what are the steps a server should take to establish a network with other servers 3.2 how is topology and reachability information exchanged between servers Thank you, Frederic Detienne ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
