Valery Smyslov writes:
> The fixed 8 bytes were used for simplicity. The purpose of this field
> is only to avoid use of misconfigured PPKs, so it is believed
> that 2^-64 is an adequate chance for misusing PPK.
> In the worst case the SA won't be established with no clear
> reason in the log file
Valery Smyslov writes:
> The draft uses the method similar to RFC 8784:
>
> SK_d = prf+ (PPK, SK_d')
>
> with the replacement of SK_d with SKEYSEED.
>
> The rationale for using the current form:
> 1. This is the most straightforward and conservative use of prf,
> when the first argument (PP
Valery Smyslov writes:
> I have some comments on draft-pwouters-ipsecme-delete-info that I
> tried to express at IETF120, but due to lack of time they were not
> responded to.
>
> 1. I'm very much concerned with the "Delete Reason Text" field. My
> primary question - in what language this free tex
Christian Hopps writes:
> This example doesn't make sense to me, it seems contrived to make
> some point but it's not realistic.
>
> People aren't contacting random IPsec servers that are
> mis-configured for their users. If the user wouldn't understand the
> above language then the operator wou
Michael Richardson writes:
> If we are going to rely on the enum alone, then it needs to cover all sorts
> of cases that might be specific to some implementations, while other
> implementations would have a more general code.
Perhaps instead of reason text we have generic enumeration of close
reas
Daniel Shiu writes:
> Many thanks for all of the comments. I feel that AUTH_HMAC_SHA1_96
> should be formally deprecated not necessarily for its security*
> relative to the deprecated AUTH_HMAC_SHA1_160, but for purposes of
> consistency, clarity and in support of a broad migration away from
> SHA-
Paul Wouters writes:
> I don't believe in this, but if I did, wouldn't you extend the Transorm Type 5
> to:
>
> - SN
> - ESN
> - SN without replay protection
> - ESN without replay protection
>
> Hence my comment about bytes and flags being a bit confusing. I
> don't think we can repurpose this r
Steffen Klassert writes:
> That said, if we want to transmit the 64-bit sequence number
> in ESP, I'd prefer to transmit the upper 32-bits before
> the lower 32-bits. That's easier on the imlementation side.
The difference in implementations is minimal, but sending lower
32-bits first keeps the ES
Paul Wouters writes:
> > On the other hand I do think Group 14 is something that most likely
> > needs to be updated...
>
> Yes, some standards like PCI are sun setting finite field DH. The
> question is what to make the new MTI, a NIST curve or a non-NIST
> curve (or both). My guess would be to p
Paul Wouters writes:
> On Fri, Aug 16, 2024 at 10:09 AM Tero Kivinen wrote:
>
> The difference in implementations is minimal, but sending lower
> 32-bits first keeps the ESP backward compatible with different
> firewall, deep packet inspection etc middleboxes, wh
Valery Smyslov writes:
> > 4.4.1. Group Policies
> >
> > Having terms Group Security Association Policy (GSA Policy) and Group
> > associated Policy (GAP are bit difficult to read, as those two are so
> similar.
> > Perhaps Group Policy (GP) and Group Security Association Policy (GSAP)?
>
> I see
Valery Smyslov writes:
> > I did understand that, but I do not see point of sending extra 8-octets as
> the first 8-
> > octets already identifies the IKE SA...
>
> The point is that we want to re-use IKEv2 header, which contains two
> IKE SPIs.
Sure, but this does not have anything to do with th
Scott Fluhrer \(sfluhrer\) writes:
> I (and I don’t believe I am alone in this) would like to see an
> ML-KEM RFC for IKE; how can we make it happen?
>
> From what I see, the next step (now that the authors have updated it
> to specify the final version of ML-KEM) would be having it adopted
> by t
Valery Smyslov writes:
> > > In normal IKEv2 each side selects its own IKE SPI, but in
> > > G-IKEv2 it is impossible. It is the GCKS that provides GMs with SPI
> > > for rekey SA and GMs will have to use it to select the right SA.
> >
> > Yes, but as the GM will always only use the first 8 octets
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:
> 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:
> 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
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
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
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
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
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
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
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:
> 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
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
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
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
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
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.
>
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
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
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
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
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
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
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:
> 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.
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:
> 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
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 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
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
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
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
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
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
--- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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.
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:
> > 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
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
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
Michael Richardson writes:
>
> >>>>> "Tero" == Tero Kivinen writes:
> Tero> As you point out in your draft there are several allocations
> Tero> without any stable reference, and I would suggest we remove
> Tero> those. If the
Prashant Batra (prbatra) writes:
> I have a question on possible collision that can occur during initial
> exchange (INIT).
>
> If two peers send INIT_REQ at the same time,
>
> maybe because of some data which matches the traffic_selector on both
> the peers, how a peer should decide whether it
Suresh Melam writes:
> Ending up with two IKE SAs, may not be an issue in terms of functionality,
> but can be seen as an issue in terms of scalability.
I do not think so. I do not think this is very common situation
hapening in the wild. It can happen if both ends decide to try to
connect to each
Praveen Sathyanarayan writes:
> [PRAVEEN] It is not very common, but common enough. We have seen several
> customer running into it. Again this is more of scalability issue. Takes
> more CPU and memory in maintaining this extraneous SAs. Also it is a
> source of confusion for several customers.
If
Valery Smyslov writes:
> section 2.25.2 describes some rules to deal with IKE SA close and
> rekey collisions.
> In particular, it states:
>
>If a peer receives a request to close an IKE SA that it is currently
>rekeying, it SHOULD reply as usual, and forget about its own rekeying
>re
Bhatia, Manav (Manav) writes:
> > There is no evidence of any recent change either to the operational
> > circumstances or to the available alternatives. So no update is
> > appropriate at this time.
>
> One major recent change is the publication of WESP [RFC 5840] and
> the standard for using
Bhatia, Manav (Manav) writes:
> Hi Sean,
>
> All I am saying is this:
>
> There are many implementations that don't support AH as 4301 has a
> MAY support clause for AH.
Just noting that same is true for WESP. It is not mandatory to
implement, and I would claim there are way more implementations
Bhatia, Manav (Manav) writes:
>
> > 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
>
> WESP can be used with ma
[I CCed the ipsec@ietf.org list, as this changes the registration
policies, and we have already had some discussion about this earlier
on the list and other people there might also have their opinion about
the matter.]
Pearl Liang via RT writes:
> 1) What are the registration procedures for these
Pearl Liang via RT writes:
> - For Registry Name: IPSEC Authentication Methods (Value 3)
> > Registry Name: IPSEC Authentication Methods (Value 3)
> > Current: Standards-track RFC
> >
> > There is nothing about this in the RFC2409, so I would say either "RFC
> > required" or "Specification require
[Removed iana etc from the CC list, as there is no point of keeping
them spammed by our WG discussion, I will contact back to them when we
have some kind of resolution about this.]
Paul Hoffman writes:
> On Feb 9, 2012, at 9:59 AM, Yaron Sheffer wrote:
>
> > Hi Pearl, Tero,
> >
> > Regarding the
Yaron Sheffer writes:
> No surprise at all - I used the term "non-IETF extension". As long as
> your extension goes through proper IETF process/review, I'm fine with
> it. I might even support it, since I agree that it adds security to
> IKEv1/PSK. Other people might argue that we shouldn't conf
Paul Wouters writes:
> On Mon, 13 Feb 2012, Paul Hoffman wrote:
>
> >>> There is no reason why the initiator cannot allow any narrowing.
> >>> This is supposed to be an improvement over IKEv1 where any
> >>> mismatch in configuration between the peers resulted in failure
> >>> to set up a tunnel.
Timothy Carlin writes:
> Hello,
>
> During testing, the UNH-IOL has encountered a behavior with regards
> to the handling of Traffic Selectors that causes interoperability
> issues.
>
> The issue center around the handling of this quote from RFC 5996,
> Section 2.9:
>
> ?To enable the responder
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_ENCAP packets
> >> where the inner IP is the same as the outer IP.
>
> > I'm not sure I follow y
ew version of I-D, draft-kivinen-ipsecme-oob-pubkey-00.txt has been
successfully submitted by Tero Kivinen and posted to the IETF
repository.
Filename:draft-kivinen-ipsecme-oob-pubkey
Revision:00
Title: More Raw Public Keys for IKEv2
Creation date: 2012-0
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 credentials which cannot be
forwarded. I.e. if the shared secret
Yoav Nir writes:
> Users use passwords, but endpoints can use PSKs and certificates.
> PSKs should be pairwise, so they have to be provisioned dynamically.
> It's all part of having to create the PAD entries dynamically. If we
> anyway have to provision peer's IP address/locator and identity (DN,
>
Michael Richardson writes:
> Tero> In section 3.2 about star topology it should be noted, that
> Tero> quite often adminstrators do require star topology because
> Tero> they want to do some kind of inspection for all traffic inside
> Tero> the vpn. This kind of policy might make it
I think I am completely lost with this draft.
If I have understood correctly the basic setup is:
UE -- FAP -- NAT --- SeGW --- Mobile network
^ ^
| \--- Public IP+Port
\-- Private IP
and the problem is that the Mobile network needs to know the Public
t...@zteusa.com writes:
> Tricci > First of all, hoping that you and I have the common understanding
> that, the portion of the network that deploys NAT is the fixed network and
> its corresponding operator is NOT the same operator who runs the mobile
> network. However, the FAP is attached to
Praveen Sathyanarayan writes:
> Yes. If certificate based authentication was used in the network, there is
> no need of new credentials. But if pre-shared key based was used, then we
> need this "temporary credentials". Also, it is required to define the
> lifetime of this "temporary credentials".
Geoffrey Huang writes:
> My initial inclination is to say that won't fly: that many
> deployments still require preshared key authentication. Rather,
> they would object to certificates because of perceived complexity.
> That said, I could see arguments that what we're discussing are
> already fai
Praveen Sathyanarayan writes:
> This works if there is only one Hub in the network. Scenario where
> multiple hubs in hierarchy or multiple Hub's that don't have
> hierarchical relation, this will not work.
I see no problems even if there is multiple hubs. There are lots of
different ways to do th
Daniel Migault writes:
> My understanding is that there are two things, that may be considered
> independently:
> - configuring IPsec layer
> - defining which route the communication should take
>
> I don't understand why only one tunnel should be used. A mobile node, when
> it detects a n
Yoav Nir writes:
> This is about my presentation from the IPsecME meeting today (which
> for some reason is not on the website)
>
> Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry
> ERP messages". This caused some controversy a year ago, but
> regardless, I did think of a use c
As described in the IPsecME WG meeting I propose that we change the
registration policy for the IPSEC Authentication Methods (Value 3) of
ipsec-registry from the "Standard-Track RFC" to "IETF Review" (From
RFC5226):
--
IETF
Geoffrey Huang writes:
> It's starting to sound like existing methods, to be sure. I'm skeptical
> of introducing yet another form of authentication. This would add to the
> complexity of the overall system. To frame it in terms of a requirement,
> I propose that any leaf-to-leaf communication h
Dan Harkins writes:
> I guess I'd like to register an objection. I wrote a draft a few months
> ago to address this:
>
> http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt
>
> That suggested making it "Specification Required". You mentioned that
> someone was opposed to it being "
Dan Harkins writes:
> That said, the problem I want to fix-- IKEv1's susceptibility to
> dictionary attack, it's binding of a PSK to an IP address, and the
> prevalence of XAUTH because there's no other option-- should be fixed.
All others than the dictionary attack IS ALREADY FIXED. The fixes a
david.bl...@emc.com writes:
> While I know that you're competent to design a solid protocol, who
> does the security review of the next 5 j-random authentication
> mechanisms to make sure that they don't have security flaws? I'd
> prefer something like IESG approval that puts the Security Area in
Dan Harkins writes:
> We can't always get what we want and we should be reasonable in
> understanding that. If we could wave a magic wand and grant your wish
> that would be good; we can't. And given the limits to our power we
> have to accept that what will happen is people will continue to use
401 - 500 of 1365 matches
Mail list logo
