RIPE-501 replacement document - IPsec question to community - we need your input.
Dear IPv6 community. (copy/paste from our internal discussion) The authors of RIPE-501 are finalizing the last comments from previous last call and would like community input for what to do with IPsec. All authors feel that IPsec should be a mandatory requirement for all devices although due to technical limitations, for mobile devices it will be optional. We are aware that RFC6434 made IPsec support a SHOULD rather than a MUST. From RFC 2119: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. The change was largely due to limitations found in low power devices and therefore we still feel the community is best served by requiring mandatory IPsec support in all other devices (hosts, routers or layer-3 switches, network security devices, load balancers) If we get this input from you this year, there is a great chance that we could put out the new/final draft out for discussion and/or maybe last-last-call before new year. For RIPE-501 authors group, Jan P.S: wishing happy new year, merry xmass, happiness, IPv6 and all that stuff in at least next year :)
* Jan Zorz:
The authors of RIPE-501 are finalizing the last comments from previous last call and would like community input for what to do with IPsec. All authors feel that IPsec should be a mandatory requirement for all devices although due to technical limitations, for mobile devices it will be optional.
Shouldn't it be the other way round? Mobile devices are more likely to need VPN services than other kinds of devices. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Dec 23, 2011, at 1:06 AM, Florian Weimer wrote:
* Jan Zorz:
The authors of RIPE-501 are finalizing the last comments from previous last call and would like community input for what to do with IPsec. All authors feel that IPsec should be a mandatory requirement for all devices although due to technical limitations, for mobile devices it will be optional.
Shouldn't it be the other way round? Mobile devices are more likely to need VPN services than other kinds of devices.
Mobile devices typically use TLS. If that has changed it would be good to know but from my experience IPsec is hardly ever used in mobile devices and vendors had issues with battery life and argued against making it a mandatory requirement in the IETF. - merike
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
* Merike Kaeo:
On Dec 23, 2011, at 1:06 AM, Florian Weimer wrote:
* Jan Zorz:
The authors of RIPE-501 are finalizing the last comments from previous last call and would like community input for what to do with IPsec. All authors feel that IPsec should be a mandatory requirement for all devices although due to technical limitations, for mobile devices it will be optional.
Shouldn't it be the other way round? Mobile devices are more likely to need VPN services than other kinds of devices.
Mobile devices typically use TLS.
Most devices use TLS. I agree with dropping IPsec from the document completely, indepedent of device type. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 12/27/11 10:15 AM, Florian Weimer wrote:
Most devices use TLS.
I agree with dropping IPsec from the document completely, indepedent of device type.
Hi, So you suggest not mentioning IPsec in any form at all in whole document? Am I reading this correctly? Cheers, Jan
* Jan Zorz:
On 12/27/11 10:15 AM, Florian Weimer wrote:
Most devices use TLS.
I agree with dropping IPsec from the document completely, indepedent of device type.
So you suggest not mentioning IPsec in any form at all in whole document? Am I reading this correctly?
Yes. Even if we could achieve agreement on a subset of devices where it's supposed to make sense, "IPsec" is really a catchphrase for a set of related protocols, so anyone who actually needs some of it needs to ask for it explicitly anyway. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
I think that we should keep IPsec/IKEv2 only for firewall and mention to any place where OSPFv3 is mentioned that the support of AH is required.
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Florian Weimer Sent: mardi 27 décembre 2011 13:41 To: Jan Zorz @ go6.si Cc: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question tocommunity - we need your input.
* Jan Zorz:
On 12/27/11 10:15 AM, Florian Weimer wrote:
Most devices use TLS.
I agree with dropping IPsec from the document completely, indepedent of device type.
So you suggest not mentioning IPsec in any form at all in whole document? Am I reading this correctly?
Yes. Even if we could achieve agreement on a subset of devices where it's supposed to make sense, "IPsec" is really a catchphrase for a set of related protocols, so anyone who actually needs some of it needs to ask for it explicitly anyway.
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Dec 27, 2011, at 7:43 AM, Eric Vyncke (evyncke) wrote:
I think that we should keep IPsec/IKEv2 only for firewall and mention to any place where OSPFv3 is mentioned that the support of AH is required.
Is there an RFC that now states that IPsec AH for OSPFv3 is a 'MUST' or 'SHOULD' and not a 'MAY'? Last I recall the specifics for how to implement IPsec for OSPFv3 are in RFC4552 and states that ESP is a 'MUST' and AH is a 'MAY'. The arguments for AH and ESP-Null were also on the IPv6 Maintenance WG mailing list in Feb/March 2008 and I don't think the standard changed. - merike
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Florian Weimer Sent: mardi 27 décembre 2011 13:41 To: Jan Zorz @ go6.si Cc: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question tocommunity - we need your input.
* Jan Zorz:
On 12/27/11 10:15 AM, Florian Weimer wrote:
Most devices use TLS.
I agree with dropping IPsec from the document completely, indepedent of device type.
So you suggest not mentioning IPsec in any form at all in whole document? Am I reading this correctly?
Yes. Even if we could achieve agreement on a subset of devices where it's supposed to make sense, "IPsec" is really a catchphrase for a set of related protocols, so anyone who actually needs some of it needs to ask for it explicitly anyway.
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Hi, On Dec 27, 2011, at 8:08 am, Merike Kaeo wrote:
On Dec 27, 2011, at 7:43 AM, Eric Vyncke (evyncke) wrote:
I think that we should keep IPsec/IKEv2 only for firewall and mention to any place where OSPFv3 is mentioned that the support of AH is required.
Is there an RFC that now states that IPsec AH for OSPFv3 is a 'MUST' or 'SHOULD' and not a 'MAY'? Last I recall the specifics for how to implement IPsec for OSPFv3 are in RFC4552 and states that ESP is a 'MUST' and AH is a 'MAY'.
There is an unverified errata report that reverses those key words: http://www.rfc-editor.org/errata_search.php?rfc=4552 It'll be interesting to see if its status is ever changed to verified. Regards, Leo
On Dec 27, 2011, at 8:44 AM, Leo Vegoda wrote:
Hi,
On Dec 27, 2011, at 8:08 am, Merike Kaeo wrote:
On Dec 27, 2011, at 7:43 AM, Eric Vyncke (evyncke) wrote:
I think that we should keep IPsec/IKEv2 only for firewall and mention to any place where OSPFv3 is mentioned that the support of AH is required.
Is there an RFC that now states that IPsec AH for OSPFv3 is a 'MUST' or 'SHOULD' and not a 'MAY'? Last I recall the specifics for how to implement IPsec for OSPFv3 are in RFC4552 and states that ESP is a 'MUST' and AH is a 'MAY'.
There is an unverified errata report that reverses those key words:
http://www.rfc-editor.org/errata_search.php?rfc=4552
It'll be interesting to see if its status is ever changed to verified.
There are no details in the errata that are useful. I find it amusing that yesterday there started a discussion in the IETF IPsec wg about writing a draft to move AH to historic. 3 years ago I had started writing a doc to enumerate why ESP-Null is good enough and detailed the fields that were getting protected using AH and why even with OSPFv3 there wasn't a clear advantage. There are nuances with SPD that you implicitly get protection of the SRC and DST IP addresses. I think I need to finish that paper as it's 90% done. I'll send out to a few folks early next week.....something I was doing in some spare time a few years ago. Note also that this argument has come up a few times since eventhough you can use ESP for only integrity protection it has been difficult for vendors to make a quick distinction whether an ESP packet is integrity only or also encrypted. So, some vendors prefer to use AH since in some ways it is 'simpler' and doesn't affect their performance. AH is the least tested protocol in any interoperability test. I have attended a few and if that has changed, OK. Not from my experience. - merike
Regards,
Leo
Merike and others, When I wrote before Christmas 'AH for OSPFv3', I actually wanted to say 'IPsec authentication for OSPFv3'. After reading RFC 4552, it is obvious that 'ESP-null in transport mode is mandatory for routers supporting OSPFv3' Sorry for the confusion And I wish an IPv6-enabled year 2012 to you and all your devices -éric
-----Original Message----- From: Merike Kaeo [mailto:merike@doubleshotsecurity.com] Sent: vendredi 30 décembre 2011 19:33 To: Leo Vegoda Cc: Eric Vyncke (evyncke); ipv6-wg@ripe.net; Jan Zorz @ go6.si; Florian Weimer Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question tocommunity - we need your input.
On Dec 27, 2011, at 8:44 AM, Leo Vegoda wrote:
Hi,
On Dec 27, 2011, at 8:08 am, Merike Kaeo wrote:
On Dec 27, 2011, at 7:43 AM, Eric Vyncke (evyncke) wrote:
I think that we should keep IPsec/IKEv2 only for firewall and mention to any place where OSPFv3 is mentioned that the support of AH is required.
Is there an RFC that now states that IPsec AH for OSPFv3 is a 'MUST' or 'SHOULD' and not a 'MAY'? Last I recall the specifics for how to implement IPsec for OSPFv3 are in RFC4552 and states that ESP is a 'MUST' and AH is a 'MAY'.
There is an unverified errata report that reverses those key words:
http://www.rfc-editor.org/errata_search.php?rfc=4552
It'll be interesting to see if its status is ever changed to verified.
There are no details in the errata that are useful. I find it amusing that yesterday there started a discussion in the IETF IPsec wg about writing a draft to move AH to historic. 3 years ago I had started writing a doc to enumerate why ESP-Null is good enough and detailed the fields that were getting protected using AH and why even with OSPFv3 there wasn't a clear advantage. There are nuances with SPD that you implicitly get protection of the SRC and DST IP addresses.
I think I need to finish that paper as it's 90% done. I'll send out to a few folks early next week.....something I was doing in some spare time a few years ago.
Note also that this argument has come up a few times since eventhough you can use ESP for only integrity protection it has been difficult for vendors to make a quick distinction whether an ESP packet is integrity only or also encrypted. So, some vendors prefer to use AH since in some ways it is 'simpler' and doesn't affect their performance.
AH is the least tested protocol in any interoperability test. I have attended a few and if that has changed, OK. Not from my experience.
- merike
Regards,
Leo
Hi, Thus wrote Florian Weimer (fweimer@bfk.de):
Yes. Even if we could achieve agreement on a subset of devices where it's supposed to make sense, "IPsec" is really a catchphrase for a set of related protocols, so anyone who actually needs some of it needs to ask for it explicitly anyway.
My experience differs. I have a bunch of site-to-site VPNs on IPSEC, partially to not very large sites, and most enterprisey routers I've met can do an IPSEC tunnel just fine. How many sizeable enterprises or government entities do you know that really reside in just one building or even campus? The requirement to be able to connect a satellite office to headquarters is not really esoteric. regards, spz -- spz@serpens.de (S.P.Zeidler)
Hi,
Yes. Even if we could achieve agreement on a subset of devices where it's supposed to make sense, "IPsec" is really a catchphrase for a set of related protocols, so anyone who actually needs some of it needs to ask for it explicitly anyway.
My experience differs. I have a bunch of site-to-site VPNs on IPSEC, partially to not very large sites, and most enterprisey routers I've met can do an IPSEC tunnel just fine.
How many sizeable enterprises or government entities do you know that really reside in just one building or even campus? The requirement to be able to connect a satellite office to headquarters is not really esoteric.
I agree. We are writing a template for tender initiators for enterprises. I think we should state that IPSec is mandatory, because enterprises should have the possibility to set up IPSec site-to-site tunnels as a minimum. I think we should write it in such a way that enterprises require IPSec support when writing a request for tender, unless they consciously decide that they don't need it. So I think we should put IPSec in the 'required' section. If an enterprise knows it will not need it then they can move it to 'optional' themselves. RIPE-501 and its successor are templates to be used and adapted as necessary. We should provide a sane default, and they might (will probably?) need IPSec at some point in time. I am leaving for vacation now, so I'll eave it up to this WG to decide what to do with my input :-) Sander
On 12/27/11 11:36 PM, Sander Steffann wrote:
I agree. We are writing a template for tender initiators for enterprises. I think we should state that IPSec is mandatory, because enterprises should have the possibility to set up IPSec site-to-site tunnels as a minimum. I think we should write it in such a way that enterprises require IPSec support when writing a request for tender, unless they consciously decide that they don't need it. So I think we should put IPSec in the 'required' section. If an enterprise knows it will not need it then they can move it to 'optional' themselves. RIPE-501 and its successor are templates to be used and adapted as necessary. We should provide a sane default, and they might (will probably?) need IPSec at some point in time.
Hi, I somehow agree... Disclaimer: RIPE community explicitly expressed the "wish" not to write anything radical into RIPE-501 bis/replacement document - I think Joao did that also publicly at Amsterdam meeting, and we received this suggestion a lot on and off-line. Being said that, we might disregard all "radical" suggestions, such as "remove IPsec completely from the document" unless they are proven non-radical and that community (majority) feels in that way. So, for that suggestion there is much more support needed from community than we can see it now. Supporters for "remove IPsec requirements completely", make yourself heard, otherwise be quiet for the rest of the time :) (we need to get this document out of the door ASAP, many governments (not joking) are waiting for replacement to take it as basis for their national IPv6 profile ;) ) We received many strong suggestions also off-list to go with the flow and follow IETF way - make it all optional for all devices (maybe with this option we could leave it out for mobile devices). Supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :) Security and IPv6 advocate mind tells us to leave IPSec (at least v2) mandatory for all sections (not valid for mobile devices) and IPsec v3 optional. This would make sense from many points of view, but I (personally) cannot make up my mind if this is not too harsh prerequisite for this moment. Again, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :) Sanders proposal above adds additional section for all devices (minus mobile), so we expand to "Mandatory", "Required" and "Optional". If I may repeat myself, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :) So, if WG chairs allow, I would propose a "show of hands" and see, how we can proceed. (anyone who express clear support fo one of the options gets a candy at RIPE64 meeting in Ljubljana :) :) :) )
I am leaving for vacation now, so I'll eave it up to this WG to decide what to do with my input :-) Sander
Sander, have a good time and rest a bit :) V6 work for this year is done :) Cheers, Jan Zorz
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory) -éric
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jan Zorz Sent: mercredi 28 décembre 2011 10:43 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input.
On 12/27/11 11:36 PM, Sander Steffann wrote:
I agree. We are writing a template for tender initiators for enterprises. I think we should state that IPSec is mandatory, because enterprises should have the possibility to set up IPSec site-to-site tunnels as a minimum. I think we should write it in such a way that enterprises require IPSec support when writing a request for tender, unless they consciously decide that they don't need it. So I think we should put IPSec in the 'required' section. If an enterprise knows it will not need it then they can move it to 'optional' themselves. RIPE-501 and its successor are templates to be used and adapted as necessary. We should provide a sane default, and they might (will probably?) need IPSec at some point in time.
Hi,
I somehow agree...
Disclaimer: RIPE community explicitly expressed the "wish" not to write anything radical into RIPE-501 bis/replacement document - I think Joao did that also publicly at Amsterdam meeting, and we received this suggestion a lot on and off-line.
Being said that, we might disregard all "radical" suggestions, such as "remove IPsec completely from the document" unless they are proven non-radical and that community (majority) feels in that way.
So, for that suggestion there is much more support needed from community than we can see it now. Supporters for "remove IPsec requirements completely", make yourself heard, otherwise be quiet for the rest of the time :) (we need to get this document out of the door ASAP, many governments (not joking) are waiting for replacement to take it as basis for their national IPv6 profile ;) )
We received many strong suggestions also off-list to go with the flow and follow IETF way - make it all optional for all devices (maybe with this option we could leave it out for mobile devices). Supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
Security and IPv6 advocate mind tells us to leave IPSec (at least v2) mandatory for all sections (not valid for mobile devices) and IPsec v3 optional. This would make sense from many points of view, but I (personally) cannot make up my mind if this is not too harsh prerequisite for this moment. Again, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
Sanders proposal above adds additional section for all devices (minus mobile), so we expand to "Mandatory", "Required" and "Optional". If I may repeat myself, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
So, if WG chairs allow, I would propose a "show of hands" and see, how we can proceed. (anyone who express clear support fo one of the options gets a candy at RIPE64 meeting in Ljubljana :) :) :) )
I am leaving for vacation now, so I'll eave it up to this WG to decide what to do with my input :-) Sander
Sander, have a good time and rest a bit :) V6 work for this year is done :)
Cheers, Jan Zorz
Bottom posting will probably make this reply confusing so for now I'll just say that I tend to agree with my co-authors but we would like to hear more input from the RIPE community, especially the operators who are using IPsec in their IPv6 deployments (or plan to). six or seven voices seems like a small sampling. Our hope is the get the final document done and back to last call in next few weeks so replies by the end of this week would be very much appreciated. - merike On Jan 2, 2012, at 6:08 AM, Eric Vyncke (evyncke) wrote:
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
-éric
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jan Zorz Sent: mercredi 28 décembre 2011 10:43 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input.
On 12/27/11 11:36 PM, Sander Steffann wrote:
I agree. We are writing a template for tender initiators for enterprises. I think we should state that IPSec is mandatory, because enterprises should have the possibility to set up IPSec site-to-site tunnels as a minimum. I think we should write it in such a way that enterprises require IPSec support when writing a request for tender, unless they consciously decide that they don't need it. So I think we should put IPSec in the 'required' section. If an enterprise knows it will not need it then they can move it to 'optional' themselves. RIPE-501 and its successor are templates to be used and adapted as necessary. We should provide a sane default, and they might (will probably?) need IPSec at some point in time.
Hi,
I somehow agree...
Disclaimer: RIPE community explicitly expressed the "wish" not to write anything radical into RIPE-501 bis/replacement document - I think Joao did that also publicly at Amsterdam meeting, and we received this suggestion a lot on and off-line.
Being said that, we might disregard all "radical" suggestions, such as "remove IPsec completely from the document" unless they are proven non-radical and that community (majority) feels in that way.
So, for that suggestion there is much more support needed from community than we can see it now. Supporters for "remove IPsec requirements completely", make yourself heard, otherwise be quiet for the rest of the time :) (we need to get this document out of the door ASAP, many governments (not joking) are waiting for replacement to take it as basis for their national IPv6 profile ;) )
We received many strong suggestions also off-list to go with the flow and follow IETF way - make it all optional for all devices (maybe with this option we could leave it out for mobile devices). Supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
Security and IPv6 advocate mind tells us to leave IPSec (at least v2) mandatory for all sections (not valid for mobile devices) and IPsec v3 optional. This would make sense from many points of view, but I (personally) cannot make up my mind if this is not too harsh prerequisite for this moment. Again, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
Sanders proposal above adds additional section for all devices (minus mobile), so we expand to "Mandatory", "Required" and "Optional". If I may repeat myself, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
So, if WG chairs allow, I would propose a "show of hands" and see, how we can proceed. (anyone who express clear support fo one of the options gets a candy at RIPE64 meeting in Ljubljana :) :) :) )
I am leaving for vacation now, so I'll eave it up to this WG to decide what to do with my input :-) Sander
Sander, have a good time and rest a bit :) V6 work for this year is done :)
Cheers, Jan Zorz
Merike, 5 or 6 voices is indeed a too small sampling to be taken into account (even if I was one of those voices). No argument. But, I am a little less comfortable with your sentence about 'operators who are using IPsec' because my understanding was that RIPE-501bis is for 'tender initiators' which are more likely to be enterprises, public sector organizations rather than operators. Else, thanks for the job on RIPE-501: very much needed but do not shoot for the stars -éric
-----Original Message----- From: Merike Kaeo [mailto:merike@doubleshotsecurity.com] Sent: mardi 3 janvier 2012 01:48 To: Eric Vyncke (evyncke) Cc: Jan Zorz; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input.
Bottom posting will probably make this reply confusing so for now I'll just say that I tend to agree with my co-authors but we would like to hear more input from the RIPE community, especially the operators who are using IPsec in their IPv6 deployments (or plan to). six or seven voices seems like a small sampling.
Our hope is the get the final document done and back to last call in next few weeks so replies by the end of this week would be very much appreciated.
- merike
On Jan 2, 2012, at 6:08 AM, Eric Vyncke (evyncke) wrote:
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
-éric
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jan Zorz Sent: mercredi 28 décembre 2011 10:43 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input.
On 12/27/11 11:36 PM, Sander Steffann wrote:
I agree. We are writing a template for tender initiators for enterprises. I think we should state that IPSec is mandatory, because enterprises should have the possibility to set up IPSec site-to-site tunnels as a minimum. I think we should write it in such a way that enterprises require IPSec support when writing a request for tender, unless they consciously decide that they don't need it. So I think we should put IPSec in the 'required' section. If an enterprise knows it will not need it then they can move it to 'optional' themselves. RIPE-501 and its successor are templates to be used and adapted as necessary. We should provide a sane default, and they might (will probably?) need IPSec at some point in time.
Hi,
I somehow agree...
Disclaimer: RIPE community explicitly expressed the "wish" not to write anything radical into RIPE-501 bis/replacement document - I think Joao did that also publicly at Amsterdam meeting, and we received this suggestion a lot on and off-line.
Being said that, we might disregard all "radical" suggestions, such as "remove IPsec completely from the document" unless they are proven non-radical and that community (majority) feels in that way.
So, for that suggestion there is much more support needed from community than we can see it now. Supporters for "remove IPsec requirements completely", make yourself heard, otherwise be quiet for the rest of the time :) (we need to get this document out of the door ASAP, many governments (not joking) are waiting for replacement to take it as basis for their national IPv6 profile ;) )
We received many strong suggestions also off-list to go with the flow and follow IETF way - make it all optional for all devices (maybe with this option we could leave it out for mobile devices). Supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
Security and IPv6 advocate mind tells us to leave IPSec (at least v2) mandatory for all sections (not valid for mobile devices) and IPsec v3 optional. This would make sense from many points of view, but I (personally) cannot make up my mind if this is not too harsh prerequisite for this moment. Again, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
Sanders proposal above adds additional section for all devices (minus mobile), so we expand to "Mandatory", "Required" and "Optional". If I may repeat myself, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
So, if WG chairs allow, I would propose a "show of hands" and see, how we can proceed. (anyone who express clear support fo one of the options gets a candy at RIPE64 meeting in Ljubljana :) :) :) )
I am leaving for vacation now, so I'll eave it up to this WG to decide what to do with my input :-) Sander
Sander, have a good time and rest a bit :) V6 work for this year is done :)
Cheers, Jan Zorz
Hello... On Jan 2, 2012, at 11:23 PM, Eric Vyncke (evyncke) wrote:
Merike,
5 or 6 voices is indeed a too small sampling to be taken into account (even if I was one of those voices). No argument.
But, I am a little less comfortable with your sentence about 'operators who are using IPsec' because my understanding was that RIPE-501bis is for 'tender initiators' which are more likely to be enterprises, public sector organizations rather than operators.
Bad choice of words on my part. We would just like more input if possible to make sure we reflect the community consensus.
Else, thanks for the job on RIPE-501: very much needed but do not shoot for the stars
:) Yes, it does have to be based on reality. - merike
-éric
-----Original Message----- From: Merike Kaeo [mailto:merike@doubleshotsecurity.com] Sent: mardi 3 janvier 2012 01:48 To: Eric Vyncke (evyncke) Cc: Jan Zorz; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input.
Bottom posting will probably make this reply confusing so for now I'll just say that I tend to agree with my co-authors but we would like to hear more input from the RIPE community, especially the operators who are using IPsec in their IPv6 deployments (or plan to). six or seven voices seems like a small sampling.
Our hope is the get the final document done and back to last call in next few weeks so replies by the end of this week would be very much appreciated.
- merike
On Jan 2, 2012, at 6:08 AM, Eric Vyncke (evyncke) wrote:
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
-éric
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jan Zorz Sent: mercredi 28 décembre 2011 10:43 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input.
On 12/27/11 11:36 PM, Sander Steffann wrote:
I agree. We are writing a template for tender initiators for enterprises. I think we should state that IPSec is mandatory, because enterprises should have the possibility to set up IPSec site-to-site tunnels as a minimum. I think we should write it in such a way that enterprises require IPSec support when writing a request for tender, unless they consciously decide that they don't need it. So I think we should put IPSec in the 'required' section. If an enterprise knows it will not need it then they can move it to 'optional' themselves. RIPE-501 and its successor are templates to be used and adapted as necessary. We should provide a sane default, and they might (will probably?) need IPSec at some point in time.
Hi,
I somehow agree...
Disclaimer: RIPE community explicitly expressed the "wish" not to write anything radical into RIPE-501 bis/replacement document - I think Joao did that also publicly at Amsterdam meeting, and we received this suggestion a lot on and off-line.
Being said that, we might disregard all "radical" suggestions, such as "remove IPsec completely from the document" unless they are proven non-radical and that community (majority) feels in that way.
So, for that suggestion there is much more support needed from community than we can see it now. Supporters for "remove IPsec requirements completely", make yourself heard, otherwise be quiet for the rest of the time :) (we need to get this document out of the door ASAP, many governments (not joking) are waiting for replacement to take it as basis for their national IPv6 profile ;) )
We received many strong suggestions also off-list to go with the flow and follow IETF way - make it all optional for all devices (maybe with this option we could leave it out for mobile devices). Supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
Security and IPv6 advocate mind tells us to leave IPSec (at least v2) mandatory for all sections (not valid for mobile devices) and IPsec v3 optional. This would make sense from many points of view, but I (personally) cannot make up my mind if this is not too harsh prerequisite for this moment. Again, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
Sanders proposal above adds additional section for all devices (minus mobile), so we expand to "Mandatory", "Required" and "Optional". If I may repeat myself, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :)
So, if WG chairs allow, I would propose a "show of hands" and see, how we can proceed. (anyone who express clear support fo one of the options gets a candy at RIPE64 meeting in Ljubljana :) :) :) )
I am leaving for vacation now, so I'll eave it up to this WG to decide what to do with my input :-) Sander
Sander, have a good time and rest a bit :) V6 work for this year is done :)
Cheers, Jan Zorz
On 1/2/12 3:08 PM, Eric Vyncke (evyncke) wrote:
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
Eric, @all This question is now preventing the new draft to be published, as we think it's very important so solve it in a way, that makes sense and at the same time not to go against IETF and RFC specs. Sometimes this two clashes :) Community: Please, give us more input, so we can decide and write down something, that is what community thinks - otherwise we'll have to listen to sample of 6 voices. It's time to replace RIPE-501. Cheers, Jan
On 26 Jan 2012, at 08:50, Jan Zorz @ go6.si wrote:
On 1/2/12 3:08 PM, Eric Vyncke (evyncke) wrote:
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
Eric, @all
This question is now preventing the new draft to be published, as we think it's very important so solve it in a way, that makes sense and at the same time not to go against IETF and RFC specs. Sometimes this two clashes :)
Community: Please, give us more input, so we can decide and write down something, that is what community thinks - otherwise we'll have to listen to sample of 6 voices.
Jan, I agree pushing 501-bis asap should be a priority. Is there a pointer to the diffs between 501-bis and specific RFCs? Obviously I could go and look it up, just wondered if a list of differences already existed in a previous post or article. Tim
On Jan 26, 2012, at 6:22 AM, Tim Chown wrote:
On 26 Jan 2012, at 08:50, Jan Zorz @ go6.si wrote:
On 1/2/12 3:08 PM, Eric Vyncke (evyncke) wrote:
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
Eric, @all
This question is now preventing the new draft to be published, as we think it's very important so solve it in a way, that makes sense and at the same time not to go against IETF and RFC specs. Sometimes this two clashes :)
Community: Please, give us more input, so we can decide and write down something, that is what community thinks - otherwise we'll have to listen to sample of 6 voices.
Jan,
I agree pushing 501-bis asap should be a priority.
Is there a pointer to the diffs between 501-bis and specific RFCs? Obviously I could go and look it up, just wondered if a list of differences already existed in a previous post or article.
The issue right now is mostly only around IPsec and whether to have it be designated as mandatory or optional. The new IPv6 Node Requirements (RFC 6434) has the following language: "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Section 4.5 of [RFC4301]) 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]." I am starting to think that he language given by Eric above may be what gives us most consensus (and least controversy) :) - merike
On 1/26/12 5:18 PM, Merike Kaeo wrote:
On 1/2/12 3:08 PM, Eric Vyncke (evyncke) wrote:
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
I am starting to think that he language given by Eric above may be what gives us most consensus (and least controversy) :)
- merike
Me too... Jan
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
+1 Ivan
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
+1 Marco -- Marco Sommani Consiglio Nazionale delle Ricerche Istituto di Informatica e Telematica Via Giuseppe Moruzzi 1 56124 Pisa - Italia work: +390503152127 (PSTN and nrenum.net) mobile: +393487981019 (PSTN and e164.org) fax: +390503158327 mailto:marco.sommani@cnr.it
* Eric Vyncke:
Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory)
This change seems fine. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 12/27/11 11:36 PM, Sander Steffann wrote:
I agree. We are writing a template for tender initiators for enterprises. I think we should state that IPSec is mandatory, because enterprises should have the possibility to set up IPSec site-to-site tunnels as a minimum. I think we should write it in such a way that enterprises require IPSec support when writing a request for tender, unless they consciously decide that they don't need it. So I think we should put IPSec in the 'required' section. If an enterprise knows it will not need it then they can move it to 'optional' themselves. RIPE-501 and its successor are templates to be used and adapted as necessary. We should provide a sane default, and they might (will probably?) need IPSec at some point in time.
Hi, I somehow agree... Disclaimer: RIPE community explicitly expressed the "wish" not to write anything radical into RIPE-501 bis/replacement document - I think Joao did that also publicly at Amsterdam meeting, and we received this suggestion a lot on and off-line. Being said that, we might disregard all "radical" suggestions, such as "remove IPsec completely from the document" unless they are proven non-radical and that community (majority) feels in that way. So, for that suggestion there is much more support needed from community than we can see it now. Supporters for "remove IPsec requirements completely", make yourself heard, otherwise be quiet for the rest of the time :) (we need to get this document out of the door ASAP, many governments (not joking) are waiting for replacement to take it as basis for their national IPv6 profile ;) ) We received many strong suggestions also off-list to go with the flow and follow IETF way - make it all optional for all devices (maybe with this option we could leave it out for mobile devices). Supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :) Security and IPv6 advocate mind tells us to leave IPSec (at least v2) mandatory for all sections (not valid for mobile devices) and IPsec v3 optional. This would make sense from many points of view, but I (personally) cannot make up my mind if this is not too harsh prerequisite for this moment. Again, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :) Sanders proposal above adds additional section for all devices (minus mobile), so we expand to "Mandatory", "Required" and "Optional". If I may repeat myself, supporters for this option, make yourself heard, otherwise be quiet for the rest of the time :) So, if WG chairs allow, I would propose a "show of hands" and see, how we can proceed. (anyone who express clear support fo one of the options gets a candy at RIPE64 meeting in Ljubljana :) :) :) )
I am leaving for vacation now, so I'll eave it up to this WG to decide what to do with my input :-) Sander
Sander, have a good time and rest a bit :) V6 work for this year is done :) Cheers, Jan Zorz
Hi, Jan, On 12/23/2011 05:45 AM, Jan Zorz @ go6.si wrote:
The change was largely due to limitations found in low power devices and therefore we still feel the community is best served by requiring mandatory IPsec support in all other devices (hosts, routers or layer-3 switches, network security devices, load balancers)
While I have not followed the discussion that lead to MUST -> SHOULD in RFC6434 closely, I should say that it is well understood that the previous requirement of "MUST" was mostly "words on paper". Question: Does "requiring IPsec support in all other devices" mean "complying with RFC 4301"? If that's the case, you're also requiring those devices to support IKEv2. If that's intentional, I think you should make it explicit... Thanks, and Merry Christmas! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Hi Fernando.. On Dec 23, 2011, at 2:26 AM, Fernando Gont wrote:
Hi, Jan,
On 12/23/2011 05:45 AM, Jan Zorz @ go6.si wrote:
The change was largely due to limitations found in low power devices and therefore we still feel the community is best served by requiring mandatory IPsec support in all other devices (hosts, routers or layer-3 switches, network security devices, load balancers)
While I have not followed the discussion that lead to MUST -> SHOULD in RFC6434 closely, I should say that it is well understood that the previous requirement of "MUST" was mostly "words on paper".
Yes....there were many IPv6 capable devices without IPsec for many years. One of the comments made in the thread of Feb 2008 was that MUST or SHOULD wouldn't make much difference in getting implementations to appear. http://www.ietf.org/mail-archive/web/ipv6/current/msg09230.html
Question: Does "requiring IPsec support in all other devices" mean "complying with RFC 4301"? If that's the case, you're also requiring those devices to support IKEv2.
The intent right now is to add the following specifications for IPsec support • IPsec-v3 [RFC4301, RFC4303, RFC4302] * • IKE version 2 (IKEv2) [RFC5996 (obsoletes RFC 4306), RFC4718] * • ISAKMP [RFC2407, RFC2408,RFC2409] I have been seeing more shipping IKEv2 implementations in past few years and do believe most newer devices follow IPsec-v3 specs. Again, this is something authors would like to hear input on to make sure this is right thing to specify across all devices, regardless of whether IPsec will be mandatory or optional.
If that's intentional, I think you should make it explicit...
Agreed
Thanks, and Merry Christmas!
Happy Holidays..... - merike
Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Jan, Let's be realistic (and the best quality of RIPE-501++ is to be realistic and 'down to the ground'): very few IPv6-nodes do IPsec... So, let's remove this requirement and make it optional (RFC 6434 clearly shows the path). Going in holiday mode: do you use SSH or telnet+IPsec ? :-) In all friendship, Season's Greetings for all -éric
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: vendredi 23 décembre 2011 09:45 To: ipv6-wg@ripe.net Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input.
Dear IPv6 community.
(copy/paste from our internal discussion)
The authors of RIPE-501 are finalizing the last comments from previous last call and would like community input for what to do with IPsec. All authors feel that IPsec should be a mandatory requirement for all devices although due to technical limitations, for mobile devices it will be optional. We are aware that RFC6434 made IPsec support a SHOULD rather than a MUST.
From RFC 2119: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
The change was largely due to limitations found in low power devices and therefore we still feel the community is best served by requiring mandatory IPsec support in all other devices (hosts, routers or layer-3 switches, network security devices, load balancers)
If we get this input from you this year, there is a great chance that we could put out the new/final draft out for discussion and/or maybe last-last-call before new year.
For RIPE-501 authors group, Jan
P.S: wishing happy new year, merry xmass, happiness, IPv6 and all that stuff in at least next year :)
On 12/23/11 5:30 PM, Eric Vyncke (evyncke) wrote:
Jan,
Let's be realistic (and the best quality of RIPE-501++ is to be realistic and 'down to the ground'): very few IPv6-nodes do IPsec... So, let's remove this requirement and make it optional (RFC 6434 clearly shows the path).
Going in holiday mode: do you use SSH or telnet+IPsec ? :-)
I see your point :) so, +1 for all optional. What others think? And additional question: should we request IPsec-v3 or v2? Cheers, Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just my 2ct: I have 90% with IPSec but 0,000% IPv6 (whatever you think, fact, this is not happening in real life yet! we're peering, all set-up, but no single customer ever asked for?! Maybe there's still something wrong with IPv6? Both is yet freaky stuff, my cents: don't block the new freaky stuff (V6) with the old one (IPSec) which never got real.. in real life.. Michael On 23.12.2011 23:16, Jan Zorz @ go6.si wrote:
On 12/23/11 5:30 PM, Eric Vyncke (evyncke) wrote:
Jan,
Let's be realistic (and the best quality of RIPE-501++ is to be realistic and 'down to the ground'): very few IPv6-nodes do IPsec... So, let's remove this requirement and make it optional (RFC 6434 clearly shows the path).
Going in holiday mode: do you use SSH or telnet+IPsec ? :-)
I see your point :)
so, +1 for all optional.
What others think?
And additional question: should we request IPsec-v3 or v2?
Cheers, Jan
- -- Michael Markstaller Elaborated Networks GmbH www.elabnet.de - www.wiregate.de Lise-Meitner-Str. 1, D-85662 Hohenbrunn, Germany fon: +49-8102-8951-60, fax: +49-8102-8951-80 Geschäftsführer: Stefan Werner, Michael Markstaller Amtsgericht München HRB 125120, Ust-ID: DE201281054 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk71PBcACgkQaWRHV2kMuAJZWQCePRJmxG7iJ0tutVxTD3e8hNu2 uhYAnArGJ+wHZTQRZ+/sOQfRgfcoQ6DS =97pC -----END PGP SIGNATURE-----
On 24 dec. 2011, at 03:42, Michael Markstaller wrote:
Just my 2ct: I have 90% with IPSec but 0,000% IPv6 (whatever you think, fact, this is not happening in real life yet! we're peering, all set-up, but no single customer ever asked for?! Maybe there's still something wrong with IPv6?
How many customers call you and ask literally for "IPv4"? In my experience most customers ask for Internet connectivity and don't care about the protocol. Given the choice the customer probably wants a V12 "...'cause it goes faster!" :) Merry christmas to you all, Grtx, MarcoH (no hats) -- "Good tests kill flawed theories; we remain alive to guess again"
Hello and Happy Holidays to everyone.... On Dec 23, 2011, at 2:16 PM, Jan Zorz @ go6.si wrote:
On 12/23/11 5:30 PM, Eric Vyncke (evyncke) wrote:
Jan,
Let's be realistic (and the best quality of RIPE-501++ is to be realistic and 'down to the ground'): very few IPv6-nodes do IPsec... So, let's remove this requirement and make it optional (RFC 6434 clearly shows the path).
Going in holiday mode: do you use SSH or telnet+IPsec ? :-)
I see your point :)
so, +1 for all optional.
What others think?
Just to be sure we are all saying the same thing. Are we wanting to have IPsec be optional for *ALL* sections, so even for routers or layer-3 switches, network security devices, load balancers? 1. For CPEs we had this discussion [July 20-26, 2011 on this list] and the decision thus far was to do:
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"
2. For Mobile Devices it makes sense to put as optional since in my experience TLS is more often used for VPN scenarios. It would be great to know if that has changed. 3. For hosts, it probably also makes sense to have IPsec be optional since in the IETF discussions (which occurred in Feb - March 2088!!! on the IPv6 Maintenance WG mailing list) mostly since sensors and low end hosts (i.e. cable modems and also low end CPEs) would not want to deal with the code bloat. However, I will make a note that an IETF 'SHOULD' is not the same as optional. If it were optional it would be a 'MAY'. Also, at the time of the discussion there were talks about BTNS (Better Than Nothing Security) being a way to help solve some deployment issues - back in 2008 the standards were still just in draft stages. Check out hack.org/mc/blog/ which a friend provided a pointer to a few days ago. Seemed really interesting to me. With a better potential for DNS being used to transfer public keys and the fact that most OSs have IPsec capabilities, I just hope we are going to make the right practical decision for now. Folks on this list know best and we as authors will definitely reflect list consensus. 4. For routers and layer-3 switches, network security devices and load balancers I would expect the industry to want IPsec as mandatory but let's see what folks on list say.
And additional question: should we request IPsec-v3 or v2?
The thinking currently is that wherever we say we require IPsec (either for mandatory or optional), we would specify the following: • IPsec-v3 [RFC4301, RFC4303, RFC4302] * • IKE version 2 (IKEv2) [RFC5996 (obsoletes RFC 4306), RFC4718] * • ISAKMP [RFC2407, RFC2408,RFC2409] OR, are there any place where the updated IPsec standards do not make sense and we still want to specify - IPsec-v2 [RFC2401,RFC2406, RFC2402] ?? Thanks all... - merike
Cheers, Jan
Whoops....first go-around said 2088 for IETF IPv6 Maintenance wg discussions below....should obviously be 2008! - merike Hello and Happy Holidays to everyone.... On Dec 23, 2011, at 2:16 PM, Jan Zorz @ go6.si wrote:
On 12/23/11 5:30 PM, Eric Vyncke (evyncke) wrote:
Jan,
Let's be realistic (and the best quality of RIPE-501++ is to be realistic and 'down to the ground'): very few IPv6-nodes do IPsec... So, let's remove this requirement and make it optional (RFC 6434 clearly shows the path).
Going in holiday mode: do you use SSH or telnet+IPsec ? :-)
I see your point :)
so, +1 for all optional.
What others think?
Just to be sure we are all saying the same thing. Are we wanting to have IPsec be optional for *ALL* sections, so even for routers or layer-3 switches, network security devices, load balancers? 1. For CPEs we had this discussion [July 20-26, 2011 on this list] and the decision thus far was to do:
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"
2. For Mobile Devices it makes sense to put as optional since in my experience TLS is more often used for VPN scenarios. It would be great to know if that has changed. 3. For hosts, it probably also makes sense to have IPsec be optional since in the IETF discussions (which occurred in Feb - March 2088!!! on the IPv6 Maintenance WG mailing list) mostly since sensors and low end hosts (i.e. cable modems and also low end CPEs) would not want to deal with the code bloat. However, I will make a note that an IETF 'SHOULD' is not the same as optional. If it were optional it would be a 'MAY'. Also, at the time of the discussion there were talks about BTNS (Better Than Nothing Security) being a way to help solve some deployment issues - back in 2008 the standards were still just in draft stages. Check out hack.org/mc/blog/ which a friend provided a pointer to a few days ago. Seemed really interesting to me. With a better potential for DNS being used to transfer public keys and the fact that most OSs have IPsec capabilities, I just hope we are going to make the right practical decision for now. Folks on this list know best and we as authors will definitely reflect list consensus. 4. For routers and layer-3 switches, network security devices and load balancers I would expect the industry to want IPsec as mandatory but let's see what folks on list say.
And additional question: should we request IPsec-v3 or v2?
The thinking currently is that wherever we say we require IPsec (either for mandatory or optional), we would specify the following: • IPsec-v3 [RFC4301, RFC4303, RFC4302] * • IKE version 2 (IKEv2) [RFC5996 (obsoletes RFC 4306), RFC4718] * • ISAKMP [RFC2407, RFC2408,RFC2409] OR, are there any place where the updated IPsec standards do not make sense and we still want to specify - IPsec-v2 [RFC2401,RFC2406, RFC2402] ?? Thanks all... - merike
Cheers, Jan
* Eric Vyncke (evyncke) <evyncke@cisco.com> [2011-12-23 17:32]:
Jan,
Let's be realistic (and the best quality of RIPE-501++ is to be realistic and 'down to the ground'): very few IPv6-nodes do IPsec... So, let's remove this requirement and make it optional (RFC 6434 clearly shows the path).
+1 Happy Holidays! Sebastian -- New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
On 12/24/2011 12:57 PM, Sebastian Wiesinger wrote:
* Eric Vyncke (evyncke) <evyncke@cisco.com> [2011-12-23 17:32]:
Jan,
Let's be realistic (and the best quality of RIPE-501++ is to be realistic and 'down to the ground'): very few IPv6-nodes do IPsec... So, let's remove this requirement and make it optional (RFC 6434 clearly shows the path).
+1
Happy Holidays!
Sebastian
I'd have to +1 this also. Especially because of already mentioned low power devices (phones and tablets and such) Even though it would be nice to have it. Ragnar Belial Us
participants (16)
-
Eric Vyncke (evyncke) -
Fernando Gont -
Florian Weimer -
Ivan Pepelnjak -
Jan Zorz -
Jan Zorz ＠ go6.si -
Leo Vegoda -
Marco Hogewoning -
Marco Sommani -
Merike Kaeo -
Michael Markstaller -
S.P.Zeidler -
Sander Steffann -
Sebastian Wiesinger -
Tim Chown -
Us