To answer Jim's question following on Pascal's point, I don't believe
that only link-layer security is enough because it lacks any end-to-end
properties. It wasn't clear in my previous email, but multihop
topologies are the norm in low-power wireless with IEEE 802.15.4.
The ISA100.11a
Hi Alain,
you raise the existential question about the security (except for
dedicated security services like VPN): why to pay for something that
might be never used? :)
This is exactly the same problem I have today with airbags in the
cars: I pay them when I buy a car (i.e. cost), I cannot
Hi,
2008/2/26, Basavaraj Patil [EMAIL PROTECTED]:
It is not the load or processing that is the issue really which I think you
are alluding to. It is just the complexity of integrating a protocol like
Mobile IPv6 with IPsec and IKE/IKEv2.
Mobile IPv6 signaling can be secured via simpler
Brian Dickson wrote:
...
Any of a bunch of other kinds of security can do the job, from TLS to
SSH to use of
out-of-band channels.
For those that have forgotten, the entire reason for mandating IPsec is to
get away from the 47 flavors of security that are never really configured
correctly or
As a general node requirement, SHOULD is the right level, not MUST.
= +1
Apart from the technical discussion of whether IPsec is actually useful for
applications etc. The way KEYWORDS are defined, a MUST makes little
sense because IPv6 will not break without IPsec.
The argument for
I see what your saying but for security if we know IKEv2 is superior then we I
think must mandate it and this is the case over IKEv1. Fully supportive of
being conscious of the reality of pain to the market and vendors for
implementation but when it is a network health issue then we have to do
Hi Pascal,
Responses in line.
All I can say is that at least one Wireless Sensor Network
standard under development will not use IPSec. ISA100.11a
(http://www.isa.org/MSTemplate.cfm?MicrositeID=1134CommitteeI
D=6891) has decided to endorse - and extend when necessary -
the work done at
It all comes down to is IPsec capable for the nodes within the discussion below
and I point to Tony Hain's mail that IPsec is far better than 47 security
protocol options from an IETF doing our job here. Batteries are energy cost
impacting other work in the IETF too it is a reality we need to
Good recap on why Tony it is very important for us to hear this input and quite
valid.
thanks
/jim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Tony Hain
Sent: Wednesday, February 27, 2008 5:20 AM
To: ipv6@ietf.org
Subject: RE: Making IPsec
I totally appreciate Alain's concern for cable modem devices
with limited memory for IPv6 but the problem is that IPv6
community decided as far back as 1998 with RFC 2401 that
IPSec is mandatory for IPv6.
The events of 1998 are irrelevant. The fact is that this website
It ridiculous that folks wave a document from 1998 away. Further, does
anyone even read emails carefully before replying? When I gave a
reference to RFC 2401 where is was mandated that IPSec is a MUST for
IPv6, I also gave a reference to RFC 4301 that is dated Dec 2005! Both
RFC's have the same
Hi Jim:
Please see inline:
ISA100.11a is defining a simple transport level security above UDP
that is based on the AES encryption engine in the CCM mode
(in reality
CCM* as defined by 802.15.4, annex B, which refers to CCM as defined
by ANSI X9.63-2001 as well as NIST Pub 800-38C and
Folks,
Tony is right that cable is a closed environment. I am a cable CMTS
router developer talking here. Also cable has its own security with BPI+
between the cable modem and CMTS (Cable Modem Termination System). See
http://www.cablemodem.com/downloads/specs/CM-SP-BPI+_I12-050812.pdf.
BPI+ is
-Original Message-
From: Bound, Jim [mailto:[EMAIL PROTECTED]
On the
issue of e2e encrypt/decrypt except the header there are
those for many reasons will not want to permit this for the
reasons you state is my experience.
I may we way off base, but when I read this, all I can
Right. We've already seen AES + CCM implemented in hardware with
802.15.4 radios. While some of those implementations are currently 15.4
specific, the fact that it is not more general could be considered an
'implementation flaw'.
The biggest concern to those of us trying to deal with IEEE
touche. IETF documents remain current unless obsoleted by another
RFC. The corpus is cumulative, so we have to follow the precedent, even
from the deep dark early days like 1998, or document there is consensus
that a spec no longer applies (e.g. RFC 4966 rendering RFC 2766 NAT-PT
historic.)
Basavaraj Patil [EMAIL PROTECTED] writes:
I agree with Thomas about his views on IPsec being a mandatory and
default component of the IPv6 stack. Because of this belief, Mobile
IPv6 (RFC3775) design relied on IPsec for securing the
signaling. This has lead to complexity of the protocol and
Tony,
For those that have forgotten, the entire reason for mandating IPsec is to
get away from the 47 flavors of security that are never really configured
correctly or completely understood. Yes for any given situation someone can
design an optimized protocol, but as soon as the situation
Thomas,
Why do you believe MIP6 did not simply adopt the same security model as MIP4
and instead choose IPsec? It was because of the view that IPsec support in
IPv6 by default exists and hence should be used.
And the IESG statement in RFC4285 needs to be revisited and deprecated
because the
Ed Jankiewicz writes:
As Jim Bound has stated many times, IETF defines standards not
deployment, and the Node Requirements revision should reiterate that the
standard for security in IPv6 is IPsec citing RFC 4301 (successor to
2401). OTOH, we at DoD and NIST are certainly addressing
James,
Ed Jankiewicz writes:
As Jim Bound has stated many times, IETF defines standards not
deployment, and the Node Requirements revision should reiterate that
the standard for security in IPv6 is IPsec citing RFC 4301
(successor
to 2401). OTOH, we at DoD and NIST are certainly
John,
Well, I would say that we (HW, SW, Platform providers) cannot expect
to understand all of the ways that their products will be deployed,
so it is extremely hard to state security is not needed.
That is not what I (and I suspect others) are saying.
What I am saying is that security (in
[EMAIL PROTECTED] writes:
James,
Ed Jankiewicz writes:
As Jim Bound has stated many times, IETF defines standards not
deployment, and the Node Requirements revision should reiterate that
the standard for security in IPv6 is IPsec citing RFC 4301
(successor
to 2401). OTOH, we at
Thomas Narten writes:
Thus, continuing to mandate IPsec (while continuing to punt on key
management) just looks silly.
Indeed. It's a solution out looking for a problem.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W
Hi Thomas,
2008/2/27, Thomas Narten [EMAIL PROTECTED]:
John,
[snip]
And even today, IPv6 only mandates IPsec (with manual keys). No key
managment. And if there is one thing we have learned from practical
deployments, it's all about key mangement/distribution. That is the
hard stuff
James:
James Carlson wrote:
Ed Jankiewicz writes:
As Jim Bound has stated many times, IETF defines standards not
deployment, and the Node Requirements revision should reiterate that the
standard for security in IPv6 is IPsec citing RFC 4301 (successor to
2401). OTOH, we at DoD and
On Feb 27, 2008, at 9:20 AM, James Carlson wrote:
It's not a good argument for everyone must implement security in all
cases in order to be considered a good IPv6 citizen, even if they have
no plans to use those security protocols, so there.
As I understand it, the current architecture of the
quick poll - for those opposed to a MUST requirement for
IPsec, what is your driving objection?
My feeling is that we should not introduce mandatory cost factors for
end devices. There are many sensor-ish devices that do not require
strict security.
If it is possible, could we say that
Dow Street writes:
1. the Internet *does not* need a mandatory security mechanism at
the IP layer
2. the Internet *does* need a mandatory security mechanism at the IP
layer, but IPsec is not the right one because it is too heavyweight
3. the Internet *does* need a mandatory security
The draft should not be considered for 6man as a WG item just yet
because it needs some more work before the draft is even acceptable to
review. Here is some things to look at after I read portions of the
draft at the URL below.
1. Section 1 of the draft says 2001:db8:3001:1:EN is selected as the
On 2008-02-28 09:34, James Carlson wrote:
Dow Street writes:
1. the Internet *does not* need a mandatory security mechanism at
the IP layer
2. the Internet *does* need a mandatory security mechanism at the IP
layer, but IPsec is not the right one because it is too heavyweight
3. the
I lean towards (3) because IPsec without IKE or something is
unmanageable. I could support MUST or SHOULD, or a conditional
statement, and would prefer linking to IKEv2 as part of the package.
Thomas hinted at the chicken and egg problem with IKEv2 - we'd like to
mandate it to encourage
Hi all,
My fear is that if implementations on e.g. sensors show that IPSec is not
affordable for this kind of device, and we put an unconditional MUST, in a few
years from now we will have billions of device which do not respect RFC4294.
With a SHOULD it is the same kind of issue, billions of
My fear is that if implementations on e.g. sensors show that
IPSec is not affordable for this kind of device, and we put an
unconditional MUST, in a few years from now we will have
billions of device which do not respect RFC4294. With a SHOULD
it is the same kind of issue, billions of device
Hi John,
To clarify:
- I was talking of sensors immplementing some IPv6
- It means companies would not care about this RFC
Julien
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: mercredi 27 février 2008 14:44
To: Julien Abeille (jabeille); [EMAIL PROTECTED];
On Feb 27, 2008, at 11:27, Dow Street wrote:
3. the Internet *does* need a mandatory security mechanism at the
IP layer, but IPsec *alone* is insufficient (without IKE, key mgmt,
etc)
This is what I'd prefer with *one* qualification. I would merely
*recommend* it for devices that are
Greetings all,
I've been reading this group for some time and appreciate everyones
work. For the most part I have followed the discussions of the past but
would now like to throw in my 2 cents.
Kevin and many others against mandating (MUST) for IPSec have a valid
point. Many sensors and
Hi all,
I'm not a security expert, so I'm not eligible to make detail
technical discussion on it. But I have the same concern with Pascal
and Jonathan.
As Jonathan and Pascal already explained the concerns on IPsec in
sensor nodes' view, I won't repeat it. I just want to ask the experts
on this
Hi all,
Please don't stick with IKEv2
because IETF also standardized other key exchange protocol,
i.e KINK (kerberos based ipsec key exchange protocol).
Or could you please list those exchange protocols in the RFC
if describing name of specific exchange protocol in the RFC?
To show a list
Hemant Singh;
Thank you for your comments.
At Wed, 27 Feb 2008 16:01:27 -0500,
Hemant Singh (shemant) wrote:
The draft should not be considered for 6man as a WG item just yet
because it needs some more work before the draft is even acceptable to
review. Here is some things to look at after
40 matches
Mail list logo
