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) 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] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
BTW, we have 3 possibility for inidicating "anonymous" ID. 1. Don't send ID Payload at all. 2. Send empty ID Payload (say, Type = 0, Len=0). 3. Send special ID Payload (say, Type=KeyId, Value="anonymous") For me, case 3 looks the worst, I'd rather to avoid special values. Case 1 looks the best from theoretical point of view, but it will add complexity to already over-complicated IKE_AUTH state machine (note, that currently ID Payload is mandatory). For me case 2 looks like acceptible compromise. I don't think this complicates the state machine that much, as it's clearly distinct by the auth type none payload. My preference is for #1. Thank you for sharing your opinion. I still think that empty ID is preferrable, as IMHO it will add less complexity to implementation. I'd still like to know more opinions on this. Multiple clients behind the same NAT router with transport mode would use different NATed UDP ports. The IPsec server can differentiate incoming packets this way. But for outgoing UDP packet streams (not udp replies) it would need to know which of the clients using the same IP this packet would need to get encrypted to. You would need some kind of "mark" asociating the SA with the socket. For *swan we did this with an "SAref" marker. It would use ip_conntrack and put an SPI based iptables MARK on the packt. For new connections originating from the IPsec gateway, you could set a socket option (IP_IPSEC_BINDREF) if you know the SPI/MARK. I got your point. But this problem is unrelated to NULL Auth and even to OE, IMHO. So I don't think it must be addressed in this draft. If draft says that in case of NULL Auth ID Payload SHOULD be sent empty and MUST be ignored by receiver, will it satisfy you? Yes, that would be perfect. Great. By the way, I do prefer the name "auth none" over "auth null". To me, 'null' embodies more of an error condition. My reasons for selecting this name were the folowing. First, we define new Authentication Method in IANA. A method is some essence, that defines how authentication has to be done. For me "NONE authentication" implies that this essence doesn't exist at all, while "NULL authentication" implies that this essence (authentication) exists, but performs no real action (is dummy). For me is sounds a bit better, as we define an essence in IANA. And second, I had a similar example - NULL Encryption Algorithm in ESP. For some reason it was named NULL, not NONE, so I just decided to follow this tradition. Disclaimer: english is not my native language, so my arguments for the naming may look a bit silly. Paul Regards, Valery. ___ 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)" 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) > 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 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)" > 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) >> 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] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
On Fri, 17 Jan 2014, Valery Smyslov wrote: I don't think this complicates the state machine that much, as it's clearly distinct by the auth type none payload. My preference is for #1. Thank you for sharing your opinion. I still think that empty ID is preferrable, as IMHO it will add less complexity to implementation. I'd still like to know more opinions on this. Sure. Let's hear from others. I got your point. But this problem is unrelated to NULL Auth and even to OE, IMHO. So I don't think it must be addressed in this draft. Agreed. By the way, I do prefer the name "auth none" over "auth null". To me, 'null' embodies more of an error condition. My reasons for selecting this name were the folowing. First, we define new Authentication Method in IANA. A method is some essence, that defines how authentication has to be done. For me "NONE authentication" implies that this essence doesn't exist at all, while "NULL authentication" implies that this essence (authentication) exists, but performs no real action (is dummy). For me is sounds a bit better, as we define an essence in IANA. And second, I had a similar example - NULL Encryption Algorithm in ESP. For some reason it was named NULL, not NONE, so I just decided to follow this tradition. I figured that was the reason. Although I think in the ESP case there is an NO-OP encryption with the name NULL. Here I think we have "no authentication", not an "authentication with null" Disclaimer: english is not my native language, so my arguments for the naming may look a bit silly. The same disclaimer applies to me. So I would also like to hear from others on this issue. Regardless, it is not a big deal for me. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
