--=-=-=
{catching up on old email}
Tero Kivinen wrote:
> Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ to SHOULD.
this is the only one which I didn't understand.
Michael Richardson
-on the road-
--=-=-=
Content-Type: application/pgp-signature
-BEGIN PGP SIG
requests might accomplish this witho=
ut=20
new kernel code.
Michael Richardson
=2Don the road-
--=-=-=
Content-Type: application/pgp-signature
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABAgAGBQJSdA2iAAoJEKD0KQ7Gj3P2TSgIAKstL3ktU0yg18WbKEcLAZgo
Jk1+kz3uhC
FC). A draft already exists, thanks Tero [1]. If we do
> not hear significant objections, we would like to adopt the document as
> a WG document by Monday, Oct. 21.
+1.
--
Michael Richardson , Sandelman Software Works
pgpItZpptoFpN.pgp
Descript
NSE FROM PRIMUS SUPPORT AGENT -
>Hello Michael,
>
>We have got the routing checked and found that we will not be able to
>complete this call to conference bridge at +1 712-775-7400 due to that NPA
>NXX being locked. This is likely due to high toll costs.
--
Michael
Michael Richardson wrote:
>> The call-in details are:
>> Tele: +1 712-775-7400
>> Code: 809604#
mcr> Two LD suppliers (entirely different phones) tell me that I can not
reach
mcr> this number from my line.
I wonder if this exchange has an inflate
Paul Hoffman wrote:
> The call-in details are:
> Tele: +1 712-775-7400
> Code: 809604#
Two LD suppliers (entirely different phones) tell me that I can not reach
this number from my line.
I'm gonna try Google Talk now.
(and I guess it's really in an hour
s to shortcut things like media traffic, then it might
be okay. The media setup protocol may be able to deal with the changes to the
addresses/port numbers.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works
't think it matters a hoot if the ADS can do IPsec. It's IKE.
IKE is a UDP based protocol, and if you remove the IPsec requirement, it's
just another deamon.
It is the *HUB* and the *SPOKES* where I think one wants to remove as many
moving parts as possible, and in particular, remove a
-ipsecme-ad-vpn-protocol and while conceptually I found
it okay, I think that the protocol should be inside IKE.
--
Michael Richardson , Sandelman Software Works
pgprjsXLRvFmf.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
or IPv4.
I see. Sounds reasonable.
Too bad the AES_GMAC designers didn't truncate more.
--
Michael Richardson , Sandelman Software Works
pgpm1zlpkLhCX.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
ateway forwards a
> particular slice of traffic to the Internet, so the spoke gateway might
> as well forward to the Internet all by itself. There should be some
> consideration given to NATs (like if the spoke was protecting RFC-1918
> addresses, and the center gateway w
Please note that fragmentation below UDP is unpopular among IPv6.
http://www.ietf.org/proceedings/87/slides/slides-87-6man-2.pdf
--
Michael Richardson , Sandelman Software Works
pgpFULMTrmYtm.pgp
Description: PGP signature
___
IPsec mailing
Appendix A.2. I'm glad you took the suggestion of having the shortcut
be learned incrementally.
Re: the situation in A.3. If officeGW realizes that peer1 and peer2 are in
fact on the same subnet, etc. is there any way for it to tell them to create
a "bypass" between them?
l
initiate to the appropriate other spoke and do full IKEv2, including
authentication?
I think that I have missed where the ADC spoke is told by the ADC client
where it is supposed to redirect to.
--
Michael Richardson , Sandelman Software Works
;s
traffic to CPE_C. Where are the tunnel outer information configured?
It seems to me at least some traffic selectors are needed.
--
Michael Richardson , Sandelman Software Works
pgpGiFd5KGg45.pgp
Description: PGP signature
___
IPsec mailing
validate n and thirdly validate e
and n are consistent with each other. In order to validate the public
exponent e, use of made of the fact that the exponent 2<=e<=2(k
I can not speculate as to whether there is prior art, but it seems to
match what we have been discussing.
--
M
gree that the problem likely needs be solved in a standard way.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sand
ul> Based on the amount of new material, I want to have another
Paul> (albeit shorter) WG Last Call for this new version of the
Paul> draft. Please send comments to the WG by Monday, April
The additional material seems clear enough to me.
--
] Never tell me th
check that the peer's public value is in range (1 < r < p-1).
This option is more appropriate if conformance to [NIST-800-56A]
is not required.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works
me implementations which calculate
their g^x/g^y, and cache that for many DH operations.
Is the the point here is that this is safe if we do these tests.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|
one, since the receiver is not in a position to know if
the DH private value was reused.
>> I have not implemented ECDSA, but the instructions seemed well
>> formatted, but I don't at this point know what they mean.
sfluhrer> Actually, we're talking about ECD
ut the instructions seemed well
formatted, but I don't at this point know what they mean.
--
Michael Richardson , Sandelman Software Works
pgp3_DpJpKwlo.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
f the PKIX certificate is used.
This is a a very simple encoding, as most of the ASN.1 part can be
included literally, and recognized by block comparison. See
[draft-ietf-tls-oob-pubkey] Appendix A for a detailed breakdown.
In addition, Appendix A has a few examples.
(Yes, add a sec
=3D
I don't think that this addreses any work item for IPsecME, but I
thought that maybe it might help someone to know about this.
--
Michael Richardson
-on the road-
pgpL90Zjnd8Zz.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@iet
t. Send your
TK> comments about this too.
if it can fit into the charter, and/or our AD will let us, then yes.
--
Michael Richardson
-on the road-
pgp4Y4prhnPQz.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.i
er where it went. This seems like a good point to me.
DM> AES-CTR is the one algorithm in that category in the draft so
DM> far.
I agree with this.
--
Michael Richardson
-on the road-
pgp6uDXc4K65j.pgp
Description: PGP signature
_
as one of the parameters you needed to
TK> tune down for web servers if you wanted to support lots of
TK> clients.
yeah, but the concern listed in the document is that the initial
congestion window wouldn't be big enough to quickly send out the large
IKE_AUTH payload. Having at l
it could obsolete payload 11?
Could new implementations decline to implement type 11? I think that
this would be marginally acceptable.
--
Michael Richardson
-on the road-
pgpsxKvndv61S.pgp
Description: PGP signature
___
IPsec mailing list
IPsec
o what
things to focus on? Or for people GREP'ing the RFC archives as a result
of an attack will come up with IPsec as a user/
--
Michael Richardson
-on the road-
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
r that did this would seem to be effectively taking twice the
resources on the responder.
I think that it's important to note really loundly, and maybe
repeatedly, that the duration of the TCP connection is not related to
the duration of the IKE SA.
--
Michael Richardson
-on the road-
one exchange over TCP now requires 2 round trips of delay, and
TK> most likely around 10 packets, compared to the 1 round trip and
TK> 2 packets.
Yes. I think that the congestion window argument is probably not
relevant. I don't think the congestion window will open much e
is is already mentioned otherwise I think
it should be added in clarifications.
Regards,
Kalyani
--
Michael Richardson
-on the road-
pgpMJkgNrKFsU.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
you mean RFC4322?
Or is there another proposal that I've missed?
--
Michael Richardson , Sandelman Software Works
pgp02LC96anVU.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
ack of control over reverse, and later,
due to there being no reverse for systems on the NATwork.
Paul> The difference with TLS is that the client has a concept of the
Paul> terminal name it connected to, and has its own src-dst transport,
Paul> whereas for IPsec we only have one sr
on (or not), we have a problem to deal with
at the IPsec level.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
connect
Yoav> from behind some very dodgy NAT devices, and some of those do
Yoav> drop fragments. Getting this behavior at the ISP is novel.
And ESP over TCP on port 4500?
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Mi
.
3) Pluto actually provides an ordering mechanism between policies which
is the ordering mechanism for policies as specified in 4301.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottaw
the (partial) mesh of "rim" links.
It's about the "Beltway" roads... perhaps someone can come up with a
suitable reference to the Washington, DC politics for the protocol name.
--
Michael Richardson , Sandelman Software Works
IETF ROLL WG co-chair.http://datatracker
that B is behind B-gateway, and gets VPN
service from B-gateway (and concentrator-X).
Vishwas> I agree there is a use case for this optimization, but do we want
to tackle
Vishwas> the use case as part of the base solution or as an extension once
the base
Vishwas> solution is created
d be *no* IPsec tunnel
between A and B, as they are presently co-located.
Do we have a requirement that the policy between two spokes
(a "bypass") could in fact be "clear"?
--
Michael Richardson , Sandelman Software Works
IETF ROLL WG co-chair.http://datatracker.ietf.org/wg/roll/charter/
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
hich
you get with your maintenance.
But, IKEv2 is a major release, for which the customer pays again.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.c
f life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
t
> "Yoav" == Yoav Nir writes:
>> You didn't take my comments too far; I think you realized that I was in
>> fact saying two things:
>>
>> 1) when traffic is redirected, MUST it be redirected directly to the
>> real endpoint? (There might be issues of in-band double NAT th
> "Vishwas" == Vishwas Manral writes:
Vishwas> Branch routers have 3G/ 4G interfaces as backups for the
Vishwas> primary interface
Vishwas> and sometimes even multiple 3G/ 4G interfaces with no wired
Vishwas> interface at
Vishwas> all to the backend.
Vishwas, it's not a
"A" get destroyed on node "B" when "A" moves, reboots, updates it's NAT
address, etc.
This is not exclusively about MOBIKE: there are lots of other ways in
which the A<-->H1 connection can change which would affect "B".
--
] He who is tired of
optional *optimization*!
It may be *required* in order to get a sufficiently high quality path
for some services (VoIP), but, from a layer-3 point of view, it's
optional.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sande
AY it be redirected more than once?
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: w
have a protocol along trunk1 and trunk2 that permits the
information about where B is to be communicated.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.
> "Stephen" == Stephen Hanna writes:
Stephen> I think that Michael is asking an important question. There
Stephen> are many ways to solve the P2P VPN problem. One way is to
Stephen> have satellites with little configuration that connect to
Stephen> core gateways with lots of d
> "Yoav" == Yoav Nir writes:
Yoav> "direct endpoint-to-endpoint connectivity may not be possible
Yoav> if both endpoints are NATed"
Yoav> Why? There are several protocols (SIP/RTP come to mind) that
Yoav> manage endpoint-to-endpoint connectivity even when both are
Yoav>
t have non-transtive authentication
mechanisms, and it would be very annoying to setup each leaf
system with a trusted connection to the AAA system for
authentication.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson
s and leaf systems would continue to "authenticate" to the
gateway using the insecure legacy mechanisms that CTOs seem to prefer.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net archite
nt in the
clear.
* Configured tunnel: network prefixes to which traffic must be
encrypted, and traffic in the clear is never permitted. A
traditionally defined Virtual Private Network (VPN) is a form of
configured tunnel.
--
] He who is tired of Weird Al is tired of life!
uot;. How
Yoav> about "dynamic discovery VPN" (DD-VPN)?
I offer:
On-Demand Dynamic VPN = ODD-VPN.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sand
?
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.you
c Encryption.
It's not Opportunistic.
It's configured, it's just on-demand. In Openswan terminology that
would mean a "routed" policy with a DNS lookup.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman S
I read the draft yesterday.
I wasn't surprised. That in itself was a surprise.
It's exactly what I thought the problem is from the beginning.
There was no big mystery requirement that I didn't understand.
The only thing I found weird was the belief that RFC4301 SPD
configuration had to be "h
k, to say that we should
Manav> "avoid" AH wherever possible.
This is the status quo already.
Why do we need this draft?
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net archit
ctive in IPsec, I suspect that some people
might not know what pieces of code and specification you wrote, and who
paid you to write those pieces of code.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ot
sing).
Someone can.
Nothing stopping anyone.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
n when the receiver does not have
the key.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
that for 99% of "Use IPsec"
statements, ESP-NULL is likely the correct choice.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.san
I find the goals and schedule acceptable.
> "Yoav" == Yoav Nir writes:
Yoav> In an environment with many IPsec gateways and remote clients
Yoav> that share an established trust infrastructure (in a single
Yoav> administrative domain or across multiple domains), customers
Yoav
> "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 there is no specification how to implement it, there
Tero> is no way anybody can make interoper
hooting interaction issues. I still believe that
Mike> IPsec at the base is not a good tunneling protocol.
CISCO IOS IPsec is a poor tunneling protocol.
Many other vendors do a better job.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michae
a pretty good solution to the
problem, particularily if in the end, you didn't want to actually have
any ACLs on the resulting tunnels.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|
addresses
Mark> that type of "large-scale, P2P VPN". And please do so in a
Mark> standards-based, non-proprietary way, that accommodates
Mark> 10,000+ gateways, independent of vendors, and won't take me 10
Mark> years to configure.
--
] He who
walled garden, they are
much more tractable. Or, given that it's all inside a tunnel, why not
just use IPv6 addresses on the inside of host to host tunnels?
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works,
RFC2332: NBMA Next Hop Resolution Protocol (NHRP)
I think that it is a much better thing to use something like this, than
invent something new.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON
like: "to get to 192.168.79.0/24, go to spoke79."
RFC4025.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/
'll invent?
Yoav> SOAP?
Yoav> As an attribute in a certificate, kind of like SIDR?
So, okay, so you want to do new work to replace work that's already been
well defined, that uses DNS as the transport.
--
] He who is tired of Weird Al is tired of life! | firew
gw, and sends all 192.168.0.0/16 to hub-gw. -
Yoav> spoke79, which protects 192.168.79.0/24, knows about hub-gw,
Yoav> and sends all 192.168.0.0/16 to hub-gw
Yes. And, how is this policy communicated?
--
] He who is tired of Weird Al is tired of life! | firewalls [
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <ht
>>>>> "Paul" == Paul Hoffman writes:
Paul> On Oct 31, 2011, at 8:09 PM, Michael Richardson wrote:
>> If the entities are in fact a group who has an internal trust
>> anchor:
Paul> They have an entity they trust to make introductions.
> "Yoav" == Yoav Nir writes:
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, it's just the easiest one to arrange
>> between total strangers
> "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, it's just the easiest one to arrange between total
strangers
>> 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
If I was an off-path attacker, and I couldn't drop your packets
(but maybe I can see them), and I am not going to try to decrypt your
packets, I would simply replay/make-up some packets. If I do this
within the IPsec replay window, the receiving machines have to run the
auth check, and so due to
> "Yoav" == Yoav Nir writes:
Yoav> I definitely think that the authors of this draft (I'm mostly
Yoav> just the editor) need a good answer about why RFC 4322 doesn't
Yoav> cover the use cases. Mostly, the starting point is different.
Yoav> RFC 4322 begins with nodes that hav
> "Yoav" == Yoav Nir writes:
Yoav> A little. Also like GET-VPN and AC-VPN and Provider-1
Yoav> (apologies to all the vendors I've missed)
Yoav> Those are some of the incompatible solutions by individual
Yoav> vendors.
And RFC4322.
FreeSWAN has a number of local controls whe
lement only the much simpler IKEv2.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the vi
es :-)
Again, I do not know why it has to double the number of round trips.
I see one extra round trip caused by the EAP-ID process, and then it's
the same number both ways.
Perhaps you can draw a time-sequence diagram for this to convince me?
- --
] He who is tired of Weird Al is tired
Yaron Sheffer wrote:
This draft proposes an IKEv2 extension to allow mutual EAP-based authentication
in IKEv2, eliminating the need for one of the peers to present a certificate.
This applies to a small number of key-generating EAP methods that allow mutual
authentication.
Proposed starting
Tero Kivinen wrote:
SPSK can be used when there is requirement for host to host (or site
to site) connection, where either end can initiate traffic and
exchanges and where entities still want to use passwords instead of
public keys to authenticate. Shared keys could be used there, but in
most set
Dan Harkins wrote:
2. solves the specific problem it is aimed at poorly-- doubling of
the number of messages, requiring writing and testing of new
state EAP state machines that are, otherwise, unnecessary; and,
Does it double, or does it really just "n+1", which is doubling
Yaron Sheffer wrote:
This draft proposes an IKEv2 extension to allow the setup of an IKE SA with no
Child SA, a situation which is currently disallowed by the protocol.
Proposed starting point:
http://tools.ietf.org/id/draft-nir-ipsecme-childless-01.txt.
Please reply to the list:
I believe
Yaron Sheffer wrote:
This work item proposes an IKEv2 extension to allow an IKE peer to quickly and
securely detect that its opposite peer has lost state. This is claimed to be
quicker than the current method, which is based on time outs.
Proposed starting point: http://tools.ietf.org/id/draft
Yaron Sheffer wrote:
This work item will define the problem statement and requirements for a
solution that allows interoperable HA/LS device groups. Mixed-vendor
clusters are specifically out of scope; but single-vendor clusters
should be fully interoperable with other vendors’ devices or clust
Yaron Sheffer wrote:
This draft proposes an extensibility framework for WESP, as well as
several specific extensions.
Proposed starting point:
http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt.
I am not interested in any further extensions to WESP.
In particular,
Yaron Sheffer wrote:
This work item proposes to extend IKEv2 (and IKEv1) so as to allow IPsec to be
used in environments that require Mandatory Access Control. It is envisioned
that this will be used by modern high-security operating systems, that go
beyond the currently supported Multilevel S
ge advice of Kivinen and McDonald, that the least
amount of harm possible will be done.
- --
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca
y would be good, as there will be people with
broken implementations (i.e. "bugs") out there trying to determine what
is going on, and they won't always be sitting at a table next to you.
--
] Y'avait une poule de jammé dans l'muffler!| firewalls [
] Mi
Let me draw a time-sequence diagram to explain things as I understand
them (fixed-width font alert)
site to site policy
policy: 1.0.0.0/8 <-> 2.0.0.0/8
Alice-GW Bob-GW
--Trigger--> (1.2.3.4->2.3.4.5)
(1)
lude a known-to-be-unacceptable
CHILD_SA proposal.
--
] Y'avait une poule de jammé dans l'muffler! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |dev
Yaron Sheffer wrote:
Hi Ken,
It seems to me this field is more trouble than it's worth. We are assuming
that the hardware will be enforcing a very simplistic security policy (don't
care if it's Tunnel or Transport, don't care if it's a TCP SYN or not etc.)
and that the hardware is unable to perf
Dan McDonald described a worse case scenario.
It had the advantage that communication that could continue did
continue. It had the disadvantage that the traffic to port 2112
got delayed because we needed the packet contents to get the policy
right. This is bad due to the delay.
It required spec
Yoav Nir wrote:
Hi Raj
Matt is correct. There is no way in IKEv2 to do a phase1-only exchange,
and then wait for traffic to establish the child SAs.
While we do establish an IKE SA if the piggy-backed child SA failed for
whatever reason (bad selectors, no proposal chosen), we don't allow
301 - 397 of 397 matches
Mail list logo
