[IPsec] Fw: New Version Notification for draft-katagi-ipsecme-clefia-00.txt
Hi all, I have submitted a new version of the Internet draft about using CLEFIA in IPsec and IKE. This draft is available at http://tools.ietf.org/html/draft-katagi-ipsecme-clefia-00. CLEFIA is a 128-bit block cipher, which is designed in 2007. The security of CLEFIA has been well evaluated through the CRYPTREC project for the revision of the e-Government recommended ciphers list in Japan. CLEFIA is also included in the Final Draft International Standard of ISO/IEC 29192-2 (Lightweight cryptography). CLEFIA offers high performance both in software and hardware. Especially, CLEFIA has advantages in efficient hardware implementation over AES. I believe that CLEFIA will contribute to efficiency of IPsec. Any feedback will be appreciated. Best regards, Masanobu Katagi Sony Corporation Forwarded by Masanobu Katagi masanobu.kat...@jp.sony.com --- Original Message --- From:internet-dra...@ietf.org internet-dra...@ietf.org To: Katagi, Masanobu masanobu.kat...@jp.sony.com Cc: Katagi, Masanobu masanobu.kat...@jp.sony.com, Moriai, Shiho shiho.mor...@jp.sony.com Date:Sat, 22 Oct 2011 15:26:28 +0900 Subject: New Version Notification for draft-katagi-ipsecme-clefia-00.txt A new version of I-D, draft-katagi-ipsecme-clefia-00.txt has been successfully submitted by Masanobu Katagi and posted to the IETF repository. Filename:draft-katagi-ipsecme-clefia Revision:00 Title: The CLEFIA Cipher Algorithm and Its Use with IPsec Creation date: 2011-10-22 WG ID: Individual Submission Number of pages: 14 Abstract: This document describes the use of the CLEFIA block cipher algorithm in conjunction with several different modes of operation within IKE and IPsec. The IETF Secretariat - Original Message Ends ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement
Yoav... the answer is either! Za needs to pass a packet to Host 2, it may be between a gateway, may be running IPSec itself, or may be unable to receive encrypted packets at all. As with RFC 4322, you would need a policy to determine behaviour when an encrypted channel can't be achieved, but the solution needs to enable Za to discover if there are available cryptographic routes, then make decisions based on the results combined with a policy. I hope that helps! Chris -Original Message- From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Sunday, October 23, 2011 10:37 PM To: Ulliott, Chris; Michael Richardson; ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Hi Chris As I've asked you off-list, I'm still trying to understand the initial condition. It's one thing if Za believes that host 2 is behind *some* gateway, and it's only a matter of finding out which gateway that is. It's a different thing if host 2 might also be not behind any gateway at all. In that case policy should either say that the packet should be dropped, or it should say that the packet should be forwarded unencrypted (BYPASS in RFC 4301 language). There is a subset of the Internet where Za can encrypt traffic. Is Za pre-configured with that subset? Yoav On 10/17/11 1:39 PM, Ulliott, Chris chris.ulli...@cesg.gsi.gov.uk wrote: The challenge for us is around discovery of the next cryptographic hop combined with the increase use of VoIP and other protocols that need peer to peer connectivity / low latency etc. If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway needs to perform a lookup to find out who it needs to establish an SA with before it can encrypt the packet and send it on its way. To my knowledge, there is not standard way of discovering this (although I'll happily be corrected!) For example... (and I hope the ASCII art works!) Host 1 -- R -- Za -- R -- R -- Zb -- R -- Host 2 (Where R is a router and Zx is a crypto) Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, but at this point Za needs to work out which remote endpoint to establish an SA with. In this case it's Zb - but the traditional way to achieve this is through static configuration which doesn't scale if you want to run fully meshed networks (we have thousands of nodes). When Zb received the packet it decrypts and forwards to Host 2. When you add resilience, this gets even more complicate, for example: Host 1 -- R -- Za -- R -- R -- Zb -- R -- Host 2 | Zc -- R --^ Packets for Host two can be sent via Zb or Zc, how does Za make that decision? In this example Zc is less hops away so would make more sense unless it wasn't available. Our interest also throws in the problem of multiple administrative domains. We have numerous sites, but IT is provisioned by differing integrators. Any standard should (in our opinion) enable this to still work. At the moment, commercial solutions for meshed VPN's assume that all the cryptographic devices are run by the same team. I hope that helps! Chris Communications with GCHQ may be monitored and/or recorded for system efficiency and other lawful purposes. Any views or opinions expressed in this e-mail do not necessarily reflect GCHQ policy. This email, and any attachments, is intended for the attention of the addressee(s) only. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmas...@gchq.gsi.gov.uk. This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to GCHQ on 01242 221491 ext 30306 (non-secure) or email info...@gchq.gsi.gov.uk The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by CableWireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement
It does. But then, both I and MCR agree that RFC 4322 in its present form is not the answer, but a second edition (as in rfc4322bis) might be. Do you think a discovery process based on DNS could be acceptable? I have never registered a domain, but I know how one could publish records for an FQDN. I have no idea how I (or an administrator) could get to add records to the reverse registry. RFC 4322 acknowledges this, and suggests an alternative - add the records to the FQDN of the host. But in general networking, we don't have FQDNs for hosts. Anyway, we seem to be doing the engineer thing of jumping right to the solution. We're currently at the problem statement phase. MCR: are you going to be in Taipei? Yoav On 10/24/11 1:52 PM, Ulliott, Chris chris.ulli...@cesg.gsi.gov.uk wrote: Yoav... the answer is either! Za needs to pass a packet to Host 2, it may be between a gateway, may be running IPSec itself, or may be unable to receive encrypted packets at all. As with RFC 4322, you would need a policy to determine behaviour when an encrypted channel can't be achieved, but the solution needs to enable Za to discover if there are available cryptographic routes, then make decisions based on the results combined with a policy. I hope that helps! Chris -Original Message- From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Sunday, October 23, 2011 10:37 PM To: Ulliott, Chris; Michael Richardson; ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Hi Chris As I've asked you off-list, I'm still trying to understand the initial condition. It's one thing if Za believes that host 2 is behind *some* gateway, and it's only a matter of finding out which gateway that is. It's a different thing if host 2 might also be not behind any gateway at all. In that case policy should either say that the packet should be dropped, or it should say that the packet should be forwarded unencrypted (BYPASS in RFC 4301 language). There is a subset of the Internet where Za can encrypt traffic. Is Za pre-configured with that subset? Yoav On 10/17/11 1:39 PM, Ulliott, Chris chris.ulli...@cesg.gsi.gov.uk wrote: The challenge for us is around discovery of the next cryptographic hop combined with the increase use of VoIP and other protocols that need peer to peer connectivity / low latency etc. If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway needs to perform a lookup to find out who it needs to establish an SA with before it can encrypt the packet and send it on its way. To my knowledge, there is not standard way of discovering this (although I'll happily be corrected!) For example... (and I hope the ASCII art works!) Host 1 -- R -- Za -- R -- R -- Zb -- R -- Host 2 (Where R is a router and Zx is a crypto) Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, but at this point Za needs to work out which remote endpoint to establish an SA with. In this case it's Zb - but the traditional way to achieve this is through static configuration which doesn't scale if you want to run fully meshed networks (we have thousands of nodes). When Zb received the packet it decrypts and forwards to Host 2. When you add resilience, this gets even more complicate, for example: Host 1 -- R -- Za -- R -- R -- Zb -- R -- Host 2 | Zc -- R --^ Packets for Host two can be sent via Zb or Zc, how does Za make that decision? In this example Zc is less hops away so would make more sense unless it wasn't available. Our interest also throws in the problem of multiple administrative domains. We have numerous sites, but IT is provisioned by differing integrators. Any standard should (in our opinion) enable this to still work. At the moment, commercial solutions for meshed VPN's assume that all the cryptographic devices are run by the same team. I hope that helps! Chris ** ** Communications with GCHQ may be monitored and/or recorded for system efficiency and other lawful purposes. Any views or opinions expressed in this e-mail do not necessarily reflect GCHQ policy. This email, and any attachments, is intended for the attention of the addressee(s) only. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmas...@gchq.gsi.gov.uk. This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to GCHQ on 01242 221491 ext 30306 (non-secure) or email info...@gchq.gsi.gov.uk ** ** The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by CableWireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement
I was not intending to be, (I have no ticket as yet), but plans might change. It seems like Chris has all of the requirements of OE, and there is all of the challenges. IPv6 and homenet might well provide FDQNs for hosts, and a trusted path to update the reverse. If DNS does not work for you, then you need another trusted introducer, and there have been many proposals out there for doing this kind of thing. None of taken off and hit the elbow of exponential growth. Yoav == Yoav Nir y...@checkpoint.com writes: Yoav It does. Yoav But then, both I and MCR agree that RFC 4322 in its present form is not Yoav the answer, but a second edition (as in rfc4322bis) might be. Yoav Do you think a discovery process based on DNS could be acceptable? I have Yoav never registered a domain, but I know how one could publish records for an Yoav FQDN. I have no idea how I (or an administrator) could get to add records Yoav to the reverse registry. RFC 4322 acknowledges this, and suggests an Yoav alternative - add the records to the FQDN of the host. But in general Yoav networking, we don't have FQDNs for hosts. Yoav Anyway, we seem to be doing the engineer thing of jumping right to the Yoav solution. We're currently at the problem statement phase. Yoav MCR: are you going to be in Taipei? Yoav Yoav Yoav On 10/24/11 1:52 PM, Ulliott, Chris chris.ulli...@cesg.gsi.gov.uk Yoav wrote: Yoav... the answer is either! Za needs to pass a packet to Host 2, it may be between a gateway, may be running IPSec itself, or may be unable to receive encrypted packets at all. As with RFC 4322, you would need a policy to determine behaviour when an encrypted channel can't be achieved, but the solution needs to enable Za to discover if there are available cryptographic routes, then make decisions based on the results combined with a policy. I hope that helps! Chris -Original Message- Yoav From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Sunday, October 23, 2011 10:37 PM To: Ulliott, Chris; Michael Richardson; ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Hi Chris As I've asked you off-list, I'm still trying to understand the initial condition. It's one thing if Za believes that host 2 is behind *some* gateway, and it's only a matter of finding out which gateway that is. It's a different thing if host 2 might also be not behind any gateway at all. In that case policy should either say that the packet should be dropped, or it should say that the packet should be forwarded unencrypted (BYPASS in RFC 4301 language). There is a subset of the Internet where Za can encrypt traffic. Is Za pre-configured with that subset? Yoav On 10/17/11 1:39 PM, Ulliott, Chris chris.ulli...@cesg.gsi.gov.uk wrote: The challenge for us is around discovery of the next cryptographic hop combined with the increase use of VoIP and other protocols that need peer to peer connectivity / low latency etc. If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway needs to perform a lookup to find out who it needs to establish an SA with before it can encrypt the packet and send it on its way. To my knowledge, there is not standard way of discovering this (although I'll happily be corrected!) For example... (and I hope the ASCII art works!) Host 1 -- R -- Za -- R -- R -- Zb -- R -- Host 2 (Where R is a router and Zx is a crypto) Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, but at this point Za needs to work out which remote endpoint to establish an SA with. In this case it's Zb - but the traditional way to achieve this is through static configuration which doesn't scale if you want to run fully meshed networks (we have thousands of nodes). When Zb received the packet it decrypts and forwards to Host 2. When you add resilience, this gets even more complicate, for example: Host 1 -- R -- Za -- R -- R -- Zb -- R -- Host 2 | Zc -- R --^ Packets for Host two can be sent via Zb or Zc, how does Za make that decision? In this example Zc is less hops away so would make more sense unless it wasn't available. Our interest also throws in the problem of multiple administrative domains. We have numerous sites, but IT is provisioned by differing integrators. Any standard should (in our opinion) enable this to still work. At the moment, commercial solutions for meshed VPN's assume that all the cryptographic devices are run by the same team. I hope that helps! Chris
Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)
At 8:15 PM -0600 10/19/11, Kevin Gross wrote: We don't need decrypt and encrypt to take the same amount of time. We need encrypt+decrypt from master to slave to take the same time as encrypt+decrypt from slave to master. That further reduces the likely variance that is algorithm or mode specific, but it does increase the potential for variance due to differences in the processing capabilities of masters and slaves. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)
On Tue, Oct 18, 2011 at 10:37 AM, Tim Frost tfr...@symmetricom.com wrote: I think most of the reviewers are missing the point of this draft. The point is not that the timing packets are inherently secret and need encryption, but that the 3GPP architecture mandates that EVERYTHING flowing to the femtocell must be inside a secure tunnel, whether the security is needed or not. It's a wider architecture issue, not the issue about whether encryption is needed and how best to do it. Everything?? Some bits can't be in a tunnel. For example, the outer IP headers. Obviously some bits of IKE also go in the clear. What exactly is everything intended to encompass? It can't be truly all bits. At most it can only be all bits that can be tunneled. I don't see why timing signals need to be protected by IPsec if they can carry their own cryptographic protection. I know very little about IEEE 1588 (PTP), but if there's any way that it can provide its own security protocol[*] then I think it'd be fair to keep PTP out of the everything that must be tunneled. OTOH, if PTP lacks sufficient security functionality, then my suggestions would be to either use NTP or else we'll all have to hold our noses for the proposed solution. Is PTP mandated for Femtocell as well? [*] The paper Security Flaws and Workarounds for IEEE 1588 (Transparent) Clocks by A. Treytl and B. Hirschler tells me that PTP does have a secure mode and that it's not very good. Have those issues been addressed since? Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)
On Mon, Oct 24, 2011 at 1:38 PM, Doug Arnold darn...@symmetricom.com wrote: This debate has been going on since before the PTP v2 standard was released, and the consensus in the timing community agrees with you. Timing packets do not need to be encrypted. Authentication would be a more appropriate security mechanism, since time is not a secret. There is even an experimental authentication mechanism in the standard, as you suggested (See Annex K of IEEE 1588-2008). Nevertheless, there is a requirement for PTP over IPsec. The reason is that some system architects/admins want to have a policy that all packets go through the IPsec tunnel. We timing geeks like to think of PTP as special, but to many system architects it is just one of many management protocols that run on their network. They don't want the complexity of making an exception for one protocol. There's no reason to agree to a bad architecture just because it appears to be written in stone. Agreeing to document it on account of its being deployed is another story, but there's no requirement that we do that either. Timing packets *should* need no more protection than the outer IP headers on an IPsec-protected packet (hello) or than the cleartext bits of IKE. Some things have to go in the clear. So much so -so much so!- that the proposal on the table is to make enough of the timing packets go in the clear that the end nodes can get more accurate time. Imagine that. What better proof is there that the architecture is broken? But does PTP need protection? Or would it need any modifications/extensions to make it safe to use without IPsec? You didn't clarify this. It may well be easier for IPsecme WG and the IETF to agree to the proposal than it would be to fix PTP if it needs fixing, but it'd be nice if we could establish that too. This is the sort of homework that the proposal's proponents should be doing. TICTOC could make a big push to educate the system architects that ptp should not be encrypted. We could even convert some of them, but not all of them. The only thing that could kill this requirement is if we convincingly show that ptp over IPsec could absolutely not be made to work in wireless backhaul networks. I don't think that such an argument is forthcoming. If TICTOC WG won't say no then the maybe IPsecme WG, the IETF, and/or the IESG will. I guess we're about to find out what IPsecme thinks of this. GET OVER IT EVERYONE, THE REQUIREMENT FOR PTP OVER IPsec IS NOT GOING AWAY! We need to figure out how to make it work as well as it can. There is no requirement that the IETF rubber-stamp this either. Using caps won't help achieve consensus. Now that the issue is clear, I think we could actually work towards establishing consensus on one or another proposals, or even simply show that there's consensus for none if that's what happens. As part of this process it'd be useful to find out what the process might be to change the femtocell architecture so as to remove the requirement that timing packets be encrypted. What if the IETF consensus is that the femtocell architecture should be changed? Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
