Hello All, Reading RIPE-501 spec for basic CPEs, I see that IPSEC & IKE are mandatory under "host" equipment. Is this a necessity ? Many IPv4 CPEs do not support IPSEC to keep the costs down. Regards, -Ahmed
On 7/20/11 2:42 PM, Ahmed Abu-Abed wrote:
Hello All, Reading RIPE-501 spec for basic CPEs, I see that IPSEC & IKE are mandatory under "host" equipment. Is this a necessity ? Many IPv4 CPEs do not support IPSEC to keep the costs down. Regards, -Ahmed
Yes, host must support this. CPE not necessarily, that's why it's under optional requirements. Cheers, Jan
Don't forget that although IPsec is part of IPv6 functionality, supporting null encapsulation (whatever it's properly called ;) and no authentication or encryption protocol also makes you compliant. We might make it optional ;) Ivan
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: Wednesday, July 20, 2011 6:36 PM To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 and IPSEC on CPEs
On 7/20/11 2:42 PM, Ahmed Abu-Abed wrote:
Hello All, Reading RIPE-501 spec for basic CPEs, I see that IPSEC & IKE are mandatory under "host" equipment. Is this a necessity ? Many IPv4 CPEs do not support IPSEC to keep the costs down. Regards, -Ahmed
Yes, host must support this. CPE not necessarily, that's why it's under optional requirements.
Cheers, Jan
ESP-NULL.....which means that you do use an integrity crypto algorithm such as SHA-1, SHA256, MD5, etc The Node Requirements bis doc is reaching finalization in the IETF and has changed IPsec from a MUST to a SHOULD: "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both manual and automatic key management. Currently the default automated key management protocol to implement is IKEv2. As required in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST implement ESP [RFC4303] and MAY implement AH [RFC4302]." It may make sense to change IPsec to 'optional' (I can't believe I am saying this :)). - merike On Jul 20, 2011, at 9:40 AM, Ivan Pepelnjak wrote:
Don't forget that although IPsec is part of IPv6 functionality, supporting null encapsulation (whatever it's properly called ;) and no authentication or encryption protocol also makes you compliant.
We might make it optional ;) Ivan
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: Wednesday, July 20, 2011 6:36 PM To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 and IPSEC on CPEs
On 7/20/11 2:42 PM, Ahmed Abu-Abed wrote:
Hello All, Reading RIPE-501 spec for basic CPEs, I see that IPSEC & IKE are mandatory under "host" equipment. Is this a necessity ? Many IPv4 CPEs do not support IPSEC to keep the costs down. Regards, -Ahmed
Yes, host must support this. CPE not necessarily, that's why it's under optional requirements.
Cheers, Jan
Thus wrote Ivan Pepelnjak (ip@ioshints.info):
Don't forget that although IPsec is part of IPv6 functionality, supporting null encapsulation (whatever it's properly called ;) and no authentication or encryption protocol also makes you compliant.
We might make it optional ;)
Do we -want- to make it optional? I'd call that a step backwards. The list is not so that every last ratty device someone dragged off their junk heap can fulfil it, after all. regards, spz -- spz@serpens.de (S.P.Zeidler)
On 7/20/11 8:05 PM, S.P.Zeidler wrote:
Do we -want- to make it optional? I'd call that a step backwards. The list is not so that every last ratty device someone dragged off their junk heap can fulfil it, after all.
I feel to agree with this statement... what percentage of CPEs we "throw out" if we make this optional? cheers, jan
On Jul 20, 2011, at 11:54 AM, Jan Zorz @ go6.si wrote:
On 7/20/11 8:05 PM, S.P.Zeidler wrote:
Do we -want- to make it optional? I'd call that a step backwards. The list is not so that every last ratty device someone dragged off their junk heap can fulfil it, after all.
I feel to agree with this statement...
what percentage of CPEs we "throw out" if we make this optional?
You mean mandatory requirement for IPsec right? How many CPEs would not be compliant if we kept it a mandatory requirement to implement IPsec? While I am a huge proponent of IPsec, I have seen so many TLS implementations take over and more are getting standardized that I am left wondering whether mandating IPsec on paper makes sense realistically. I have zero issues with keeping IPsec as mandatory for hosts but want to play devils advocate for a minute. - merike
On 7/20/11 8:54 PM, Jan Zorz @ go6.si wrote:
I feel to agree with this statement...
what percentage of CPEs we "throw out" if we make this optional? sorry, mandatory, not optional. typo.
so, what percentage of CPEs we "throw out" if we make this mandatory? cheers, Jan
I believe implementing line rate IPSEC on a CPE requires silicon that accelerates the crypto algorithms, and this may be a good feature but is outside the budget of most consumers who don't need much beyond SSL/TLS embedded in their HTTP client. So making IPSEC optional is more practical to LIRs needing low cost CPE solutions. And to answer the question below, I know one low cost IPv6 CPE vendor on RIPE's CPE Survey who doesn't support IPSEC, but haven't checked them all. -Ahmed -------------------------------------------------- From: "Jan Zorz" <jan@pragma.si> Sent: Thursday, July 21, 2011 12:48 AM To: <ipv6-wg@ripe.net> Subject: Re: [ipv6-wg] RIPE-501 and IPSEC on CPEs
On 7/20/11 8:54 PM, Jan Zorz @ go6.si wrote:
I feel to agree with this statement...
what percentage of CPEs we "throw out" if we make this optional? sorry, mandatory, not optional. typo.
so, what percentage of CPEs we "throw out" if we make this mandatory?
cheers, Jan
On 7/21/11 12:28 PM, Ahmed Abu-Abed wrote:
I believe implementing line rate IPSEC on a CPE requires silicon that accelerates the crypto algorithms, and this may be a good feature but is outside the budget of most consumers who don't need much beyond SSL/TLS embedded in their HTTP client.
So making IPSEC optional is more practical to LIRs needing low cost CPE solutions.
And to answer the question below, I know one low cost IPv6 CPE vendor on RIPE's CPE Survey who doesn't support IPSEC, but haven't checked them all. Hmm, how to promote ipsec and security and not discriminate too many devices at same time?
Should we move IPSEC and all that security stuff under mandatory and pre-pend it with "If ipsec (or whatever fits) is requested, then ...... is required. Would that work? Cheers, Jan
Hi, Thus wrote Ahmed Abu-Abed (ahmed@tamkien.com):
I believe implementing line rate IPSEC on a CPE requires silicon that accelerates the crypto algorithms, and this may be a good
Depends on your line rate. Up to 10Mbps, with i386 family CPUs of 400Mhz or better, the CPU on its own will do fine.
So making IPSEC optional is more practical to LIRs needing low cost CPE solutions.
Another option would be for LIRs looking for ultra low cost routers to take some that don't make the requirements list. Or take CPEs that flag themselves as "fulfilling RIPE-501 except IPSEC". Just because RIPE-501 exists does not mean that devices that don't fulfil it will suddenly evaporate, right? Again, the purpose of such a list is that a device that fulfils it will cover most reasonable needs. If we strike every feature off that somebody said "oh well I think I can do without that" about, it will become a useless "remotely resembling functional" description. Arguing that practically nobody would want their CPE to do IPSEC because everybody does host based IPSEC would be a better approach, but I would offer that that's going to be patently untrue if you look at company users and not private-person-residential users. regards, spz -- spz@serpens.de (S.P.Zeidler)
Hello, On July 23rd S.P.Zeidler wrote:
Hi,
Thus wrote Ahmed Abu-Abed (ahmed@tamkien.com):
I believe implementing line rate IPSEC on a CPE requires silicon that accelerates the crypto algorithms, and this may be a good
Depends on your line rate. Up to 10Mbps, with i386 family CPUs of 400Mhz or better, the CPU on its own will do fine.
100Mbps (or even 1Gbps) is also needed with GPON and ADSL2+ CPE offerings. And CPE vendors stay away from x86 processors due to heat dissipation issues.
So making IPSEC optional is more practical to LIRs needing low cost CPE solutions.
Another option would be for LIRs looking for ultra low cost routers to take some that don't make the requirements list. Or take CPEs that flag themselves as "fulfilling RIPE-501 except IPSEC".
One of the main objectives of RIPE-501 is specifying IPv6 CPE requirements. CPEs are consumer devices, and LIRs need a spec that take practical issues, like cost, into consideration.
Just because RIPE-501 exists does not mean that devices that don't fulfil it will suddenly evaporate, right?
Shipping volume wise, IPv6 consumer CPEs are the most to utilize the RIPE-501 spec. So why not make such devices a priority when it comes to the mandatory requirements ?
Again, the purpose of such a list is that a device that fulfils it will cover most reasonable needs.
IPSEC on a low price consumer device may not be a reasonable need with current hardware offerings for CPEs. Making it optional is the best approach.
If we strike every feature off that somebody said "oh well I think I can do without that" about, it will become a useless "remotely resembling functional" description.
Arguing that practically nobody would want their CPE to do IPSEC because everybody does host based IPSEC would be a better approach, but I would offer that that's going to be patently untrue if you look at company users and not private-person-residential users.
Many company users have a VPN client setup on their PC which should not need IPSEC on the CPE to work. We didn't say nobody wants it on their CPE, but IPSEC should not be on the mandatory list. Regards, -Ahmed
Hi, Thus wrote Ahmed Abu-Abed (ahmed@tamkien.com):
Arguing that practically nobody would want their CPE to do IPSEC because everybody does host based IPSEC would be a better approach, but I would offer that that's going to be patently untrue if you look at company users and not private-person-residential users.
Many company users have a VPN client setup on their PC which should not need IPSEC on the CPE to work.
So a company with two locations solves "the people at one location need to be able to access resources at the other location" by having the single PCs open a VPN connection .. where to exactly? So a company with several hundred locations with a local LAN each has several dozen PCs from each location open VPNs to a concentrator (instead of having the CPE open one connection for the entire LAN) and no useful way to get from location A to location B, nor even a useful way for central IT to get at the machines in the single locations? Neither of these scenarios is even remotely rare. The very first sentence of RIPE-501 v2 is: "To ensure the smooth and cost-efficient uptake of IPv6 across their networks, it is important that governments and large enterprises specify requirements for IPv6 compatibility when seeking tenders for Information and Communication Technology (ICT) equipment and support." "governments and large enterprises" not "John&Mary Smith, private residence" Throwing out a bog standard requirement for companies of almost any size because a family household will likely not need it in their CPE strikes me as missing the point. By a mile. regards, spz -- spz@serpens.de (S.P.Zeidler)
On 7/23/11 12:54 AM, S.P.Zeidler wrote:
Another option would be for LIRs looking for ultra low cost routers to take some that don't make the requirements list. Or take CPEs that flag themselves as "fulfilling RIPE-501 except IPSEC".
:)
Just because RIPE-501 exists does not mean that devices that don't fulfil it will suddenly evaporate, right?
Again, the purpose of such a list is that a device that fulfils it will cover most reasonable needs.
agree.
If we strike every feature off that somebody said "oh well I think I can do without that" about, it will become a useless "remotely resembling functional" description.
Arguing that practically nobody would want their CPE to do IPSEC because everybody does host based IPSEC would be a better approach, but I would offer that that's going to be patently untrue if you look at company users and not private-person-residential users.
Business CPE must support it, residential should. But, please, have in mind that feedback from this list goes to Ole Troan, editor of RFC6204. He suggested to include only RFC6204 as mandatory (and that was also response from this community), so in case of different ideas RFC6204 might be changed. Ole, are you in the game? :) My suggestion would be to add (in addition to RFC6204 in mandatory): "If this specification is used for business class CPE, then IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to RFC6204 requirements" Suggestions, opinions? Cheers, Jan Cheers, Jan
On 7/24/11 10:50 AM, Jan Zorz @ go6.si wrote:
My suggestion would be to add (in addition to RFC6204 in mandatory):
"If this specification is used for business class CPE, then IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to RFC6204 requirements"
Any opinions from the WG on this? Otherwise I would add this to the spec. Ole? Cheers, Jan
Hi, On Tue, Jul 26, 2011 at 09:43:16AM +0200, Jan Zorz @ go6.si wrote:
On 7/24/11 10:50 AM, Jan Zorz @ go6.si wrote:
My suggestion would be to add (in addition to RFC6204 in mandatory):
"If this specification is used for business class CPE, then IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to RFC6204 requirements"
Any opinions from the WG on this? Otherwise I would add this to the spec.
I like this version. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
My suggestion would be to add (in addition to RFC6204 in mandatory):
"If this specification is used for business class CPE, then IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to RFC6204 requirements"
Any opinions from the WG on this? Otherwise I would add this to the spec.
Ole?
on the fence, but if I had to fall down on one side I think its OK. perhaps a should? it really depends on the deployment. not all business deployments require VPNs. which presume is what is the underlaying reason for requiring this? cheers, Ole
On 7/26/11 3:44 PM, Ole Troan wrote:
My suggestion would be to add (in addition to RFC6204 in mandatory):
"If this specification is used for business class CPE, then IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to RFC6204 requirements"
Any opinions from the WG on this? Otherwise I would add this to the spec.
Ole?
on the fence, but if I had to fall down on one side I think its OK. perhaps a should? it really depends on the deployment. not all business deployments require VPNs. which presume is what is the underlaying reason for requiring this?
Ole, thnx for kicking in... So, did you mean something like this in Optional section: "If this specification is used for business class CPE, then it is highly recommended, that IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] are unconditionally required in addition to RFC6204 requirements" Would that work? What others think? Cheers, Jan
On Jul 26, 2011, at 9:04 AM, Jan Zorz @ go6.si wrote:
On 7/26/11 3:44 PM, Ole Troan wrote:
My suggestion would be to add (in addition to RFC6204 in mandatory):
"If this specification is used for business class CPE, then IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to RFC6204 requirements"
Any opinions from the WG on this? Otherwise I would add this to the spec.
Ole?
on the fence, but if I had to fall down on one side I think its OK. perhaps a should? it really depends on the deployment. not all business deployments require VPNs. which presume is what is the underlaying reason for requiring this?
Ole, thnx for kicking in...
So, did you mean something like this in Optional section:
"If this specification is used for business class CPE, then it is highly recommended, that IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] are unconditionally required in addition to RFC6204 requirements"
Would that work?
What others think?
The document lists mandatory and optional requirements. I think we should stick to this model. I like this new wording for the optional section here since it does stipulate that IPsec is strongly recommended but does not mandate it. - merike
So, did you mean something like this in Optional section:
"If this specification is used for business class CPE, then it is highly recommended, that IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] are unconditionally required in addition to RFC6204 requirements"
Would that work?
ack. cheers, Ole
participants (8)
-
Ahmed Abu-Abed -
Gert Doering -
Ivan Pepelnjak -
Jan Zorz -
Jan Zorz ＠ go6.si -
Merike Kaeo -
Ole Troan -
S.P.Zeidler