Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

Hi Dan, On May 4, 2011, at 9:47 PM, Dan Harkins wrote: > > On Tue, May 3, 2011 10:30 pm, Yoav Nir wrote: > [snip] >> The Authenticator needs the true identity to make policy decisions. > > Well then DO NOT use EAP for authentication. > > Dan. I'm sure I don&

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

On May 4, 2011, at 11:45 PM, Dan Harkins wrote: > > RFC 5996 says in section 2.16: > > "When the initiator authentication uses EAP, it is possible that the > contents of the IDi payload is used only for Authentication, > Authorization, and Accounting (AAA) routing purposes and selecting

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

On May 5, 2011, at 9:17 AM, Dan Harkins wrote: > > Hello, > > On Wed, May 4, 2011 10:45 pm, Yoav Nir wrote: >> >>> >> >> OK. I see what you mean. Certificates are not necessarily better. She >> might have a certificate with a subject like >

Re: [IPsec] Clarification needed on ipv6 address assignment

Hi Balaji.J For the most part, a VPN gateway uses sufficiently few addresses (hundreds or a few thousands) that IPv6 is not necessary. This is the reason that there was little interest in changing the way IPv6 addresses are assigned in CONFIG payloads. There's also the idea that with IPv6 ther

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

On May 5, 2011, at 11:41 PM, Yaron Sheffer wrote: Hi, I think we are going down a rathole on the issue of "authenticated identity". Most IKE gateways, like many other security devices, normally make policy decisions based on groups. I will provide secure connectivity to anyb...@this-isp.com

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

On May 7, 2011, at 3:42 AM, Qin Wu wrote: > > >> >> It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 >> ever intended (in fact I believe the text is new to RFC 5996). Presumably, >> when we talk about identity-based policy decisions, we refer to >> http://tools.iet

Re: [IPsec] IPSec implementation

IPsec usually runs in kernels, so C seems to be the norm I'm not aware of any C++ implementations. On Jun 1, 2011, at 9:23 AM, Muhammad Nasir Mumtaz Bhutta wrote: > hi, > i need to change the IPSec functionality, is there any implementation of > IPSec in higher order languages like java, .net

Re: [IPsec] DH keys calculation performance

On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: > Hello, > > The DH exchange (Calculation of Public/Private key and the Secret) in > IKEV2 Initial exchange > seems to be very expensive. This is slowing down the overall IKEv2 > tunnel establishment. > Is there a way to optimize it?

Re: [IPsec] DH keys calculation performance

On Jul 26, 2011, at 11:13 AM, Scott Fluhrer (sfluhrer) wrote: > > >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Yoav Nir >> Sent: Tuesday, July 26, 2011 6:40 AM >> To: Prashant Batra (prbatra)

Re: [IPsec] IPsecme WG: a quick update

Alright, here's one. http://tools.ietf.org/html/draft-nir-ipsecme-erx-01 defines an extension to IKEv2 so that ERX (as defined by the HOKEY group) can be used with IKEv2. This will allow a seamless transfer from a local network protected by 802.1x to a public network where your access needs to

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

I think this is a terrible idea. IKEv2 has a way for mutual authentication with a shared key. A concern was raised that this method was vulnerable to guessing if trivial shared keys were configured. There were several proposals for a better cryptographic method. The IPsecME working group fail

Re: [IPsec] Role of the IANA expert reviewer

On Aug 2, 2011, at 5:43 PM, Paul Hoffman wrote: > I have stated my reasons why I consider allocating multiple payload numbers etc for exactly same thing a bad thing. >>> >>> The three proposals do not do "exactly the same thing": they each >>> have different cryptographic and administ

Re: [IPsec] Role of the IANA expert reviewer

On 8/3/11 4:55 PM, "Tero Kivinen" wrote: >Yoav Nir writes: >> There is no such consensus that protocol variants are a good thing. >> I think it's just the opposite. Although I don't think it's Tero's >> job to stop the publication of thr

Re: [IPsec] Role of the IANA expert reviewer

On Aug 3, 2011, at 8:09 PM, Yaron Sheffer wrote: > Hi Yoav, > > as a coauthor on one of these documents, I find your proposal below > positively insulting. There were three author teams, and you should give > them credit for having rational reasons for publishing these documents > and moving

[IPsec] IKEv2 and ERP

