Dan Harkins writes:
> There is a new draft available that some of you may be interested
> in looking at. Please send your comments to the list.
I see no point of just updating one registry in the isakmp-registry
(http://www.iana.org/assignments/isakmp-registry) and ipsec-registry
(http://www.ian
Vilhelm Jutvik writes:
> ESP doesn't protect the immutable parts of the IPv6 header nor those
> of any extension header. Both source as well as IP destination field
> can be verified by comparing them to the information found in the
> associated SA's traffic selector, but extension headers can be a
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 still a lot of negotiation
> >> going on.
> >
> > I d
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 problem we are really solving and what
security and other r
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 still a lot of negotiation
> going on.
I do not understand what you are trying to say there.
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 deal with RFC 4301 stuff like SPD. The only
> selector they need is for the GRE tunnel (protocol 43?
Mike Sullenberger writes:
> I conceed the 1 IPsec SA issue, but with IPsec you still have to enumerate
> all of the subnets within that SA and renegotiate when subnets are added
> or removed. With GRE tunneling IPsec only ever sees the GRE tunnel packet
I most likely would need to read the draft
Mike Sullenberger writes:
> We use other tunnel mechanisms (GRE), because IPsec tunneling mode
> is lacking in functionality. For example, when you use GRE for the
> tunneling you also reduce the IPsec SA's that are needed to "describe"
> the traffic for IPsec to encrypt. If you use IPsec tunnel m
ramaswamy writes:
> Thanks for the response, I agree with your comments, I think we can use
> certificates to avoid man in the middle attacks and error message flooding
> in the INIT phase only, as certificates are signed by trusted certificate
> authorities authenticity is ensured.
>
> If certifi
Prashant Batra (prbatra) writes:
> What my intention was to combine this idea with draft - "Alternate
> Tunnel Addresses for IKEv2" that is already there,
> which says something like this (for tunnel mode IPSec)-
>
> IKE_AUTH -
> IKE_IP_I:500 -> IKE_IP_R:500)
> HDR(A,B), SK {IDi, [CERT,] [CER
Prashant Batra (prbatra) writes:
> If the user knows that it has to establish 2/3 CHILD_SA, will it not be
> good to have a provision to specify the information for all in a single
> message (IKE_AUTH).
>
> This might save a lot of CHILD_SA exchanges.
CREATE_CHILD_SA exchange is quite light weig
ramaswamy writes:
> Proposed new negotiations
>
> Before initial exchange begins initiator looks up to the pre shared
> secret with the intended responder and does the hash value on first
> half of pre shared secret, nonce of the initiator. Once the
> responder receives the request it looks up th
From: internet-dra...@ietf.org
Subject: New Version Notification for
draft-kivinen-ipsecme-secure-password-framework-02.txt
Date: Wed, 24 Aug 2011 06:18:38 -0700
A new version of I-D,
draft-kivinen-ipsecme-secure-password-framework-02.txt has been
successfully submitted by Tero Kivinen
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 three documents that are "for the
> same thing". That should be done by the community.
I am most definately
Paul Hoffman writes:
> > Ok, perhaps using word of being responsible for the IANA registries is
> > wrong as IANA will be responsible for the actual registries, but it is
> > my understanding that designed expert is support to help IANA to keep
> > the registries usable.
>
> Absolutely. And, you
Paul Hoffman writes:
> You are *not* responsible for the IANA registries. RFC 5226 says:
>
>It should be noted that a key motivation for having designated
>experts is for the IETF to provide IANA with a subject matter expert
>to whom the evaluation process can be delegated. IANA forwa
Yaron Sheffer writes:
> it doesn't matter exactly what negotiation is used, as long as two peers
> can offer multiple methods in IKE_SA_INIT, and find out which auth
> methods they have in common, if any. This is true for PACE, and also for
> version -04 of SPSK, i.e. before it adopted your fram
Yaron Sheffer writes:
> Back to the matter at hand: I am opposed to
> draft-kivinen-ipsecme-secure-password-framework. It has served its
> purpose when two of the proposals were changed to add method
> negotiation, and thus enable IKE peers to implement none, one or more of
> these methods.
Ac
Paul Hoffman writes:
> > Partially yes, but unfortunately all of the authors of those actual
> > protocols decided that they wanted to continue publishing those drafts
> > as individual RFCs, and each of them used different way to negotiate
> > them, so there was no way to even implement multiple o
Yoav Nir writes:
> This draft represents a total shirking of our responsibility. Rather
> than decide on one protocol that is "best" or even arbitrarily
> choosing one that is "good enough", it proposes to build a framework
> so that everyone and their dog can have their own method. This is a
> nig
--- Begin Message ---
A new version of I-D, draft-kivinen-ipsecme-secure-password-framework-01.txt
has been successfully submitted by Tero Kivinen and posted to the IETF
repository.
Filename:draft-kivinen-ipsecme-secure-password-framework
Revision:01
Title: Secure
In the RFC5996 we have format for Raw RSA keys (using PKCS1 format).
The current buzzword compatible mantra seems to be ECDSA or Elliptic
Curve keys in general, so perhaps we should also allow Raw ECDSA keys
to be used in the IKEv2?
For the format we could either use one of the following:
1) RFC5
Scott C Moonen writes:
> IKEv1 was unclear about the scope of this notification, and I'm glad that
> IKEv2 made clear that it applies to identities and not IP addresses. But
> there is an unfortunate chicken-and-egg problem here, and I'm kicking
> myself for not noticing this back in 2009. The para
Xiangyang zhang writes:
> This proposal addresses two major issues in IPsec anti-replay service:
> 1. Some high end security router can configure thousands of bits for
> anti-replay window. For example, Juniper can configure up to 4096
> bits. The bit-shifting for this window is a tremendous burde
ully this draft will clarify things bit more.
http://www.ietf.org/id/draft-kivinen-ipsecme-secure-password-framework-00.txt
--- Begin Message ---
A new version of I-D, draft-kivinen-ipsecme-secure-password-framework-00.txt
has been successfully submitted by Tero Kivinen and posted to the IETF
reposi
Nico Williams writes:
> On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote:
> > 3) The IKE_SA_INIT and IKE_AUTH are used as exchange types, but the
> > extra payloads in them depend on the SPAM algorithm used, and the
> > SPAM algorithm used also affects the AUTH pa
Nico Williams writes:
> I believe you are wrong about that. Evidence: SCRAM (RFC5802).
>
> If you look at SCRAM you'll see that it's exceedingly simple -- it's a
> pre-shared password type mechanism, loosely resembling DIGEST-MD5.
I have not yet read the SCRAM, but based on the discussion on the
Yaron Sheffer writes:
> So I don't think we need a whole framework. We just need a way for the
> two peers to negotiate which method(s) they support early enough, i.e.
> in IKE_SA_INIT. In PACE we use a notification, and I strongly urge the
> two other documents' authors to do the same. But I'm
Nico Williams writes:
> I fail to see how Tero's proposal makes any headway. Customers who
> have and want to use AAA will not be able to use it, near as I can
> tell, and if you undertake to make it possible to use AAA in Tero's
> proposal then you'll be quickly approximating EAP re-invention.
I
Dan Harkins writes:
> I'm a bit undecided on Tero's proposal. I tend to get in trouble when
> I ascribe motivation to things people do so I won't do that, but as
> someone who actually implements the protocols we design here I think
> having n protocols, where n > 1, to solve a single problem wit
Nico Williams writes:
> Reading into what you write above you seem to think that it's not
> possible to abstract authentication sufficiently well (for IKEv2's
> purposes, in this case). I disagree. I'll grant only that there's
We do have abstract authentication method already in the IKEv2, i.e.
Nico Williams writes:
> On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote:
> > 1) Add new notification to the IKE_SA_INIT telling which SPAM
> > algorithms are supported. This will notification will include tuple
> > of 8-bit integers containing the 8-bit SPAM algori
Nico Williams writes:
> We already have three generic authentication frameworks: SASL,
> GSS-API, and EAP. Must we add a fourth one? (We also have a number
> of less generic ones, such as the ones in SSHv2, TLS, ...).
I do not consider this to be generic authentication framework. I
consider this
Yoav Nir writes:
> I have mixed feelings about this. It's better than all four of those
> drafts advancing separately. OTOH this plug-innable architecture is
> pretty much admitting defeat. It sets us up to have a situation like
> EAP, with lots of different methods, and no guide to implementers as
As we all know we (as a wg) did fail to pick one secure password
authentication method, and the latest count seems to be that we are
going to have 4 of them.
All of them seem to be mostly same from the IKEv2 protocol point of
view, but each of them are implemented differently. All of the
proposals
Balaji J writes:
> Can i know why is the DHCP allocated IP scenario not considered in
> IKEv2 RFC or any separate RFC(like RFC3456 for IKEv1)?
It was considered, but working group decided that it is too
complicated and decided to include built in support for address
allocation using configuration
david.bl...@emc.com writes:
> It's more than a decision to not include that capability - IKEv1 exchanges
> cannot be protected with combined mode algorithms without significant
> incompatible change to IKEv1, as explained in Section 1 of RFC 5282:
That is clear, I do not think anybody even dreams
Vinod Sasi writes:
> Many thanks for your reply; this is helping me to a great extent.
In the RFC6071 we do note that those combined mode ciphers are not
feature of the old IPsec-v2 set (i.e IKEv1). I would recommend not to
implement them using IKEv1, as there might be quite a lot of
interoperabi
Frank Bailey writes:
> In section 2.8 it talks about when rekeying a Child SA or an IKE SA, that
> the peers should establish an 'equivalent' SA. The question I have,
> is what is meant by equivalent?
It means mostly same... I.e. protecting same traffic and using same
parameters, ciphers etc.
>
Balaji J writes:
> Recently i have started reading the IKEv2 RFC(5996).
> I need a clarification on assigning the ip address using ikev2 protocol as
> below which i couldn't find in the RFC4718:
Note that RFC5996 is more resent than RFC4718 and RFC5996 obsoletes
both RFC4306 and RFC4718, so not al
Scott C Moonen writes:
> Tero, the existence of RFC 4304 represents an even more direct way in which
> ESPv3 and AHv3 have leaked into IKEv1.
True. On the other hand that is feature that is explictly negotiated
in the IKEv1, which only enables the one specific feature of the ESPv3
to the IKEv1 and
In early 2009 there was discussion in the IPsec list that the RFC4543
was supposed to allocate numbers also for IKEv1, not only for IKEv2.
There was some discussion on the list and then there was errata 1821
was submitted to the RFC4543 which said those numbers should also be
allocated for the IKEv
Yoav Nir writes:
> IKEv2 has an underlying assumption that peers are always available
> to respond (for example to liveness check).
Can you point me to that in RFC5996, I think I might have missed that.
I am under the understanding that either end of the IKEv2 protocol can
crash/shutdown/go silent
Yoav Nir writes:
> There are two things I'm wondering about, though. Why is this draft
> written like a mini-RFC5996, instead of just referencing 5996 and
> describing a profile. You could skip all of Appendix A and much of
> the explanation in section 2.
One of the reasons is that I wanted the do
Shoichi Sakane writes:
> This draft describes a scenario to use IKEv2 for a minimum specification.
> The document only allows one side to be a responder.
More correct way is to say, that this document only describes the
node which is always the initiator of the communication.
> I would like to a
Yoav Nir writes:
> A bigger problem is that this text says that IKEv2 needs to be
> updated, but there is no draft for this update, nor has there been
> any message to this list about this proposed change.
>
> The simple change they require is to section 3.16:
>o Code (1 octet) indicates wh
thinking whether IPsec and IKEv2 could be used in for
small devices for machine to machine communications.
--
A new version of I-D, draft-kivinen-ipsecme-ikev2-minimal-00.txt has
been successfully submitted by Tero Kivinen and
Scott C Moonen writes:
> Apologies for missing the fact that it is not strictly man-in-the-middle
> attack. Certainly the attacker won't be able to take advantage of the
> revelation if he is not in the middle, but it's still improper to reveal
> the token.
Attacker does not need to actually even
Paul Hoffman writes:
> > A token maker MUST NOT send a QCD token in an unprotected
> > message for an existing IKE SA.
> >
> > This requirement is obvious and easy in the case of a single gateway.
> > However, some implementations use a load balancer to divide the load
> > between several physical
Paul Hoffman writes:
> 9.2. QCD Token Transmission
>
> A token maker MUST NOT send a valid QCD token in an unprotected
> message for an existing IKE SA.
>
> This requirement is obvious and easy in the case of a single gateway.
> However, some implementations use a load balancer to divide the loa
I do not have time to check this document now, as I do have some
working group documents that I need to check before getting to this.
Keith Welter writes:
> This may be a naive answer, but I'm not opposed to the idea of Individual
> Submission. I do have some comments/questions:
> 1. My draft
Yoav Nir writes:
> I think it's time to resolve this. Do we leave this as-is, or do we
> cut down the applicability.
I am in favor of making the protocol simplier to implement and
especially much simplier to test, and restrict the token taker and
token maker roles to initiator and responder respe
Pekka Riikonen writes:
> I'd like to return to this failover counter. It's the single issue in the
> protocol which I don't like. The reasons are, first, that it makes an
> assumption how clustering and sync has been implemented, that is this
> value has to be synced in the cluster and the pro
Yoav Nir writes:
> As a general principle, yes. But the HA extension already assumes
> that due to the failover, there is some discrepancy. The easy way
> out would be to write a protocol extension that just detects this
> discrepancy and kills the IKE SA. But that would mean a lot of IKE
> SA setu
Pekka Riikonen writes:
>
> On Tue, 23 Nov 2010, Tero Kivinen wrote:
> : I think correct way to handle INVALID_SPI is that consider it as same
> : as the other end would have sent delete for that his inbound SPI
> : listed in the notification, and then send corresponding dele
Yaron Sheffer writes:
> to reiterate: if you ensure that the Message ID value is always strictly
> larger than in previous messages (i.e. if the failover member sends
> old_value+delta for a large enough delta, and if the peer is willing to
> accepts arbitrary jumps in the value) then both sides
Pekka Riikonen writes:
> I don't think sending delete notification after receiving INVALID_SPI
> (over IKE SA) is appropriate. The other end has already told you it
> doesn't have the SA. It should be just deleted without notification.
> Isn't this the typical thing to do?
The other end is t
Pekka Riikonen writes:
> : Now the real question is what are we going to do with the exchanges
> : which are still in progress when the sync message is received, and how
> : do we recover when we notice that we do have missed IKE messages,
> : meaning we have created, rekeyed or deleted some Child
Pekka Riikonen writes:
> Isn't this what the -02 draft specifies?
Not sure, as I have not yet read the -02 draft fully.
> ...
>o The active member dies, and a standby member takes over. The
> standby member sends its own idea of the IKE Message IDs (both
> incoming and outgoing)
Pekka Riikonen writes:
> On Thu, 18 Nov 2010, Raj Singh wrote:
>
> : > Cluster member to client:
> : > - The counter I plan to use next (based on a traffic/rekey rate estimate,
> : > must be higher than the last message that was actually sent, otherwise it
> : > might be rejected)
> : >
> :
> : I
Yaron Sheffer writes:
> it seems to me we have created an overly complicated solution for replay
> protection of the Msg ID = 0 messages. Specifically, I think both the
> failover counter and the nonce can be eliminated.
>
> Since the messages are protected under the IKE SA, we just need to
> e
I started to think whether there are other possible attacks against
QCD and found one which might be possible if implementations do not
take care of it. The IKE SPIs are allocated during the IKE_SA_INIT.
The IKEv2 SA is really created during the IKE_AUTH. This means there
is a possibility that some
I did review the draft-ietf-ipsecme-failure-detection before the WG
meeting and some of the comments I have here already have tickets so
no need to add them second time:
--
Comments to draft-ietf-ipsecme-failure-detection:
Sectio
I haven't had time to read the draft-ietf-ipsecme-ipsecha-protocol-02
completely yet, but while looking at the slides in the WG meeting, I
noticed one serious problem.
The IKEV2_MESSAGE_ID_SYNC and IPSEC_REPLAY_COUNTER_SYNC messages do
not follow Notification payload syntax.
For the IKEV2_MESSAGE
Frederic Detienne writes:
> In order to secure QCD, the token has to include all the fields that
> can be used for routing a packet to any given server:
>
> - source/destinatition IP
> - protocol (UDP / ESP)
> - source/destination ports if applicable
But the problem is that the IPsec implemen
Frederic Detienne writes:
> Like I explained earlier, sharing the address-less QCD token is
> problematic in multiple practical network designs:
> - Stateless failover pairs (e.g. VRRP, HSRP, ..)
> - Load Balanced clusters
> - Anycast server clusters
I do not think having address inside the QCD
David Wierbowski writes:
> Thanks for your answers, but I should have been more specific in my
> question. I was not asking how a MITM could break IKE. I was asking for
> an example of how draft-ietf-ipsecme-failure-detection-01 increases the
> risk over what we have today in IKE. That's what I'
Scott C Moonen writes:
> > As the host is sending traffic it will immediately notice when it is
> > not getting ACKs back from the GW, i.e. when the traffic gets
> > unidirectional, and again it can start fixing situation at that
> > point.
>
> But Tero, that process can take several minutes. Fir
David Wierbowski writes:
> Tero writes:
> >David Wierbowski writes:
> >> Tero writes:
> >> >I do not consider very open protocols which allow all kind of things
> >> >"just for fun" and "in case we someday get scenario which can use it"
> >> >as good thing.
> >>
> >> I do not think we are allowing
Yoav Nir writes:
> Alternatively it would simplify things immensely if we mandate that
> SPIs be random for implementations that support QCD (possibly only
> on the gateway side). Can we do it without having to "update RFC
> 4306"?
Yes I think we can do that, as this is requirement for only those
Keith Welter writes:
> 1. reiterate how reauthentication works in RFC 5996 (quote third paragraph
> of section 2.8.3)
I have not yet read your draft, but how dows it relate to the RFC
4478? Isn't that already defining things that would help a lot, for
example I think that can be used to force one
David Wierbowski writes:
> Tero writes:
> >I do not consider very open protocols which allow all kind of things
> >"just for fun" and "in case we someday get scenario which can use it"
> >as good thing.
>
> I do not think we are allowing the initiator and responder to
> be both a taker and a maker
Yaron Sheffer writes:
> It seems to me we are adding architectural assumptions,
Not really adding architectural assumption, but just explaining that
in those cases we do not need QCD, as we have more efficient already
standardized ways to handle the situation.
> just to gain a relatively minor s
Yaron Sheffer writes:
> you are assuming you can always map an IP address (of the incoming ESP)
> into the peer's identity. This is often possible, but not always. For
> example, if you're using round-robin DNS to look up the B peer, or if
> IKE Redirect was used.
Yes, that is the case if you h
Yaron Sheffer writes:
> I agree with Scott's position. In the case of site-to-site VPN, where
> SAs are NOT set up by configuration, but rather triggered by traffic,
> you can have a tunnel triggered by traffic from A to B, but later mostly
> used in the opposite direction. This would benefit fr
David Wierbowski writes:
> I disagree with this "simplification." Tero's logic is that this does make
> sense in some cases (e.g. his case), so let's disallow it. As Scott Moonen
> pointed out, there are cases where it is perfectly valid to expect either
> endpoint to send the next packet and cas
Paul Hoffman writes:
> >True, we need some other term for it. Something like the original
> >IKE_SA_INIT initiator or the party initiating the initial connection
> >(i.e. triggering). Or simply say that the QCD_TOKENs in INFORMATIONAL
> >exchanges and rekeys can only be sent by the peer who origina
Scott C Moonen writes:
> > I was thinking about the original initiator, not the exchange
> > initiator.
>
> Ok, but this then imposes an awkward new requirement to remember the
> "original original initiator," as it were. Today the initiator of the
> rekey becomes the original initiator of the re
Scott C Moonen writes:
> > I think it would simplify the implementations and the protocol by just
> > limiting that only responders can be token makers without loosing any
> > of the functionality.
>
> I don't think we should limit this. First, rekeys can easily reverse the
> sense of who is init
Pekka Riikonen writes:
> The window at the remote peer will move to 31000; no replay errors.
That is true for outgoing packets. That is not possible for the
incoming packets, as attacker can replay packets sent to you just
before it caused you to crash, thus causing those replayed packets to
get t
Raj Singh writes:
> Now, say failover happened at 30, 500. So, standby member
> becomes active, and it start using IPsec replay counter from 30,
> 000. It will be considered as Replay Attack and SA has to be
> destroyed.
If you have replayed incoming packets, you do consider that replay
attac
Pekka Riikonen writes:
> - Should there be way to negotiate support for IKE SA window sync but not
> for IPSEC SA sync? Currently by sending SYNC_SA_COUNTER_INFO_SUPPORTED
> you agree to support both, which can mean you may receive the IPSEC SA
> syncs.
That was my main request during the last
Yaron Sheffer writes:
> >> Alternatively it would simplify things immensely if we mandate that SPIs
> >> be random for implementations that support QCD (possibly only on the
> >> gateway side). Can we do it without having to "update RFC 4306"?
> >
> > I think it's enough to require this of the toke
Raj Singh writes:
> > It's actually worse than that. If message #4 was missed, and 5-8 were
> > received, then messages 5-8 are stored, but not processed. This has to be
> > so, because suppose message 7 deletes the SA that was created in message 4,
> > you can't process it before message 4. In any
The section 2 describing RFC4306 crash recovery is not complete. It
does not include the normal processing happining on the peer that is
not rebooting.
I suggest adding following text:
--
When the one peer loses state or reboots i
Scott C Moonen writes:
>
> The IANA registry currently lists the ESN transform as optional for ESP, AH
> in IKEv2. From http://www.iana.org/assignments/ikev2-parameters:
>
> Registry:
> Transform
> Type Description Used In
> Reference
> ---
Yoav Nir writes:
> I agree that the draft in its current form glosses over the fact
> that the missing IKE exchanges did something, like setting up a
> child SA, or tearing one down. I don't believe there is any way you
> can set up a cluster so that this never ever happens. You can make
> it rare,
I have read the the draft now, altought my paper version was -03 (last
version from the ietf repository), but noticed before starting to read
it that there was this newer version in the hidden web-page (where you
can even download it if you find the fine print version saying
"original format" downl
Jitender Arora writes:
> Load balancer by definition needs to know the devices where it is
> sharing the load to, so I do not consider that a problem. Also if the
> redirection is done in the IKE_SA_INIT phase then the application
> support required is very minimal.
>
>
> Jitender--> Adding the I
I read this document and it seems to be mostly ok.
I might disagree on some parts of the section 1 text talking why EAP
is needed (I think the main reason was to support legacy systems. The
public keys are flexible enough to meet requirements of many
deployment scenarios unless your requirement in
Paul Hoffman writes:
> In specific, it would be good if the pickier folks on this list to
> look at 2195 and see if this is really just a clarification or is a
> change that limits something we don't want to limit. Comments on any
> of the others is welcome too.
I think the change in 2195 is ok,
Jitender Arora writes:
> Jitender--> Currently we are using this approach (basically using
> the redirect and the Mobike).
>
> This is causing the following issues:
>
> 1. If the redirect message is handled by the Load Balancer, the
> load balancer needs to be IKEv2 aware and also it needs to kn
Jitender Arora writes:
> Currently the IKEv2 does not allow the IKEv2 signaling and the
> IPSEC traffic to go to different IP addresses, so this is the
> problem this draft is trying to solve.
>
> The application where it is required now is the load balancing
> of the IPSEC tu
Dan McDonald writes:
> Consider the example in section 3.3 of IKEv2bis, which I've edited for
> brevity:
>
>SA Payload
> |
> +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
> | |7 transforms, SPI = 0x052357bb )
>
> (either way for ESN, three CB
Thomas Narten writes:
> Is there more specific wording in 4301 on this point? Is it viewed as
> an absolute MUST requirement to implement IKEv2 in order to claim
> compliance with RFC4301?
RFC4301 says in section 4.5:
--
4.5. SA
Jitender Arora writes:
> 1. I will point the section 5.1 in the introduction itself that way
> the purpose and applications of the draft are clear.
After I read the section 5.1 (I skipped most of the other draft as I
needed to know first WHY this is needed before I care about HOW it is
implemente
David Wierbowski writes:
> >Do you think it is legal to create a system where one Child SA can
> >fail in such way that IKE SA cannot send delete notification?
>
> I do not think a robust IKE implementation would allow this.
I agree, and the current text says you cannot do that (i.e. it says
taht
Yoav Nir writes:
> Actually, in our implementation, all packets (IKE and ESP) have the
> cluster IP address, so the peer doesn't notice a failover, and also
> the peer can't tell which member is "active" or which member it is
> working with.
Yes, that is also one way doing it, but in that case th
Yoav Nir writes:
> I agree. And whatever we may think of the particular solution, it does
> present a problem that can and should be in the problem statement draft.
>
> So how about adding teh following sub-section:
>
> 3.7. Different IP addresses for IKE and IPsec
>
>In many implementatio
David Wierbowski writes:
> What I do not like about the text is that it is a rule related to the
> life of the Child SAs. I think it would be clearer to tie the rule
> to the termination of the IKE SA. For example I think replacing the
> text with some thing like the following is more straight fo
901 - 1000 of 1364 matches
Mail list logo