Hi At the meeting in Quebec, I gave a presentation at the hokey meeting about http://tools.ietf.org/html/draft-nir-ipsecme-erx . The draft covers using the EAP extensions for re-authentication in IKEv2. The obvious (to me) use-case is a phone connected to a 802.1x network. As you leave the bui

Re: [IPsec] Perfect Forward secrecy

indly share your view on the above . > >Thanks and Regards >Naveen > >-Original Message----- >From: Scott Fluhrer (sfluhrer) >Sent: Friday, August 26, 2011 7:27 PM >To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir' >Cc: 'ipsec@ietf.org' >

[IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

Hi all For years, one of the barriers to the adoption of IPsec was that configuration didn't scale. With thousands of peers, the PAD and SPD would become unwieldy, so even where IPsec was deployed it was often built in hub-and-spoke configurations, not because policy demanded this, but because it

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

cs/ios/12_0t/12_0t5/feature/guide/ted.html > > Dan. > >On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: >> Hi all >> >> For years, one of the barriers to the adoption of IPsec was that >> configuration didn't scale. With thousands of peers, the PAD and SPD

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

hat it is missing in IKEv1 is a way to turn the host<->host tunnels >into subnet<->subnet tunnels, and that would be easy to do in IKEv2 with >the TS. > > >>> Sounds like TED: > >> >>> >http://www.cisco.com/en/US/docs/ios/12_0t/12_0

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

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

ryptographic 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;

Re: [IPsec] eap-md5 based authentication

Hi Prashant. I think in the challenge request, the first byte is the challenge length (usually 16) followed by the challenge itself, and then followed by some server name. I guess the reasoning is that this allows the client to choose the correct password based on the server name. Yoav __

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

Chris' case is a little different, because he is willing to do some work to establish trust between the two administrative domains, so it's not really opportunistic (although doing it with OE might be a solution) So there could be some "hub gateway" that could do the introducing, perhaps over I

Re: [IPsec] eap-md5 based authentication

henticated. > >Maybe, it is required for some extra authentication? > >Regards, >Prashant > >-Original Message- >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >Of Glen Zorn >Sent: Tuesday, October 25, 2011 3:46 PM >To: Yoav Nir >Cc: ipsec@ie

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

This goes back to my previous question. What is this information that is "known to hub and all spokes" ? If the spoke knows what addresses are behind each other spoke, then we lose the scalability - that's a lot of configuration up front. If the spoke only knows the union of all addresses behin

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

On 10/26/11 9:39 PM, "Yaron Sheffer" wrote: >There is a common use case where we don't worry about malicious spokes, >i.e. where they are all trusted. > >We do worry about misconfigured spokes, but that would most likely >result in loss of connectivity, which I expect to be fixed in due time. >

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

Well, there is a free room between 1300-1500 on Wednesday, but then we're opposite WebSec, and I can't attend. Our best bet is to do it after the Plenary. The plenary ends at 19:30, and people might want to grab something to eat, so it would probably be best to do it at 20:00. Hope you don't h

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

OK. So DNSSEC is off the table. At least for now. At least with Chris's scenario, we can assume that there's an "administrative domain" that includes a "hub" and some "spokes". This "hub" has information about the addresses protected by each of the "spokes", so it makes sense that it will do the

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

On 10/31/11 3:30 PM, "Michael Richardson" wrote: > >> "Jorge" == Jorge Coronel writes: >Jorge> +1 > >Jorge> I agree DNSSEC cannot be assumed, its deployments have been >Jorge> marginal. > >DNSSEC is *one* *public* trusted third party. It's not the only way to >use DNS securely

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

of doing this as long as all gateways are from that vendor, but some government users (represented by Chris Ulliot) are not willing to lock their entire government infrastructure to a single vendor. > >On Oct 29, 2011, at 3:34 PM, Yoav Nir wrote: > >> OK. So DNSSEC is off the table

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

On 11/1/11 7:49 PM, "Paul Wouters" wrote: >On Tue, 1 Nov 2011, Yoav Nir wrote: > >> >> On 11/1/11 4:53 PM, "Mark Boltz" wrote: >> >>> I agree with Paul H. that the term "encryption domain" is not really >>> fully correct

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

On 11/1/11 7:51 PM, "Keith Welter" wrote: >>Having been working for the same vendor for 10 years, I've gotten used to >> our marketing jargon. Anyway, I'd like to have some short term for the >> set of addresses that are behind a certain gateway", or "the set of >> addresses that you can reach th

Re: [IPsec] Comments on the new meshed VPN draft

Hi Yaron Sorry for taking so long to respond. My comments inline. On Oct 14, 2011, at 11:37 AM, Yaron Sheffer wrote: > I am going on vacation, but I did want to post these before. Sorry if I > cannot take part in the ensuing discussion. > Overall, this is a good start for an important set of pr

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

On 11/7/11 9:44 PM, "Michael Richardson" wrote: > >> "Praveen" == Praveen Sathyanarayan writes: >Praveen> In this solution, HUB is the trust entity that all spoke >Praveen> establish static IPSec tunnel (either using Site to site >Praveen> tunnel or spoke establish dynamic remo

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

On 11/7/11 10:19 PM, "Michael Richardson" wrote: > >>>>>> "Yoav" == Yoav Nir writes: >Yoav> I don't see how DNS figures into this. We have three >Yoav> gateways: - hub-gw, which knows the protected domains of >Yo

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

On 11/7/11 11:46 PM, "Michael Richardson" wrote: > >>>>>> "Yoav" == Yoav Nir writes: >Yoav> I don't see how DNS figures into this. We have three >Yoav> gateways: - hub-gw, which knows the protected domains of >Yo

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

e - 发件人: ipsec-boun...@ietf.org<mailto:ipsec-boun...@ietf.org> [mailto:ipsec-boun...@ietf.org] 代表 Yoav Nir 发送时间: 2011年10月14日 13:24 收件人: ipsec@ietf.org<mailto:ipsec@ietf.org> 主题: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Hi all For years, one o

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

In that case, would RFC 4322 solve your problem? It is based on DNS. From: Michael Ko [mailto:mich...@huaweisymantec.com] Sent: 08 November 2011 03:54 To: Yoav Nir; ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

unication from hub-gw to spoke32 >would be something like: "to get to 192.168.79.0/24, go to spoke79." > >-geoff > >-Original Message- >From: m...@sandelman.ca [mailto:m...@sandelman.ca] >Sent: Monday, November 07, 2011 10:46 PM >To: Yoav Nir >

[IPsec] P2P-VPN draft and side meeting

Hi all I am glad to see the great volume of comments about our draft. However, we do seem to be talking about too many things at the same time. The problems people are talking about can be divided into two broad categories: - Setting up tunnels between perfect strangers. - Setting up tunnels wher

Re: [IPsec] P2P-VPN draft and side meeting

gt; Yoav, > > I'd be happy to do the Juniper presentation. > > -geoff > > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Yoav Nir > Sent: Wednesday, November 09, 2011 11:26 AM > To: ipsec@ietf.org > S

Re: [IPsec] P2P-VPN draft and side meeting

Also, who's going to present for Cisco? On Nov 13, 2011, at 10:49 PM, Yoav Nir wrote: > Cool. You can use slides, or just handwave. Whatever works for you. > > Too bad IETF rooms don't come with whiteboards. > > If you are making slides, please send them to

[IPsec] P2P VPN - Side Meeting

Hi all This is to announce a side meeting about peer to peer VPN, as described in our recently published draft: http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 In the meeting we will discuss the use case of directly connecting two IKE implementations that already have a path of trust betwee

Re: [IPsec] Does ESP provide all functionality offered by AH?

What Paul said, mostly, but see below. On Nov 15, 2011, at 2:39 AM, Paul Wouters wrote: > On Sun, 13 Nov 2011, Vilhelm Jutvik wrote: > >>> From page 62, RFC 4301: >> >> ... >> 4. Apply AH or ESP processing as specified, using the SAD entry >> selected in step 3a above. Then match the packet

Re: [IPsec] P2P VPN - Side Meeting

Hi Frederic Inline... On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: > Hi Yoav, > > We will be there (following offline with you for the details). > > I do not think there is a need to spend 20 minutes on the draft which > everyone should have read. There are three vague points in it

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

Hi Mark I see that you're not at the IETF. Will you be following the meeting through Jabber and (hopefully) audio? Anyway, GRE and NHRP are standardized protocols that could be used as part of a large scale solution. I don't (personally) believe that they are as scalable as other solutions we

Re: [IPsec] P2P VPN - Side Meeting

On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote: > > On 15 Nov 2011, at 12:05, Yoav Nir wrote: > >> Hi Frederic >> >> Inline... >> >> On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: >> >>> Hi Yoav, >>> &

Re: [IPsec] P2P VPN - Side Meeting

Hi Mike On Nov 15, 2011, at 6:25 PM, Mike Sullenberger wrote: > Hi Yoav, > >Please see inline. > > Mike. > >> On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote: >> >>> >>> On 15 Nov 2011, at 12:05, Yoav Nir wrote: >>> >>

Re: [IPsec] P2P VPN - Side Meeting UNCLASSIFIED

On Nov 15, 2011, at 7:36 PM, Ulliott, Chris wrote: > Classification:UNCLASSIFIED > > The problem with a single SA is that it usually means a single key (what ever > form that takes) such that a compromise of a single spoke puts all traffic at > risk... So what ever solution we go for - we need

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

On Nov 15, 2011, at 10:52 PM, Michael Richardson wrote: > >> "Mark" == Mark Boltz writes: >Mark> With all due respect to Cisco, the larger problem we're trying >Mark> to address, is in part the fact that DMVPN and ACVPN are >Mark> vendor specific implementations. And the goal of

Re: [IPsec] P2P VPN - Side Meeting

On Nov 16, 2011, at 9:32 AM, Tero Kivinen wrote: >> What you call other fancy features is what I call functional separation. >> IPsec does encryption well, but in reality it does a fairly poor job of >> tunneling. So lets have IPsec do what it does well and have GRE do what >> it does well and th

Re: [IPsec] P2P VPN - Side Meeting

On Nov 16, 2011, at 1:45 PM, Tero Kivinen wrote: > Yoav Nir writes: >>> So you still didn't explain what GRE does better than modern IPsec >>> tunneling? >> >> I think GRE (or any tunnel that is not IPsec - like L2TP) allows >> them to avoid having to

Re: [IPsec] P2P VPN - Side Meeting

tures that protect a network and routing as > a security policy really is not a problem until shown otherwise. > > Again, I urge you to be specific because there is nothing tangible in your > claims. I understand what you mean but if you rationalized it, you would see > your intuit

Re: [IPsec] P2P VPN - Side Meeting

On Nov 16, 2011, at 3:31 PM, Tero Kivinen wrote: > Frederic Detienne writes: >> Again, I urge you to be specific because there is nothing tangible >> in your claims. I understand what you mean but if you rationalized >> it, you would see your intuition fools you. > > When one does not know what

Re: [IPsec] P2P VPN - Side Meeting

x.com/u/28687906/P2P-VPN-PDF.zip During the Plenary meeting (16:30-19:30 local time) I will be in the Jabber room most of the time, so if you remote participants want to test it, and say hi, go ahead. Otherwise see y'all at 20:00 in room 101D. Yoav On Nov 14, 2011, at 10:09 AM, Yoav Nir wr

Re: [IPsec] P2P VPN - Side Meeting

On Nov 16, 2011, at 3:38 PM, Tero Kivinen wrote: > Frederic Detienne writes: >>> Frederic Detienne writes: And like I said earlier, the amount of negotiation when there are multiple prefixes to protect is limited to one. With "modern ipsec tunneling" (got to love that), there is st

[IPsec] P2P-VPN - Side Meeting - Announcement

ts want to test it, and say hi, go ahead. Otherwise see y'all at 20:00 in room 101D. Yoav On Nov 14, 2011, at 10:09 AM, Yoav Nir wrote: > Hi all > > This is to announce a side meeting about peer to peer VPN, as described in > our recently published draft: > http://tools.i

Re: [IPsec] P2P VPN - Side Meeting

teve > >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Frederic Detienne >> Sent: Wednesday, November 16, 2011 4:24 AM >> To: Yoav Nir >> Cc: ipsec@ietf.org WG; Tero Kivinen; Mike Sullenberger &g

Re: [IPsec] P2P VPN - Side Meeting

On Nov 17, 2011, at 2:17 AM, Michael Richardson wrote: > >Mike> I am not sure where you are getting a set of extended >Mike> access-lists. There aren't any extended access-lists added. >Mike> If a packet is routed through the tunnel it is encapsulated >Mike> and then encrypted. T

Re: [IPsec] P2P VPN - Side Meeting

On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote: > On Thu, 17 Nov 2011, Yoav Nir wrote: > >> Not necessarily. If your device drops packets that come through the "wrong" >> tunnel, you're safe. Typically in a complex network you will allow multiple >> path

Re: [IPsec] P2P VPN - Side Meeting

On Nov 18, 2011, at 2:06 AM, Nico Williams wrote: > On Wed, Nov 16, 2011 at 8:17 PM, Yoav Nir wrote: >> On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote: >>>> But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs >>>> are static, so there is

Re: [IPsec] Notes from P2P VPN Side Meeting

psec email list. > > After a bit of monkeying around with audio and > video issues, Yoav Nir gave a brief presentation > on the Problem Statement draft. This was followed > by equally brief presentations on the Cisco, > Juniper, and Checkpoint solutions for P2P VPN > fro

Re: [IPsec] IKEv2 and ERP

On Aug 6, 2011, at 10:37 PM, Yoav Nir wrote: > Hi > > At the meeting in Quebec, I gave a presentation at the hokey meeting about > http://tools.ietf.org/html/draft-nir-ipsecme-erx . > > The draft covers using the EAP extensions for re-authentication in IKEv2. The > obviou

Re: [IPsec] IKEv2 and ERP

be over the open Internet. Lastly, judging by the level of interest so far, I do not see this draft becoming an ipsecme WG charter item. I do not have any problem with its being published elsewhere. Thanks, Yaron On 11/19/2011 02:07 PM, Yoav Nir wrote: On Aug 6, 2011, at 10:37 PM, Yoav Nir wro

Re: [IPsec] Add new protocols that require AH?

Hi Jack On Nov 23, 2011, at 1:24 AM, Jack Kohn wrote: > As per RFC 4301 implementing AH is a MAY and ESP a MUST. Given that > most of what is achieved by AH can be easily achieved by ESP-NULL, is > there a possibility that AH may get deprecated in the future. Should > new protocols or mechanisms

Re: [IPsec] IKEv2 and ERP

RP in those cases? Yoav From: Qin Wu [mailto:bill...@huawei.com] Sent: 22 November 2011 10:07 To: Yoav Nir; Yaron Sheffer Cc: IPsecme WG; ho...@ietf.org Subject: Re: [IPsec] IKEv2 and ERP Hi,Yoav: yes,I am do aware of other cases where IKE is used beyond the

Re: [IPsec] Contradiction in RFC5996

Hi Valery I believe that you are correct. The text in section 2.25 clearly says that the SPI field is populated, while section 3.10 says that this field is populated only for INVALID_SELECTORS and REKEY_SA. Section 3.10 was carried over from RFC 4306, while section 2.25 is new to 5996. The er

Re: [IPsec] [Technical Errata Reported] RFC5996 (3036)

+1 On Nov 27, 2011, at 6:19 AM, Charlie Kaufman wrote: > I believe this errata should be marked "Verified". This is pretty clearly a > case where the document was updated in one place and a needed corresponding > update in another place was missed. > > --Charlie > > -Original Messag

Re: [IPsec] Preparing a charter change for P2P VPN

On Nov 21, 2011, at 10:09 PM, Stephen Hanna wrote: > The conclusion of Wednesday night's P2P VPN side meeting > was that we would start a new thread on the proposed > ipsecme charter change and resolve the open questions > by email. Let's start off with the text that came out > of Wednesday's mee

Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

On Nov 29, 2011, at 2:38 AM, Paul Hoffman wrote: > > On Nov 28, 2011, at 4:11 PM, Michael Ko wrote: > >> I agree that discovery is one of the issues that should be explored. Due to >> the dynamic nature, automated discovery is an important requirement for the >> user to set up a secure conne

[IPsec] Large Scale VPN

Hi all. The discussion has died down a bit, so I thought I'd chime in with proposed charter text. What do people think of the following? The first paragraph is taken from Steve's email of 18-Nov. Yoav In an environment with many IPsec gateways and remote clients that share an established tr

Re: [IPsec] Large Scale VPN

On Dec 8, 2011, at 6:04 PM, Paul Hoffman wrote: > > On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote: > >> In an environment with many IPsec gateways and remote clients that share an >> established trust infrastructure (in a single administrative domain or >> across m

Re: [IPsec] Large Scale VPN

On Dec 8, 2011, at 8:14 PM, Yaron Sheffer wrote: > We as a group can commit to deliverable #1 and #3 (problem statement and > standardized solution). But deliverable #2 (vendor protocols) is mostly > out of our hands. That's why I used "review" and "help" rather than "write" or "produce". > S

Re: [IPsec] Large Scale VPN

uld use ternary logic", or "+1" is all it takes. Yoav On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: > > Agree. How about: > > In an environment with many IPsec gateways and remote clients that share an > established trust infrastructure (in a single admini

Re: [IPsec] Large Scale VPN

>> If we want Paul and Yaron to take this to our AD, we need to show >> that there are more people who think these work items are a good >> idea. More people than just me and MCR. So please show your >> support (or objections!) soon. An "I think this is a g

Re: [IPsec] Question about ECDSA cert usage for IKEv2 auth

On Dec 22, 2011, at 9:07 PM, Gaurav Poothia wrote: Hello, The basic IKEv2 cert auth mechanism for RSA (from RFC 5996) seems to be to hash using SHA-1 before signing. However when using ECDSA certs for IKEv2 I am trying to make sure I am reading RFC 4754 correctly when it says the following: “M

Re: [IPsec] Moving Authentication Header (AH) to Historic

On Dec 29, 2011, at 9:25 PM, Melinda Shore wrote: > It seems to me that the NAT problem is a *NAT* problem, not an AH > problem. I disagree with this. Section 3.3.3.1.1.1 of RFC 4302 lists source IP address and destination IP address as immutable fields. This may be true in some idealized Inte

Re: [IPsec] Avoiding Authentication Header (AH) (was Moving Authentication Header (AH) to Historic)

On Jan 2, 2012, at 2:11 AM, Michael Richardson wrote: > > This property is simply undesireable for many security systems, > including all VPNs. > > Having said all of this, I agree that for 99% of "Use IPsec" > statements, ESP-NULL is likely the correct choice. I don't think you actually m

Re: [IPsec] Avoiding Authentication Header (AH)

On Jan 5, 2012, at 4:37 PM, Bhatia, Manav (Manav) wrote: > >> Getting WESP implemented to the boxes will require a lot of time. >> There are still lots of boxes which do not even support IKEv2 (which is >> required for >> WESP) and IKEv2 has been out for 6 years already. AH might already be >

Re: [IPsec] Starting work on our new charter items

On Jan 20, 2012, at 12:43 AM, Paul Hoffman wrote: > We have a new charter. Do we have any volunteers to start work on the two > documents we committed to work on? I think it's premature to start work on the solutions document, but it is time to start work on the problem statement document. I'

Re: [IPsec] query related to rekey

On Jan 20, 2012, at 10:49 PM, Nico Williams wrote: > > - assume that the initiator of a CREATE_CHILD_SA exchange is NOT > ready to receive ESP/AH on the new SA SPI until the initiator sends a > DELETE payload deleting the old SA SPI, so the responder should NOT > send on the new SA until it gets

Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt

Hi Zaifeng Reading your draft, I'm trying to understand the problem you are solving. It is about the FAP being compromised and sending false information through the tunnel. What is the malicious FAP lying about? How does sending some information (does "notarized" mean "signed"?) from the SeGW

Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt

n] Sent: 21 January 2012 11:08 To: Yoav Nir Cc: ipsec@ietf.org Subject: 答复: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Hi Yoav: Thank you for your email. Regarding to your question on "what is the malicious FAP lying about", I would

Re: [IPsec] IKEv2 Traffic Selector narrowing questions

On Feb 13, 2012, at 3:26 PM, Paul Wouters wrote: > On Sun, 12 Feb 2012, Scott Fluhrer (sfluhrer) wrote: > >>> a) What should the initiator do with packets that suddenly fall >> outside >>>the new narrowed proposal? drop them? send them in plain text? >>>(in other words, I'm trying to def

Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem

On Feb 13, 2012, at 10:23 PM, Paul Wouters wrote: > Hi, > > There are many IPsec related standards, and I was hoping to use the > combined experience of the list to tell me if in fact, these new apple > devices have a bug, or whether it is an RFC or draft anywhere. > > When using L2TP/IPsec m

Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem

On Feb 16, 2012, at 4:11 PM, Tero Kivinen wrote: > Paul Wouters writes: >> On Mon, 13 Feb 2012, Yoav Nir wrote: >> >>>> When using L2TP/IPsec mode with IKEv1, the latest iphones/OSX machines, >>>> when on public IP, and when no NAT is detected, send UDP_E

Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem

On Feb 16, 2012, at 4:43 PM, Paul Wouters wrote: > On Thu, 16 Feb 2012, Yoav Nir wrote: > >>> Are you really telling me they are using a private numbers from the >>> internet draft that expired more than 10 years ago, and which is not >>> compatible with the RF

[IPsec] P2P VPN Problem Statement - why is this hard?

Hi Steve On Mar 6, 2012, at 11:54 PM, Stephen Hanna wrote: > So please review this short document and send comments. While the draft does a good job of describing use cases, and certain inadequate solutions, I think it's missing a description of why this is hard. Even if we accept the solution

Re: [IPsec] P2P VPN Problem Statement - why is this hard?

the hub > constantly needs to be reconfigured. So it's really the same problem in > a more limited form. > > Thanks, > Yaron > > On 03/07/2012 12:54 AM, Yoav Nir wrote: >> Hi Steve >> >> On Mar 6, 2012, at 11:54 PM, Stephen Hanna wrote: >&

Re: [IPsec] P2P VPN draft

I like it. On Mar 7, 2012, at 11:52 PM, Ulliott, Chris wrote: > Classification:UNCLASSIFIED > > How about "dynamic mesh VPNs" as a title as I think the dynamic part is key > here and probably an important aspect of the use cases. > > Chris > > [This message has been sent by a mobile device] >

Re: [IPsec] P2P VPN draft UNCLASSIFIED

On Mar 14, 2012, at 12:05 AM, Mark Boltz wrote: > I like Juniper's suggestion of "auto mesh VPNs", although other options may > be available. I think that dynamic is a good word, but I'd rather anything > that can distill to an acronym that would be too ambiguous with DMVPN. Or any > other ter

Re: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00

On Mar 14, 2012, at 8:00 AM, Tero Kivinen wrote: > In section 2.1 where there is dicsussion about the endpoint to > endpoint vpn use case, it should be noted, that this might require > different temporary credentials. Endpoints (especially remote access > users) do use passwords or similar creden

Re: [IPsec] P2P VPN draft UNCLASSIFIED

As Tero pointed out, some of the use cases don't end up in a full mesh, because sometimes administrators really want a trunk, so the end result could be a mesh among nodes in the same organization, and a trunk to another. Maybe even a partial mesh (with "secondary nodes" behind particularly bad

Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible

"direct endpoint-to-endpoint connectivity may not be possible if both endpoints are NATed" Why? There are several protocols (SIP/RTP come to mind) that manage endpoint-to-endpoint connectivity even when both are behind NAT. Why shouldn't IPsec endpoints do this? If this requires some new NAT

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

I agree that this pre-supposes that the solution will involve "gateways" figuring things out for "endpoints" in either one step or more than one step. It pre-supposes a two-tier system. We've had a presentation in Taipei that did not involve gateways, but rather specialized servers carrying aut

Re: [IPsec] [ipsecme] #218: Exhaustive configuration

+1 Not only IP addresses, but actual peers may come and go. A user database changes every day as employees (for example) come and go. On Mar 21, 2012, at 9:26 PM, Vishwas Manral wrote: Hi Steve, Like I mentioned the problem is not just exhaustive configuration but also the fact that configura

Re: [IPsec] [ipsecme] #217: Temporary credentials

I don't think there need to be authorization tokens, as authorization can be left to local policy. But there always needs to be some kind of "introduction" process, and it can take many forms: - Yaron, Yoav is at 192.168.1.3. Use c80273f0f7dd5bdc10c38234616fde22 as PSK - Yaron, Yoav is at 192.

Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible

ogendra Pal Ericsson, India +91-9686202644 On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir mailto:y...@checkpoint.com>> wrote: "direct endpoint-to-endpoint connectivity may not be possible if both endpoints are NATed" Why? There are several protocols (SIP/RTP come to mind) that manag

Re: [IPsec] [ipsecme] #219: Star topology as an admin choice

I don't think this is an all-or-nothing choice. You might want a mesh for VoIP, but a star for HTTP, FTP and mail protocols. Or you may want a mesh within your organization, but to trunk and inspect all traffic going somewhere else. On Mar 21, 2012, at 3:37 AM, Stephen Hanna wrote: > Please com

Re: [IPsec] [ipsecme] #217: Temporary credentials

On Mar 26, 2012, at 9:52 AM, Michael Richardson wrote: > >> "Geoffrey" == Geoffrey Huang writes: >Geoffrey> My initial inclination is to say that won't fly: that many >Geoffrey> deployments still require preshared key authentication. >Geoffrey> Rather, they would object to certi

<    1   2   3   4   5   6   7   8   9   >