Subject: Updates to Node Requirements-bis

From: <[email-masked]>
Date: Sun, 24 Feb 2008 22:53:52 -0600

Hi all,

I am issuing a quick rev to the Node Req.-bis.  There are a couple of
bugs, with respect to the references, that I need to fix still, but I
switched to using Symbolic References, and added a quick & dirty list of
changes from RFC4294.

One question, I assume that I should include "Deprecation of Type 0
Routing Headers in IPv6", RFC 5095 in the document.  Any other
suggestions of things that should still be included in the draft?

thanks,
John
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Mon, 25 Feb 2008 08:19:31 -0800

John,

> suggestions of things that should still be included in the draft?

I agree that should be included.

Bob

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 25 Feb 2008 11:36:32 -0500

John,

It would be nice to have requirements traceability in the IPv6 Node
requirements document. We know you have listed all of the documents
where everything came from, but it would be good to say which parts came
from which documents.  Some traceability is already done in the
document, but it would be good to have traceability for all of the
requirements. For example, saying that "this requirement stems from
section x.y.z of RFCXXXX".

Thanks.

Wes & Hemant
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Sunday, February 24, 2008 11:54 PM
To: [email-masked]
Subject: Updates to Node Requirements-bis

Hi all,

thanks,
John

---

From: "Duncan, Richard J CTR DISA JITC" <[email-masked]>
Date: Mon, 25 Feb 2008 12:03:02 -0500

Classification:  UNCLASSIFIED 
Caveats: NONE

John-

Is there also anyway the new node requirements RFC could be somewhat
reconciled with the new US Government IPv6 Profile and the DoD IPv6 Profile?
It would probably keep the confusion down a bit. 

01010011 01100101 01101101 01110000 01100101 01110010 01000110 01101001

Jeremy Duncan

Joint Interoperability Test Command
IPv6 Test and Evaluation
ManTech Telecommunications & Information Systems
Office: 703-814-8384
Cell: 520-226-1789
__________________________________________________ 
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Monday, February 25, 2008 11:37 AM
To: [email-masked]; [email-masked]
Subject: RE: Updates to Node Requirements-bis

John,

It would be nice to have requirements traceability in the IPv6 Node
requirements document. We know you have listed all of the documents where
everything came from, but it would be good to say which parts came from
which documents.  Some traceability is already done in the document, but it
would be good to have traceability for all of the requirements. For example,
saying that "this requirement stems from section x.y.z of RFCXXXX".

Thanks.

Wes & Hemant
 
-----Original Message-----

Hi all,

I am issuing a quick rev to the Node Req.-bis.  There are a couple of bugs,
with respect to the references, that I need to fix still, but I switched to
using Symbolic References, and added a quick & dirty list of changes from
RFC4294.

One question, I assume that I should include "Deprecation of Type 0 Routing
Headers in IPv6", RFC 5095 in the document.  Any other suggestions of things
that should still be included in the draft?

thanks,
John
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Classification:  UNCLASSIFIED 
Caveats: NONE

---

From: <[email-masked]>
Date: Mon, 25 Feb 2008 11:06:36 -0600

Jeremy,

>Is there also anyway the new node requirements RFC could be 
>somewhat reconciled with the new US Government IPv6 Profile 
>and the DoD IPv6 Profile?

Would you be able to provide a summary of the differences? Also,
are the US Government & the DoD IPv6 profiles publically available?

What we could potentially do is look at resolving any major conflicts,
if possible - or at least have an informative appendix covering this.

Thoughts?
John

---

From: "Duncan, Richard J CTR DISA JITC" <[email-masked]>
Date: Mon, 25 Feb 2008 12:30:38 -0500

John-

I can give you the 2 documents:

DoD IPv6 Standards Profile, Version 2:
http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_product_profile_v2.pdf

US Government IPv6 Profile Version 1, Draft 2:
http://www.antd.nist.gov/usgv6/usgv6-v1-draft2.pdf
 
I would suggest you look at it in the context of the RFC.  The reason is
because these two are different as well.

Jeremy Duncan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 12:07 PM
To: Duncan, Richard J CTR DISA JITC; [email-masked]
Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED)

Jeremy,

>It would probably keep the confusion down a bit. 

Would you be able to provide a summary of the differences? Also, are the US
Government & the DoD IPv6 profiles publically available?

What we could potentially do is look at resolving any major conflicts, if
possible - or at least have an informative appendix covering this.

Thoughts?
John

---

From: Ed Jankiewicz <[email-masked]>
Date: Mon, 25 Feb 2008 13:21:06 -0500

I recently took a pass through both the USG and DoD documents to 
identify differences.  I am also planning to compare the DoD doc against 
this draft.  I will gladly share those comparisons with this list, and 
hope to have it done this week, certainly before the IETF meeting in two 
weeks.

Duncan, Richard J CTR DISA JITC wrote:
> ------------------------------------------------------------------------
>

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: <[email-masked]>
Date: Mon, 25 Feb 2008 12:23:55 -0600

Hi Ed,

That would be great.  If the comparison is useful, we can then include
it as an appendix or at least discuss some of the differences.

thanks,
John 

>From: ext Ed Jankiewicz [mailto:[email-masked]] 
>Sent: 25 February, 2008 10:21
>To: [email-masked]
>Cc: Duncan, Richard J CTR DISA JITC; Loughney John 
>(Nokia-OCTO/PaloAlto)
>Subject: Re: Updates to Node Requirements-bis (UNCLASSIFIED)
>
>I recently took a pass through both the USG and DoD documents 
>to identify differences.  I am also planning to compare the 
>DoD doc against this draft.  I will gladly share those 
>comparisons with this list, and hope to have it done this 
>week, certainly before the IETF meeting in two weeks.
>
>> I would suggest you look at it in the context of the RFC.  
>The reason 
>> is because these two are different as well.
>>
>>
>somewhat 
>> Would you be able to provide a summary of the differences? Also, are 
>> the US Government & the DoD IPv6 profiles publically available?
>>
>Fort Monmouth Branch Office - IPv6 Research Supporting DISA 
>Standards Engineering Branch

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 25 Feb 2008 16:24:49 -0500

> From: Duncan, Richard J CTR DISA JITC 

> The reason is

I would agree that someone should reconcile, or at least identify, all
the differences, although I don't know that it should be the IETF. I
would expect that the rationale for the differences does not lie within
the IETF?

One difference between RFC 4294 and I-D 4294-bis is that AH was demoted
from a MUST to a MAY. Is a specific reference identitied, and I just
missed it maybe? I noticed that the latest NIST IPv6 Profile
accommodates this change.

One MUST that the NIST IPv6 Profile introduced was mandating of OSPFv3
as the routing protocol. Is this because RIPng is not beiong adopted in
practice? Small networks should do well with RIPng, I would think,
unless RIPng is never used in practice. And in principle, there could be
a case made for static routing tables in special cases. I'm not sure why
the routing protocol mandate for all Government nets.

Same applies to IKEv2. The IETF does not mandate its use, while NIST
does.

One detail I'm not clear on is whether or why routers, which may well be
in non-secure spaces, are required to support ESP. I-D 4294-bis doesn't
elaborate - it just says "nodes" must. Older versions of the NIST IPv6
Profile said that routers had to support AH to protect the routing
protocols. My assumption is that this rationale, protection of routing
protocols, is why now NIST is mandating that routers support ESP, now
that AH has been demoted to a MAY. A brief clarification would be
welcome.

Another mandate in the NIST IPv6 Profile is that both tunneling and dual
stack mechanisms be supported in Government networks. But what about
small networks that already support dual stacks? They should have no
reason to use tunneling as a mechanism for IPv6 transition?

Those are some of the issues I saw. I'm sure there are many I didn't
focus on.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Feb 2008 13:20:37 +1300

> would expect that the rationale for the differences does not lie within

The IETF's job is to make the Internet work better (RFC 3935) so we
obviously have to give that priority. It would certainly be useful
to understand why the DISA and NIST profiles differ from the IETF's
profile, but aligning with DISA and NIST shouldn't be a goal in itself
as far as I can see.

> accommodates this change.

As does IPsec (RFC 4301 section 3.2 first paragraph).
> Same applies to IKEv2. The IETF does not mandate its use, while NIST

See RFC 4301 section 3.2 *last* paragraph. The problem is that
the real world is slow to move to IKEv2. It's important to describe
what's real, I think. The NIST requirement is "interesting" given
the state of products.

> that AH has been demoted to a MAY. A brief clarification would be

Would you want to ship a router that couldn't protect the network layer?

> reason to use tunneling as a mechanism for IPv6 transition?

That's an operational issue, not a node requirement. Would you want
to ship a stack that could support a dual stack but not use it
to tunnel?

   Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 25 Feb 2008 20:29:59 -0500

> From: Brian E Carpenter [mailto:[email-masked]] 
> To: Manfredi, Albert E

> > the differences, although I don't know that it should be the IETF.

> profile, but aligning with DISA and NIST shouldn't be a goal in itself

Typically, the NIST requirements seem more stringent. My only point is
that if any explanation for differences is deemed desirable, I would
expect that DISA or NIST be the ones who explain why these differences
were introduced. I think we agree. The IETF can only guess at reasons.

> what's real, I think. The NIST requirement is "interesting" given

I-D 4294-bis says in Section 9.4:

   An implementation MUST support the manual configuration of the
   security key and SPI.  The SPI configuration is needed in order to
   delineate between multiple keys.

   Key management SHOULD be supported.  Examples of key management
   systems include IKEv2 [RFC4306] and Kerberos; S/MIME and TLS include
   key management functions.

   Where key refresh, anti-replay features of AH and ESP, or on-demand
   creation of Security Associations (SAs) is required, automated keying
   MUST be supported.

So automatic key exchange is not considered mandatory by the IETF in all
cases, but it is mandatory in the NIST Profile. At least, that's how I
read that.

> > My assumption is that this rationale, protection 
> > of routing

Depends what you mean. A router located in a non-secure space can be
expected to protect the way it populates its routing tables. That's
about it, though. AH seemed a good way to do that, but ESP, for the
purpose of protecting RIPng or OSPFv3 messages, should be fine too, I
think.

Expecting more than that seems like wishful thinking, IF the routers are
in non-secure spaces. Encypting spoofed messages coming from non-secure
hosts does not make these any more secure. What would make these more
secure is ESP host-to-host, or ESP tunneled between security gateways.

> > stack mechanisms be supported in Government networks.

> to ship a stack that could support a dual stack but not use it

Yes. If I provide a special-purpose network that provides dual-stack,
why should I have the added burden of supporting tunneling that I will
never use? My preferred approach is to not require features that won't
be used, but allow them to be added if necessary, in the future. This
saves development time and testing efforts.

Bert

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Mon, 25 Feb 2008 23:27:57 -0500

Colleagues,

Although I do not speak for either DISA or NIST, I believe that the
spirit of Jeremy's request was that the specifications (RFCs) required
by the DISA and NIST documents be considered for inclusion in the
updated node requirements document.  I am working on he deltas between
the NIST draft 1 and 2, and the DISR.

Best Regards,
 
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Manfredi, Albert E
Sent: Monday, February 25, 2008 8:30 PM
To: Brian E Carpenter
Cc: [email-masked]
Subject: RE: Updates to Node Requirements-bis

   Where key refresh, anti-replay features of AH and ESP, or on-demand
   creation of Security Associations (SAs) is required, automated
keying
   MUST be supported.

So automatic key exchange is not considered mandatory by the IETF in
all
cases, but it is mandatory in the NIST Profile. At least, that's how I
read that.

Expecting more than that seems like wishful thinking, IF the routers
are
in non-secure spaces. Encypting spoofed messages coming from non-secure
hosts does not make these any more secure. What would make these more
secure is ESP host-to-host, or ESP tunneled between security gateways.

Bert

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Feb 2008 12:45:15 +0800

On Feb 26, 2008, at 5:24 AM, Manfredi, Albert E wrote:

> One detail I'm not clear on is whether or why routers, which may  
> well be in non-secure spaces, are required to support ESP. I-D 4294- 
> bis doesn't elaborate - it just says "nodes" must.

The question, at least in my mind, isn't whether they always have to  
use it, but whether sometimes it is appropriate to use. If it is  
sometimes appropriate, then it has to be implemented and supported  
whether or not it is configured.

Operationally, I think that SSH/SSL is the mechanism most people use  
to secure network management, which raises a question as to the real  
need for IPsec in the router. That is a discussion that should be had  
with the operational community.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Feb 2008 12:49:51 +0800

On Feb 26, 2008, at 1:03 AM, Duncan, Richard J CTR DISA JITC wrote:

> somewhat reconciled with the new US Government IPv6 Profile and the  
> DoD IPv6 Profile?

I find myself of two minds here.

 From one perspective, is there a desire that the two be identical?  
If so, is there any chance that the authors of those profiles could  
talk with the IETF about their lines of reasoning? My sense is that  
the profiles are just that - that whatever the IETF may have thought  
on a topic, that NIST and DoD have each chosen to think differently,  
and that a vendor looking at the issues needs to review each of the  
relevant sets of requirements.

 From the other perspective, whether or not the two are identical,  
there are obviously different lines of reasoning here, and the IETF  
(gasp) might be incorrect on one point or another. Which brings me  
back to - is there any chance that not only the differences could be  
summarized, but the reasoning behind the differences?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Tue, 26 Feb 2008 13:41:37 +0800

The latest draft: draft-ietf-6man-node-req-bis-00.txt
still lists IPsec as mandatory to implement.

As I mentioned last IETF meeting, this is creating a problem for certain
kind of devices, like cable modems, who have a very limited memory
footprint. Those devices operate in an environment where IPsec is not used
and mandating its implementation has a serious cost: it means that legacy
devices cannot be upgraded to IPv6...

In DOCSIS 3.0, the decision was to NOT require IPsec implementation on those
devices. I'm sure other environment have made or will make similar choices.

Moreover, to make the point more general, we are specifying/buying many
other types of devices where we know that IPsec will never be used. Why
should the vendor of those devices have to implement it? Because one day I
might decide to deploy it? IMHO, this is not a good think, because in the
meantime, I will have to run extra code which means extra bugs, more memory
and more risks of miss-configuration.

I would like to suggest that the node requirements remove any mention of
IPsec being mandatory to implement and instead includes text in the line of:
"if you are going to implement IPsec, here is what you should/must do".

  - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Feb 2008 08:00:57 +0200 (EET)

> the routing protocol mandate for all Government nets.

IS-IS is currently probably more widely used for IPv6 routing than 
OSPFv3.

Given that there are multiple good options that any reasonable 
network could deploy, I don't see why the IETF should make a 
recommendation in this space.

NIST's goal was probably, "some implementations on the field just 
support static and maybe RIPng.  We want to mandate something more 
scalable, and OSPFv3 is as good an option as any".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Nobuo OKABE <[email-masked]>
Date: Tue, 26 Feb 2008 16:53:31 +0900 (JST)

Hi Alan,

Could you please show us detailed evidences
or something about your sugestion?

We have raised the same kind of discussion at the very beginning of
Node Requirement activities (draft-okabe-ipv6-lcna-minreq-XX) about 2002.

  At that moment, the consensus was not to remove IPsec from standard
  by the state of the art. At least, that was my understanding.

  Here are the record of that discussion:
  http://www.taca.jp/internet-draft/feedback-01/summary.html
  http://www.taca.jp/internet-draft/feedback-01/maillist.html

  Then, we have tried to develop IPsec solution
  on small embedded devices with reasonable footprint/performance.

Through our experience, precisely speaking,
heavy part is not IPsec body
but key exchange protocols, e.g. ike and ikev2,
if you can use cryptographic hardware (ex. AES and SHA1).
(and crypt h/w seems common for small embedded devices, today.)

  By our IPsec implementation experience on 16-bits CPU system,
  object code size of IPsec body is not so big:
    SADB handling + Inbound/Outbound IPsec processing = 8kbytes

  However, we gave up to implement ike and ikev2 on embedded devices
  because of their complexity and the use of public-key crypt.

  Instead, we standardized Kerberos based IPsec key exchange protocol
  as KINK (RFC4430) with cisco people. 
  Roughly speaking, KINK can be implemented with small footprint (45kbytes)
  and reasonable processing time (70msec/exchange, w/o waiting time)
  on 16-bits CPU system.

  The following paper shows some of data:
  http://hiroshi1.hongo.wide.ad.jp/hiroshi/papers/2007/indin2007-Okabe.pdf

I understand that our approach may be not universal but specific.
However, for me, your sugestion seems too rough to change the consensus.
I would be happy if I see your evidence.

I hope that the records and the experiences described above
helps the discussion.

Thanks,

From: Alain Durand <[email-masked]>
Subject: Making IPsec *not* mandatory in Node Requirement ( was Re: Updates to Node Requirements-bis (UNCLASSIFIED))
Date: Tue, 26 Feb 2008 13:41:37 +0800

> "if you are going to implement IPsec, here is what you should/must do".

----- Nobuo Okabe (Yokogawa Electric Corporation)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Tue, 26 Feb 2008 16:48:36 +0800

The problem is that some of those devices have really limited memory and
they already do (too?) many things, so there is no room left... Some vendors
had to go back at their code and spend a lot of time and effort to clean
things up to make room for the very basic IPv6 code, so every kb count.

The whole idea of asking them to do extra efforts to implement a
functionality that is not needed and that will introduce bugs & instability
is not very appealing.

Again, this last argument applies also to devices that do not have memory
problems: if I do not need functionality X, I'd rather like not to have it
implemented as it will lower the operational risks.

In other words, what functionality goes into a device is a business decision
that is driven by the application considered. The node requirement document
is a good place to say: if you want functionality X, here is what you have
to do to make sure it interoperates well, it is not the place to make
business decisions.

If IPsec was used ubiquitously, I'd probably have another opinion. The
reality is that today, IPsec usage is more the exception than the rule (at
least in my environment), and I do not see this changing soon.

  - Alain.

---

From: Nobuo OKABE <[email-masked]>
Date: Tue, 26 Feb 2008 18:51:16 +0900 (JST)

Hi Alain,

I really know the situation what you are saying.

And there is other fact:

  Practical activities usually take over standardized specification.
  Anyway, aggressive vendors sometimes remove unused functions
  even though those are specified as MUST.

So, the discussion you rose may be related to not only technical one
but also motto/spirit of IETF's standardization activity.
# "practical vs. principle"-like...I cannot find appropriate words in English.

Then, I have opposite ideas.

  Principal:
  In the future, implementation issue will be solved somehow (ex. crypt h/w).
  So security requirement should be remained.

  Practical:
  If there is something MUST item which almost implementations ignore,
  it can harm the value of standardization itself.

Hmm....I think that standardized spec should be targeted to
not everything but the majority.

  There is no rule but has some exception.

But what is the majority?.....Hmm....

Thanks,

From: Alain Durand <[email-masked]>
Subject: Re: Making IPsec *not* mandatory in Node Requirement
Date: Tue, 26 Feb 2008 16:48:36 +0800

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Feb 2008 12:05:07 +0200 (EET)

> implemented as it will lower the operational risks.

I think this discussion somewhat misses the point because some folks 
feel informational roadmap documents have more weight than they 
actually do (according to IETF procedures, or even in practice in 
vendors' feature planning).  (E.g., there was similar discussion about 
RFC4614.)

The node requirements document, despite its misleading title, is 
INFORMATIONAL.  It does not represent IETF consensus, so even if the 
document would say every IPv6 node MUST implement IPsec, it would mean 
basically nothing.

Where is a Standards Track or BCP document that says IPsec is 
mandatory?

If vendors need to make tradeoffs of what they implement or don't 
implement, that's their call.  They can't call that product to be 
"RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or 
claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC 
number which mandates IPsec).  That's all.

The product also might not get IPv6 ready logo certifications and 
such, but that's not IETF's business anyway.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 26 Feb 2008 08:06:12 -0500

Pekka,

The node requirement draft as I read it from 

http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt

is on Standards Track. Did I miss anything because you think this node
requirement doc is an INFORMATIONAL draft?

As for IPSec and IPv6, indeed it is true that IPSec is mandatory for
IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is
mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security
Architecture for the Internet Protocol). Snipped from the RFC's is
section 10 shown below between square brackets.

[10. Conformance Requirements

   All IPv4 systems that claim to implement IPsec MUST comply with all
   requirements of the Security Architecture document.  All IPv6 systems
   MUST comply with all requirements of the Security Architecture
   document.]

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.
Cable IPv6 standards came much later. We will have to see what common
ground can be met to address Alain's concern.

Hemant
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pekka Savola
Sent: Tuesday, February 26, 2008 5:05 AM
To: Alain Durand
Cc: [email-masked]; [email-masked]; Fred Baker (fred)
Subject: the role of the node "requirements" document

On Tue, 26 Feb 2008, Alain Durand wrote:
> The problem is that some of those devices have really limited memory 
> and they already do (too?) many things, so there is no room left... 
> Some vendors had to go back at their code and spend a lot of time and 
> effort to clean things up to make room for the very basic IPv6 code,
so every kb count.
> functionality that is not needed and that will introduce bugs & 
> instability is not very appealing.
>
> problems: if I do not need functionality X, I'd rather like not to 
> have it implemented as it will lower the operational risks.

I think this discussion somewhat misses the point because some folks
feel informational roadmap documents have more weight than they actually
do (according to IETF procedures, or even in practice in vendors'
feature planning).  (E.g., there was similar discussion about
RFC4614.)

Where is a Standards Track or BCP document that says IPsec is mandatory?

If vendors need to make tradeoffs of what they implement or don't
implement, that's their call.  They can't call that product to be
"RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or
claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC number
which mandates IPsec).  That's all.

The product also might not get IPv6 ready logo certifications and such,
but that's not IETF's business anyway.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 26 Feb 2008 09:27:15 -0500

Hemant,
     Take a look at the category for RFC 4294 at 
http://tools.ietf.org/html/rfc4294.  It is Informational and no 
discussion has occurred to change that classification for this update.

Regards,
Brian

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 14:42:01 -0000

> 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
<http://www.ipv6ready.org/about_phase2_test.html>
clearly does not consider IPsec to be part of the IPv6 core protocols
and therefore lots of implementations will not have it.

Cable boxes are not much different from general purpose computers
running Linux. In fact, they may use Linux for all I know. In any
case, they are complex devices and if you looked at an architecture
diagram for them they would like rather like a network in a box
with many functions on separate chips (or areas of an FPGA) all
communicating with various internal protocols and busses.

But IPv6 is not just for devices like that. It was also intended
to be something that could be implemented on embedded devices
that often use 8-bit CPUs with the IP stack written in carefully
handcoded assembly language. TINI is an example of such a device
but there are hundreds of them out there and manufacturers continue
to introduce new 8-bit microcontrollers all the time.

If you have any contacts with Yokogawa in Japan, they have a lot
of experience in this area and will be able to give a better idea
of how common it is to implement IPv6 without IPsec. WIDE people
may also know more about this.

--Michael Dillon

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 08:42:12 -0600

Hi all,

If people feel that further disclaimers are needed in the current bis
draft
to ensure that people understand that it only meant as an informative
compendium, then I am happy to add that extra text.

John 

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Brian Haberman
>Sent: 26 February, 2008 06:27
>To: [email-masked]
>Subject: Re: the role of the node "requirements" document
>
>Hemant,
>http://tools.ietf.org/html/rfc4294.  It is Informational and 
>no discussion has occurred to change that classification for 
>this update.
>
>Regards,
>Brian
>
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Pekka Savola
>> actually do (according to IETF procedures, or even in 
>practice in vendors'

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 26 Feb 2008 10:43:02 -0500

> From: Pekka Savola [mailto:[email-masked]] 

> scalable, and OSPFv3 is as good an option as any".

I completely agree. And, if the NIST Profile were directed at commodity
router vendors, e.g. for enterprise networks of Govt agencies, there
would be some logic in that. However, all IPv6 networks owned and
operated by the Government are not that sort of network. This is similar
to Alain Durand's point about cable modems, where you want the smallest
possible memory footprint when supplying the needed services.

Bert

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 26 Feb 2008 10:52:55 -0500

Brian,

Indeed, I know that RFC4294 is INFORMATIONAL. I got confused because I
see the new node-req-bis draft URL snipped below to be on Standards
Track.

Sorry, if I am missing some IETF process. I was expecting the bis draft
above to be INFORMATIONAL as well.

Thanks.

Best Regards.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Tuesday, February 26, 2008 9:27 AM
To: [email-masked]
Subject: Re: the role of the node "requirements" document

Hemant,

Regards,
Brian

> actually do (according to IETF procedures, or even in practice in
vendors'

mandatory?

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 26 Feb 2008 07:58:08 -0800

Hi Albert,

Instead of mandating every protocol, would it be helpful to further
break the functionality into two subclasses and have seperate
requirements in such cases. I do not like the idea of having to impose
a superset of the requirements for all such nodes.

In my view such functionality should kept to the minimum.

Thanks,
Vishwas

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 26 Feb 2008 11:12:16 -0500

> From: Vishwas Manral [mailto:[email-masked]] 
> Sent: Tuesday, February 26, 2008 10:58 AM
> To: Manfredi, Albert E
> Cc: Pekka Savola; [email-masked]

Something along those lines would help. Or just qualifying some of these
MUSTs, much like I-D 4294-bis does.

In my case, it's not IPsec per se at issue, although even there, the
security model has to make sense. For example, it doesn't make much
sense to specify a vault door as the front door to your home, and at the
same time provide no walls on either side of this door. If you are going
to secure a network, sending plaintext to routers which are located in
non-secure spaces, and expecting these routers to make the network
secure, is clearly not going to fly.

Bert

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Feb 2008 11:18:33 -0500

IMO, we need to get over the idea that IPsec is mandatory in
IPv6. Really. Or that mandating IPsec is actually useful in practice.

It is the case that mandating IPsec as part of IPv6 has contributed to
the hype about how great IPv6 is and how one will get better security
with IPv6. Unfortunately, that myth has also harmed the overall IPv6
deployment effort, as people look more closely and come to understand
that deploying IPv6 doesn't automatically/easily yield improved
security.

We all know the reality of security is very different and much more
complicated/nuanced then just saying "use IPsec".

Consider:

IPsec by itself (with no key management) is close to useless. The
average person cannot configure static keys, so the result is (in
effect) a useless mandate (as a broad mandate for ALL nodes).

What applications actually make use of IPsec for security? A lot fewer
than one might think. For many IPv6 devices/nodes, if one actually
looks at the applications that will be used on them, they do not use
IPsec today for security. And, there are strong/compelling arguments
for why IPsec is not the best security solution for many applications.
Thus, requiring IPsec is pointless.

To be truly useful, we (of course) need key management. If we want to
mandate key management, the stakes go way up. IKEv1/v2 is not a small
implementation effort. And, we are now in the funny situation where
IKEv1 has been implemented, but due to shortcomings, IKEv2 has already
been developed. IKEv2 has been out for over 2 years, but
implementations are not widespread yet. So, would we mandate IKEv1
(which is obsoleted and has documented issues), or do we mandate
IKEv2, even though it is clear it is not widely available yet?

IMO, we should drop the MUST language surrounding IPsec. The technical
justification for making it MUST are simply not compelling. It seems
to me that the MUST is there primarily for historical/marketing
reasons.

Note that dropping the MUST will not mean people stop implementing
IPsec, where there is compelling benefit. Indeed, note that the USG
has already moved away from IKEv1 and has strongly signalled that it
will require IKEv2 going forward. So I am confident that IPsec (and
IKE) will get implemented going forward.

But there is no reason why IPsec should be mandated in devices where
it is clear (based on the function/purpose of the device) that IPsec
will in fact not actually be used.

As a general "node requirement", SHOULD is the right level, not MUST.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Feb 2008 11:29:09 -0500

> document would say every IPv6 node MUST implement IPsec, it would mean 

You may be correct in a narrow, legalistic sense.  In practice,
however, saying that the document carries no weight is simply not
true. The facts speak otherwise.

When people look around for guidance on what to implement, they do in
fact refer to the IPv6 Node Requirements RFC. Even though it is only
informational and (supposedly) carries "no weight", people do in fact
defer to it when they are unsure of what to do.

Consider the USG IPv6 profiles. DoD (via JITC) has issued
profiles. (See http://jitc.fhu.disa.mil/apl/ipv6.html). NIST is also
close to finalizing profiles (see
http://www.antd.nist.gov/usgv6/). These will be mandatory (in a MUST
sense) for products sold to USG.

Both profiles relied heavily on the recommendations of RFC 4294.

Thomas

---

From: Ed Jankiewicz <[email-masked]>
Date: Tue, 26 Feb 2008 11:36:52 -0500

(full disclosure - I am one of the editors of the DoD IPv6 Profiles 
document - but comments are my own as an individual)

1.  Can we discuss the normative level of the revised Node Requirements 
document?  My preference would be that it is a standards track or BCP 
ultimately, to give firm definition of what an IPv6 node MUST do.  
Another INFORMATIONAL document like RFC4294 is merely a helpful 
annotated bibliography, but that may be all we can accomplish in a 
reasonable timeframe, all in all it doesn't make a big difference.

2.  I don't expect (nor believe it appropriate) that this revision will 
satisfy all the needs of either NIST or DoD for defining "IPv6 Capable" 
for our client organizations.  That being said, several folks are 
already reviewing the three drafts side by side, to help ensure that the 
Node Requirements accurately defines the requirements that apply to ALL 
IPv6 nodes for ALL deployments.  The editors of the DoD and NIST 
documents should concentrate on the delta from that baseline for 
specific US Government and DoD requirements and deployments. 

3.  Specifically with respect to IPsec and IKEv2, regardless of the 
"settlement" of that debate years ago, there are still valid questions 
about which requirements apply to ALL IPv6 nodes.  I hope this revision 
of the Node Requirements can reiterate the commitment to IPsec, but if 
it does not, DoD (and NIST) can certainly state stronger and more 
specific requirements in our documents.  DoD in particular answers to a 
higher authority on security and cryptographic requirements, and will 
probably require things that a small office or home user would never need.

A prior message in this thread (from Jeremy Duncan) included pointers to 
the NIST and DoD profiles drafts, feel free to send any 
questions/comments to the editors off-list.  Some of the differences are 
worth discussing on this list to see if there is consensus for changes 
to the Node Requirements draft.  Additional work will need to be done by 
the editors of both the DoD and NIST drafts to address the specific 
needs of our clients that don't apply to everyone.

Hemant Singh (shemant) wrote:
>>    requirements of the Security Architecture document.  All IPv6
>>     
> systems
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 26 Feb 2008 09:30:32 -0800

Hi Thomas,

I would again suggest that instead of making it non-mandatory, we
could provide a seperate set of requirements - for different device
types.

OSPFv3 currently uses IPsec because the assumption is that IPv6
mandates IPsec, and that means we do not need any other mechanism for
the same. OSPFv2 (normal OSPF) uses its own internal mechanism for
authenticating protocol packets.

The idea is that if you change such requirements, it may break the
assumptions taken by the other protocols regarding the same.

Thanks,
Vishwas

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 26 Feb 2008 11:58:16 -0600

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 not
really helped either in adoption or implementation.
IPsec based security is an overkill for Mobile IPv6 and illustrates the
point that you do not have to use it simply because it happens to be an
integral part of IPv6.

-Basavaraj

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 12:00:33 -0600

Thomas,

>As a general "node requirement", SHOULD is the right level, not MUST.

I veer to being somewhat conservative in this area. I don't think that
we should be  
re-interpreting Standards-track RFCs in the Node Req document.  I think
that we can only refer
to what the base standards track RFCs state, and provide some text to
guide the reader.  

I still tend to think that IPSec is a good enabler to have, on a hw or
sw platform, for example.
Whether it is activiated or used is another story.  Also, understanding
the overall security
solutions that should be used in different deployments are quite
complicated, and can only
get worse if certain solutions are not available.  

At a high-level, creating any IPv6 implementation without any security
solutions is a problematic,
IMO.  If IBM, Nokia or any other company would sell an IPv6 stack as
part of a  solution that provided 
no security, I don't think that would be very good or useful. I think
some aspects of security
needs to be a MUST as part of an overall IPv6 stack, however, there are
many choices and parts of
a potential solution.  I think we should look at what the overall IETF
concensus for a minimum
requirement would be.  

My question is, does the IETF have any such consensus?

John

>From: ext Thomas Narten [mailto:[email-masked]] 
>Sent: 26 February, 2008 08:19
>To: Nobuo OKABE
>Cc: [email-masked]; Loughney John 
>(Nokia-OCTO/PaloAlto); [email-masked]; [email-masked]
>It is the case that mandating IPsec as part of IPv6 has 
>contributed to the hype about how great IPv6 is and how one 
>will get better security with IPv6. Unfortunately, that myth 
>has also harmed the overall IPv6 deployment effort, as people 
>look more closely and come to understand that deploying IPv6 
>doesn't automatically/easily yield improved security.
>
>We all know the reality of security is very different and much 
>more complicated/nuanced then just saying "use IPsec".
>
>Consider:
>
>IPsec by itself (with no key management) is close to useless. 
>The average person cannot configure static keys, so the result is (in
>What applications actually make use of IPsec for security? A 
>lot fewer than one might think. For many IPv6 devices/nodes, 
>if one actually looks at the applications that will be used on 
>them, they do not use IPsec today for security. And, there are 
>strong/compelling arguments for why IPsec is not the best 
>security solution for many applications.
>To be truly useful, we (of course) need key management. If we 
>want to mandate key management, the stakes go way up. IKEv1/v2 
>is not a small implementation effort. And, we are now in the 
>funny situation where
>IKEv1 has been implemented, but due to shortcomings, IKEv2 has 
>already been developed. IKEv2 has been out for over 2 years, 
>but implementations are not widespread yet. So, would we 
>mandate IKEv1 (which is obsoleted and has documented issues), 
>or do we mandate IKEv2, even though it is clear it is not 
>widely available yet?
>
>IMO, we should drop the MUST language surrounding IPsec. The 
>technical justification for making it MUST are simply not 
>compelling. It seems to me that the MUST is there primarily 
>for historical/marketing reasons.
>
>Note that dropping the MUST will not mean people stop 
>implementing IPsec, where there is compelling benefit. Indeed, 
>note that the USG has already moved away from IKEv1 and has 
>strongly signalled that it will require IKEv2 going forward. 
>So I am confident that IPsec (and
>But there is no reason why IPsec should be mandated in devices 
>where it is clear (based on the function/purpose of the 
>device) that IPsec will in fact not actually be used.
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 26 Feb 2008 10:13:02 -0800

Hi Basavraj,

But isn't that something IPsec needs to improve on. We already have
efforts like BTNS with "connection latching" in IPsec which may help
to ease the load on the end devices, which seems to have been the main
issue raised.

Thanks,
Vishwas

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 26 Feb 2008 12:21:20 -0600

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 mechanisms. But because of
the prevailing thinking that IPsec MUST be used as the security mechanism,
we stuck with it and are lets say not too happy about it.

-Basavaraj

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 26 Feb 2008 18:30:11 +0000

I concur with Jeffrey regarding the email objective to the IETF below.  The IETF develops specifications and guidelines (being loose here with the term). Our role is to "not" standardize deployment practices.  The market uses this SDO work here to define their deployment scenarios for their business.  GM, Boeing, USG and DOD, Wal-Mart, British Telecom, SKT, Toyota, etc. are all businesses and they will adopt what is mandatory or not-mandatory to support their missions and goals. What the market does depend on from us in the IETF is interoperability across the specifications, though I would expand that to the capabilties of connectivity, interoperability, discovery, security, and end-to-end.  However, if we can learn from the market for the case being node requirements, within this discussion, that is a prudent and useful exercise to pursue as an input data point to us, and John's position to us I think reflects this quite well.

Regarding IPsec:

IPv6 can restore the capability of end-to-end between two nodes without NAT methods being used, through globally routable addresses, which is required by several technology trends in the market (not enough address space with IPv4).  Using IPsec encryption (the market will determine the PKI is my view) a user can encrypt/decrypt end-to-end their data below the IP header in the case where there is zero trust for any middle node within the end-to-end network path, and any edge distributed firewalls (my view of where they are headed at the secure edge) simply passes IPsec traffic through as a policy and trusts the IPsec connection.  At Danvers, I think 1995, I was against IPsec being mandatory for IPv6 and the primary reason (not the only one I also liked SKIP and other issues :--)) was it was to much of a MUST to put on IPv6 development in the market at that time as an implementor at that time.  I and others lost that debate in the IETF.  Today it is different the "network stack
 s" to support IPv6 for the most part have all been developed within any commercial product (clearly more work is requiired above the network stack) I am aware of at this time. If IPsec is a MUST my view is that today most of it has been developed by most commercial products, and it does state from this SDO IPsec is required for proper secure operations at the IP Layer.  Today I think it should be a MUST and for node requirements from the IETF view. For the market it will become a MUST product requirement or commercial products simply will loose to their competitors who do support IPsec, and that is how the free market economy should work, and the IETF should not try to influence that aspect of the market.  My view is all enterprises should mandate IPsec and if they do there is nothing we can do about that in the IETF.  But, we should make sure IPsec supports the IETF requirements we deem necessary for any protocol specification.

/jim

> Behalf Of Dunn, Jeffrey H.
> Sent: Monday, February 25, 2008 11:28 PM
> To: Manfredi, Albert E; Brian E Carpenter
> Cc: [email-masked]
> Although I do not speak for either DISA or NIST, I believe
> that the spirit of Jeremy's request was that the
> specifications (RFCs) required by the DISA and NIST documents
> be considered for inclusion in the updated node requirements
> document.  I am working on he deltas between the NIST draft 1
> and 2, and the DISR.
>
> Best Regards,
>
> Jeffrey Dunn
> Info Systems Eng., Lead
> MITRE Corporation.
>
> Behalf Of Manfredi, Albert E
> > > I would agree that someone should reconcile, or at least
> identify,
> > > all the differences, although I don't know that it should be the
> > > IETF.
>
> > obviously have to give that priority. It would certainly be
> useful to
> > understand why the DISA and NIST profiles differ from the IETF's
> Typically, the NIST requirements seem more stringent. My only
> point is that if any explanation for differences is deemed
> desirable, I would expect that DISA or NIST be the ones who
> explain why these differences were introduced. I think we
> agree. The IETF can only guess at reasons.
>
> > See RFC 4301 section 3.2 *last* paragraph. The problem is that the
> > real world is slow to move to IKEv2. It's important to
> describe what's
> > real, I think. The NIST requirement is "interesting" given
> the state
> > of products.
>
> So automatic key exchange is not considered mandatory by the
> IETF in all cases, but it is mandatory in the NIST Profile.
> At least, that's how I read that.
>
> > > My assumption is that this rationale, protection of routing
> > > protocols, is why now NIST is mandating that routers support ESP,
> > > now that AH has been demoted to a MAY. A brief
> clarification would
> > > be welcome.
> >
> Depends what you mean. A router located in a non-secure space
> can be expected to protect the way it populates its routing
> tables. That's about it, though. AH seemed a good way to do
> that, but ESP, for the purpose of protecting RIPng or OSPFv3
> messages, should be fine too, I think.
>
> Expecting more than that seems like wishful thinking, IF the
> routers are in non-secure spaces. Encypting spoofed messages
> coming from non-secure hosts does not make these any more
> secure. What would make these more secure is ESP
> host-to-host, or ESP tunneled between security gateways.
>
> > > Another mandate in the NIST IPv6 Profile is that both
> tunneling and
> > > dual stack mechanisms be supported in Government networks.
>
> > That's an operational issue, not a node requirement. Would
> you want to
> > ship a stack that could support a dual stack but not use it
> to tunnel?
>
> Yes. If I provide a special-purpose network that provides
> dual-stack, why should I have the added burden of supporting
> tunneling that I will never use? My preferred approach is to
> not require features that won't be used, but allow them to be
> added if necessary, in the future. This saves development
> time and testing efforts.
>
> Bert

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 26 Feb 2008 18:50:04 +0000

For defense in depth scenarios I disagree in the case for the MN to verify with the HA. But I see your point.
/jim

> Behalf Of Basavaraj Patil
> Sent: Tuesday, February 26, 2008 12:58 PM
> To: Thomas Narten; Nobuo OKABE
> Cc: John Loughney; [email-masked]; [email-masked]
> 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 not really helped either in
> adoption or implementation.
> IPsec based security is an overkill for Mobile IPv6 and
> illustrates the point that you do not have to use it simply
> because it happens to be an integral part of IPv6.
>
> -Basavaraj
>
>
> > IMO, we need to get over the idea that IPsec is mandatory in IPv6.
> > Really. Or that mandating IPsec is actually useful in practice.
> >
> contributed to

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 26 Feb 2008 18:56:22 +0000

I don't see the implementation complexity as supporting rationale but would be open to hearing the issues of signaling maybe?  MIPv6, IPsec, and IKEv2 (I also think it was the market mandate IKEv2 right now) do need to be cohesive wihin an implementation but clearly different discrete components with a network stack software design The approach or at least the way I believe it should be engineered in a network stack I think the integration is not a problem.  I don't think we should not require a function in the IETF because it is percieved that "integrating a protocol like Mobile IPv6 with IPsec and IKE/IKEv2" is to complex because I would disagree with that assumption.

/jim

> Sent: Tuesday, February 26, 2008 1:21 PM
> To: ext Vishwas Manral
> Cc: Thomas Narten; John Loughney; [email-masked]; [email-masked]
> 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 .
> Mobile IPv6 signaling can be secured via simpler mechanisms.
> But because of the prevailing thinking that IPsec MUST be
> used as the security mechanism, we stuck with it and are lets
> say not too happy about it.
>
> -Basavaraj
>
>
> >>  Because of this belief, Mobile IPv6 (RFC3775) design
> relied on IPsec
> >> for  securing the signaling. This has lead to complexity of the
> >> protocol and not  really helped either in adoption or
> implementation.
> illustrates
> >> the  point that you do not have to use it simply because
> it happens
> >> to be an  integral part of IPv6.
> >>
> >>  -Basavaraj
> >>
> >>
> >>
> >>
> contributed
> >>> to the hype about how great IPv6 is and how one will get better
> >>> security with IPv6. Unfortunately, that myth has also harmed the
> >>> overall IPv6 deployment effort, as people look more
> closely and come
> >>> to understand that deploying IPv6 doesn't
> automatically/easily yield
> >>> improved security.
> >>>
> >>> What applications actually make use of IPsec for security? A lot
> >>> fewer than one might think. For many IPv6 devices/nodes, if one
> >>> actually looks at the applications that will be used on
> them, they
> >>> do not use IPsec today for security. And, there are
> >>> To be truly useful, we (of course) need key management.
> If we want
> >>> to mandate key management, the stakes go way up. IKEv1/v2
> is not a
> >>> small implementation effort. And, we are now in the funny
> situation
> >>> where
> >>> already been developed. IKEv2 has been out for over 2 years, but
> >>> compelling. It seems to me that the MUST is there primarily for
> >>> historical/marketing reasons.
> >>>
> implementing
> >>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>> Requests: http://www.ietf.org/mailman/listinfo/ipv6
> >>>
> >>  IETF IPv6 working group mailing list  [email-masked]
> Administrative
> >> Requests: http://www.ietf.org/mailman/listinfo/ipv6
> >>

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 26 Feb 2008 20:11:42 +0100

Hi all,

To come back to constrained device, as I already mentionned on the list within 6lowpan, we are working on a draft which documents the cost of each feature mandated by RFC4294, from an implementation perspective (target platform is 8bit microcontroller, few 10K ROM, few K RAM). I guess as soon as we have results, this might help the discussion.

To give a bit of insight on sensor industry, the market is highly fragmented in terms of technology. Most vendors have proprietary L3, sometimes proprietary L2, and there are a bunch of standards coming, like ZigBee, Z-Wave, ISA, HART...
One reason for people not to go for IPv6 is "Oh this is too big for a sensor", also because they are not always familiar with IP.

What I want to say is that this kind of question (do we mandate IPSec) is critical for a domain which promises billions of device.

Cheers,
Julien

 
Julien Abeillé
Software Engineer
Technology Center
[email-masked]
Fax:+41 21 822 1604
Cisco Systems International Sàrl
Av. des Uttins 5
1180 Rolle
Switzerland (FR)
www.cisco.com

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bound, Jim
Sent: mardi 26 février 2008 19:50
To: Basavaraj Patil; Thomas Narten; Nobuo OKABE
Cc: John Loughney; [email-masked]; Fred Baker (fred)
Subject: RE: Making IPsec *not* mandatory in Node Requirement

> Of Basavaraj Patil
> 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 
> protocol and not really helped either in adoption or implementation.
> IPsec based security is an overkill for Mobile IPv6 and illustrates 
> the point that you do not have to use it simply because it happens to 
> be an integral part of IPv6.
>
> -Basavaraj
>
>

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 13:12:57 -0600

Julien and Alain,

My high-level question to you both is, for sensors and set-top
boxes - do you feel that you do not need security for any
reason?  Is this a long-term issue or a short-term issue.

I can't really think of a reason why security would not be an
issue, but I could be wrong.

John

>Behalf Of ext Julien Abeille (jabeille)
>Sent: 26 February, 2008 11:12
>To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas 
>Narten; Nobuo OKABE
>Cc: Loughney John (Nokia-OCTO/PaloAlto); [email-masked]; Fred 
>Baker (fred)
>To come back to constrained device, as I already mentionned on 
>the list within 6lowpan, we are working on a draft which 
>documents the cost of each feature mandated by RFC4294, from 
>an implementation perspective (target platform is 8bit 
>microcontroller, few 10K ROM, few K RAM). I guess as soon as 
>we have results, this might help the discussion.
>
>To give a bit of insight on sensor industry, the market is 
>highly fragmented in terms of technology. Most vendors have 
>proprietary L3, sometimes proprietary L2, and there are a 
>bunch of standards coming, like ZigBee, Z-Wave, ISA, HART...
>One reason for people not to go for IPv6 is "Oh this is too 
>big for a sensor", also because they are not always familiar with IP.
>
>What I want to say is that this kind of question (do we 
>mandate IPSec) is critical for a domain which promises 
>billions of device.
>
>Cheers,
>Julien
>
>
> 
> 
>Julien Abeillé
>Software Engineer
>Technology Center
>[email-masked]
>Fax:+41 21 822 1604
>This e-mail may contain confidential and privileged material 
>for the sole use of the intended recipient. Any review, use, 
>distribution or disclosure by others is strictly prohibited. 
>If you are not the intended recipient (or authorized to 
>receive for the recipient), please contact the sender by reply 
>e-mail and delete all copies of this message.
> 
>
>Behalf Of Bound, Jim
>For defense in depth scenarios I disagree in the case for the 
>MN to verify with the HA. But I see your point.
>/jim
>

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 26 Feb 2008 20:28:12 +0100

Hi John,

Regarding sensors,
- some applications (e.g. sensors for process control in factories) require strong security, but dedicated security mechanism are used (in ISA standard for industrial automation as an example), the main difference with IPSec being the importance of the "lightweigt" requirement. A security mechanism and associated algorithms for such sensors might use much less processing power, memory... than standard IP mechanisms
- some applications might not require any security, e.g. a light sensor in your flat might not need it and not implement it, also due to the very low cost of the sensor.

Cheers,
John

Julien Abeillé
Software Engineer
Technology Center
[email-masked]
Fax:+41 21 822 1604

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: mardi 26 février 2008 20:13
To: Julien Abeille (jabeille); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; Fred Baker (fred)
Subject: RE: Making IPsec *not* mandatory in Node Requirement

Julien and Alain,

My high-level question to you both is, for sensors and set-top boxes - do you feel that you do not need security for any reason?  Is this a long-term issue or a short-term issue.

I can't really think of a reason why security would not be an issue, but I could be wrong.

John

>ext Julien Abeille (jabeille)
>To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas Narten; Nobuo 
>OKABE
>Cc: Loughney John (Nokia-OCTO/PaloAlto); [email-masked]; Fred Baker 
>(fred)
>To come back to constrained device, as I already mentionned on the list 
>within 6lowpan, we are working on a draft which documents the cost of 
>each feature mandated by RFC4294, from an implementation perspective 
>(target platform is 8bit microcontroller, few 10K ROM, few K RAM). I 
>guess as soon as we have results, this might help the discussion.
>
>To give a bit of insight on sensor industry, the market is highly 
>fragmented in terms of technology. Most vendors have proprietary L3, 
>sometimes proprietary L2, and there are a bunch of standards coming, 
>like ZigBee, Z-Wave, ISA, HART...
>One reason for people not to go for IPv6 is "Oh this is too big for a 
>sensor", also because they are not always familiar with IP.
>
>What I want to say is that this kind of question (do we mandate IPSec) 
>is critical for a domain which promises billions of device.
>
>Cheers,
>Julien
>
>
> 
> 
>Julien Abeillé
>Software Engineer
>Technology Center
>[email-masked]
>Fax:+41 21 822 1604
>This e-mail may contain confidential and privileged material for the 
>sole use of the intended recipient. Any review, use, distribution or 
>disclosure by others is strictly prohibited.
>If you are not the intended recipient (or authorized to receive for the 
>recipient), please contact the sender by reply e-mail and delete all 
>copies of this message.
> 
>
>Bound, Jim
>For defense in depth scenarios I disagree in the case for the MN to 
>verify with the HA. But I see your point.
>/jim
>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Feb 2008 14:59:38 -0500

> - some applications might not require any security, e.g. a light sensor =
> in your flat might not need it and not implement it, also due to the =
> very low cost of the sensor.

I agree. There is absolutely no need to prevent my neighbor (or a bad
guy outside my window) from being able to control/influence light
sensors in my house. What possible harm could they do?

Who needs security anyway!

:-)

Thomas

---

From: "Kevin Kargel" <[email-masked]>
Date: Tue, 26 Feb 2008 14:15:31 -0600

While I agree that by and large security is a good priority, there are
cases for lightweight protocols to conserve cost.  One example would be
remote reporting thermometers that I actually use on IPv4 now.  They are
non-configurable, they have no settings other than network config.  You
plug them in, give them an address, and they have a lightweight web
server and read-only snmp that will display sensor temperature when
queried.  

I like to have these sensors scatterred throughout my enterprise.  There
is nothing to hack, they posess virtually no memory, and if they get
hacked my world will not end, I will double check the temperature
manually, unpower the device, plug it back in, and it will reload from
it's read-only boot rom.  I would really prefer that these devices cost
$40 instead of $200 .  

We could put all sorts of security on these devices, making them more
expensive than they are worth, or we can plug them in, enjoy their
benefits, and accept the risk.

I have customers that run computers from live-CD's, who want the network
to perform, and are not worried about security.  They are only connected
while the user is at the keyboard, if they suspect a compromise they
reboot and are back where they started.  They like the fact that they
can have internet cheaply and easily.  These customers do not want a
secure configuration with pass phrases and keys and whatnot, they want a
four click config that gets then online.  

Whether these use cases are good or bad doesn't really matter, what
matters is that they do exist and the customer should have decision
making authority for their network.  

JMHO

Kevin

> Behalf Of Thomas Narten
> Sent: Tuesday, February 26, 2008 2:00 PM
> To: Julien Abeille (jabeille)
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> Fred Baker (fred)
> > - some applications might not require any security, e.g. a light 
> > sensor = in your flat might not need it and not implement 
> it, also due 
> > to the = very low cost of the sensor.
> 
> I agree. There is absolutely no need to prevent my neighbor 
> (or a bad guy outside my window) from being able to 
> control/influence light sensors in my house. What possible 
> harm could they do?
>

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 26 Feb 2008 21:17:50 +0100

A sensor can only sense..., you are talking about a light actuator.

Julien

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: mardi 26 février 2008 12:00
To: Julien Abeille (jabeille)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Fred Baker (fred)
Subject: Re: Making IPsec *not* mandatory in Node Requirement

> sensor = in your flat might not need it and not implement it, also due 

I agree. There is absolutely no need to prevent my neighbor (or a bad guy outside my window) from being able to control/influence light sensors in my house. What possible harm could they do?

:-)

Thomas

---

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Feb 2008 15:19:18 -0500

> reason?  Is this a long-term issue or a short-term issue.
Let me answer on everyone's behalf:

IPsec is an end-to-end security protocol.

For many environments, such as set-top boxes and the like, the box has 
its own ability
to secure itself (or make itself unusable), and the L0/L1/L2 portion of 
the network
is under the provider's physical control.

So, for a substantial portion of deployed equipment (cable/dsl boxes, 
embedded systems),
with no user-serviceable parts, *how* security is handled, is orthogonal 
to the issue
of whether it needs security.

Suggesting that in-band, network-wide, heavy-weight security (IPsec) is 
the *only*
solution to the requirement, doesn't fly.

Any of a bunch of other kinds of security can do the job, from TLS to 
SSH to use of
out-of-band channels.

And *this* is why I think that IPsec ought to be downgraded to SHOULD 
for IPv6 node
requirements.

Brian Dickson
>>> the point that you do not have to use it simply because it 
>>>       
>> happens to 
>>     
>>>> the hype about how great IPv6 is and how one will get
>>>>         
>>> better security
>>>       
>>>> with IPv6. Unfortunately, that myth has also harmed the
>>>>         
>>> overall IPv6
>>>       
>>>> deployment effort, as people look more closely and come to
>>>>         
>>> understand
>>>       
>>>> We all know the reality of security is very different and 
>>>>         
>> much more 
>>     
>>>> What applications actually make use of IPsec for security?
>>>>         
>>> A lot fewer
>>>       
>>>> looks at the applications that will be used on them, they
>>>>         
>>> do not use
>>>       
>>>> IPsec today for security. And, there are strong/compelling
>>>>         
>>> arguments
>>>       
>>>> for why IPsec is not the best security solution for many
>>>>         
>>> applications.
>>>       
>>>> To be truly useful, we (of course) need key management. If
>>>>         
>>> we want to
>>>       
>>>> mandate key management, the stakes go way up. IKEv1/v2 is
>>>>         
>>> not a small
>>>       
>>>> IKEv1 has been implemented, but due to shortcomings, IKEv2
>>>>         
>>> has already
>>>       
>>>> IMO, we should drop the MUST language surrounding IPsec.
>>>>         
>>> The technical
>>>       
>>>> justification for making it MUST are simply not compelling.
>>>>         
>>> It seems
>>>       
>>>> IPsec, where there is compelling benefit. Indeed, note 
>>>>         
>> that the USG 
>>     
>>>> has already moved away from IKEv1 and has strongly
>>>>         
>>> signalled that it
>>>       
>>>> But there is no reason why IPsec should be mandated in
>>>>         
>>> devices where
>>>       
>>>> it is clear (based on the function/purpose of the device)
>>>>         
>>> that IPsec
>>>       
>>>> As a general "node requirement", SHOULD is the right level,
>>>>         
>>> not MUST.
>>>       
>>>> Thomas
>>>>
>>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Feb 2008 09:31:09 +1300

> recommendation in this space.

Yes, it's hard to see a "MUST implement" interoperability requirement
in this space. However, there is value to a reader in listing
the IGPs that are standardised and should be considered for
implementation.
> scalable, and OSPFv3 is as good an option as any".

And this illustrates the difference in purpose between the NIST/DISA
profiles, which are operational and RFP requirements, and the IETF
profile, which is presumably aimed at a minimal implementation
rqeuirement. The IETF can (as Fred has said) profitably learn from
the NIST/DISA reasoning, but our concerns are broader.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Feb 2008 09:45:42 +1300

> reasonable timeframe, all in all it doesn't make a big difference.

I think we have a lot of experience of failure in this area in the
IETF (and OSI profiles also failed), so I predict that if we try to
reach consensus on this as a standards-track or BCP document, we will
fail again. As we often say, in the end it's the market that decides,
and each implementor chooses what to do for their particular part of
the market. I think our job is to publish clear and consistent
specifications. In the present case, they may well say things like

   If you choose to implement IPsec, here are the RFCs that
   you MUST/SHOULD/MAY implement.

   If you choose to implement an IGP, here are the RFCs
   that you MAY implement.

and so on, for things that are not part of the bare minimum.

> for our client organizations.  

Of course not. A requirement spec for an RFP is not the same thing
as a generic implementation requirement spec.

> That being said, several folks are 
> IPv6 nodes for ALL deployments. 

It may need to define a bare minimum but in addition it certainly
needs to list a whole bunch of options.

> The editors of the DoD and NIST 

As should anyone else in the RFP business.
> probably require things that a small office or home user would never need.

Exactly right, IMHO.

    Brian C

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 26 Feb 2008 12:52:31 -0800

Hi Brian,

BTNS extensions to IPsec provide out-of-band security authentication
(its not always in-band like you state). We can replicate the behavior
of TLS/ SSL using IPsec. Have a look at:

http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and-applic-06.txt

Thanks,
Vishwas

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 26 Feb 2008 22:05:41 +0100

Hi Brian,

Please see inline.

Cheers,
Julien 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: mardi 26 février 2008 12:46
To: Ed Jankiewicz
Cc: Brian Haberman; [email-masked]
Subject: Re: the role of the node "requirements" document

On 2008-02-27 05:36, Ed Jankiewicz wrote:
> 1.  Can we discuss the normative level of the revised Node 
> Requirements document?  My preference would be that it is a standards 
> track or BCP ultimately, to give firm definition of what an IPv6 node MUST do.

I think we have a lot of experience of failure in this area in the IETF (and OSI profiles also failed), so I predict that if we try to reach consensus on this as a standards-track or BCP document, we will fail again. As we often say, in the end it's the market that decides, and each implementor chooses what to do for their particular part of the market. I think our job is to publish clear and consistent specifications. In the present case, they may well say things like

[JA]I like a lot this approach. It allows more solution specific SDOs to say what they take, and fits very fine with our 6lowpan effort to identify the "bare minimum". 

> 
> 2.  I don't expect (nor believe it appropriate) that this revision 
> will satisfy all the needs of either NIST or DoD for defining "IPv6 Capable"

Of course not. A requirement spec for an RFP is not the same thing as a generic implementation requirement spec.

> already reviewing the three drafts side by side, to help ensure that 
> the Node Requirements accurately defines the requirements that apply 
> to ALL

It may need to define a bare minimum but in addition it certainly needs to list a whole bunch of options.

> about which requirements apply to ALL IPv6 nodes.  I hope this 
> revision of the Node Requirements can reiterate the commitment to 
> IPsec, but if it does not, DoD (and NIST) can certainly state stronger 
> and more specific requirements in our documents.  DoD in particular 
> answers to a higher authority on security and cryptographic 
> requirements, and will probably require things that a small office or home user would never need.

Exactly right, IMHO.

    Brian C

> 
> A prior message in this thread (from Jeremy Duncan) included pointers 
> to the NIST and DoD profiles drafts, feel free to send any 
> questions/comments to the editors off-list.  Some of the differences 
> are worth discussing on this list to see if there is consensus for 
> changes to the Node Requirements draft.  Additional work will need to 
> be done by the editors of both the DoD and NIST drafts to address the 
> specific needs of our clients that don't apply to everyone.
> 
>> Indeed, I know that RFC4294 is INFORMATIONAL. I got confused because 
>> I see the new node-req-bis draft URL snipped below to be on Standards 
>> Track.
>>
>> Sorry, if I am missing some IETF process. I was expecting the bis 
>> draft above to be INFORMATIONAL as well.
>>
>> Thanks.
>>
>> Best Regards.
>>
>> Hemant
>>
>> Of Brian Haberman
>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.
>>> tx
>>> t
>>>
>>> Cable IPv6 standards came much later. We will have to see what 
>>> common ground can be met to address Alain's concern.
>>>
>>> Hemant
>>>  
>>>> The problem is that some of those devices have really limited 
>>>> memory and they already do (too?) many things, so there is no room left...
>>> "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, 
>>> or claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 26 Feb 2008 21:06:46 +0000

Regarding sensors that needs scope there are sensor deployments being planned that will not even use TCP/IP but only layer 1 and 2 except for the gateway sensor.  So can we speak of sensors, sensor nets, sensor instrumentation that is using the TCP/IP protocol to be clear.

/jim

> From: Julien Abeille (jabeille) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2008 2:28 PM
> To: [email-masked]; Bound, Jim;
> [email-masked]; [email-masked]; [email-masked]
> - some applications (e.g. sensors for process control in
> factories) require strong security, but dedicated security
> mechanism are used (in ISA standard for industrial automation
> as an example), the main difference with IPSec being the
> importance of the "lightweigt" requirement. A security
> mechanism and associated algorithms for such sensors might
> use much less processing power, memory... than standard IP mechanisms
> - some applications might not require any security, e.g. a
> light sensor in your flat might not need it and not implement
> it, also due to the very low cost of the sensor.
>
> Cheers,
> John
>
>
>
> Julien Abeillé
> Software Engineer
> Technology Center
> [email-masked]
> Fax:+41 21 822 1604
> receive for the recipient), please contact the sender by
> reply e-mail and delete all copies of this message.
>
>
> To: Julien Abeille (jabeille); [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> My high-level question to you both is, for sensors and
> set-top boxes - do you feel that you do not need security for
> any reason?  Is this a long-term issue or a short-term issue.
>
> Narten; Nobuo
> big for a
> mandate IPSec)
> receive for the

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 26 Feb 2008 21:13:00 +0000

Example.  Bad guy psychopath (medical definition) is able to shut off ones lights or security lighting system comes outside of the through window one did not expect gets in and is 6'8" tall 260 lbs and solid muscle (no fat) and not a nice person :--).  Clearly extreme but some want security for the extreme case and do we not want to design for the extreme case too and does the extreme point to a significant or common case?  I think if we ask this question what comes back is quite useful.

/jim

> Sent: Tuesday, February 26, 2008 3:00 PM
> Cc: [email-masked]; Bound, Jim;
> [email-masked]; [email-masked]; [email-masked]; Fred
> Baker (fred)

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 26 Feb 2008 21:24:12 +0000

On the contrary some of the laser sensing capabilities now could be considered light so I guess it is what we mean by "light" technically or from a physics/scientific view I took it to be light controlled by sensors.

/jim

> Sent: Tuesday, February 26, 2008 3:18 PM
> To: Thomas Narten
> Cc: [email-masked]; [email-masked];

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 26 Feb 2008 23:20:46 +0100

Fine with this

The important point as Kevin Kargel mentions is that there ARE use cases where security is not required and/or end-to-end security is not required and/or IPSec is not required.

Julien

-----Original Message-----
From: Bound, Jim [mailto:[email-masked]] 
Sent: mardi 26 février 2008 13:24
To: Julien Abeille (jabeille); Thomas Narten
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Fred Baker (fred)
Subject: RE: Making IPsec *not* mandatory in Node Requirement

/jim

> Cc: [email-masked]; Bound, Jim; [email-masked]; 
> [email-masked]; [email-masked]; Fred Baker (fred)
> [email-masked]; [email-masked]; [email-masked]; Fred Baker 
> (fred)

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 16:35:04 -0600

Julien,

I guess the point is that some cases and deployment, secuirty is not required to be used.
However, if you are making a product and you do not include security as part of the solution,
than IPSec then you have  a problem.

John

>Fine with this
>
>The important point as Kevin Kargel mentions is that there ARE 
>use cases where security is not required and/or end-to-end 
>security is not required and/or IPSec is not required.
>
>Julien
>
>Cc: [email-masked]; [email-masked]; 
>On the contrary some of the laser sensing capabilities now 
>could be considered light so I guess it is what we mean by 
>"light" technically or from a physics/scientific view I took 
>it to be light controlled by sensors.
>
>/jim
>
>(or a bad

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 27 Feb 2008 00:05:27 +0100

Ok, I get it, but I would think this is to be left to the choice of the vendor if/how he provides security. 

I am in favor of the approach where node requirements rfc defines the bare minimum for two nodes to be able to talk to each other, then phrase the other sections like setion 6.1, 6.2, i.e. if a node wants to implement security at IP layer, it must use RFCxyz...
This might be my 6lowpan view however.

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: mardi 26 février 2008 14:35
To: Julien Abeille (jabeille)
Cc: [email-masked]
Subject: RE: Making IPsec *not* mandatory in Node Requirement

Julien,

I guess the point is that some cases and deployment, secuirty is not required to be used.
However, if you are making a product and you do not include security as part of the solution, than IPSec then you have  a problem.

John

>Fine with this
>
>The important point as Kevin Kargel mentions is that there ARE use 
>cases where security is not required and/or end-to-end security is not 
>required and/or IPSec is not required.
>
>Julien
>
>On the contrary some of the laser sensing capabilities now could be 
>considered light so I guess it is what we mean by "light" technically 
>or from a physics/scientific view I took it to be light controlled by 
>sensors.
>
>/jim
>

---

From: Ed Jankiewicz <[email-masked]>
Date: Tue, 26 Feb 2008 18:07:41 -0500

That is a good point, does IPsec depend on unanimous support?  We 
struggled with this in the DoD Profiles.  Our rationale for making IPsec 
mandatory (except at the moment for some simple appliances) was that for 
IPsec to be a feasible solution it needs to be available throughout the 
network.  We want it to be universally available so that it CAN be used 
when required.  With end-to-end, any two hosts could use IPsec as a 
solution even if no one else supported it, assuming that nothing in the 
network blocks its use.  However, given recent news items about ISPs and 
governments wanting to block or throttle certain content, it seems they 
might also want to block something that could hide that content from 
their prying eyes. 

Even if the revision were to relax the requirement for IPsec (and I 
don't suggest it should) I believe there should be a strong statement 
about non-interference in the Node Requirements so that consenting hosts 
can count on the delivery of packets with IPsec options.

As Thomas said a while back, de-mandating IPsec would not make it go 
away, nor would it remove market incentive for vendors to implement it, 
so existing and new implementations would still be available.  DoD would 
likely still require it in products, so if a vendor wanted to sell to 
DoD it would be in their interest to include IPsec.  As always, just my 
personal opinion, not to be construed as policy...

Ed J.

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 17:07:27 -0600

Julien,

>Ok, I get it, but I would think this is to be left to the 
>choice of the vendor if/how he provides security. 
>
>I am in favor of the approach where node requirements rfc 
>defines the bare minimum for two nodes to be able to talk to 
>each other, then phrase the other sections like setion 6.1, 
>6.2, i.e. if a node wants to implement security at IP layer, 
>it must use RFCxyz...

I think that it is always good to have some common mechanism, if
we are talking about interoperability. If you are making a 
sensor that implements one kind of security, while I make a server
that implements another kind of security, the end result is that
our two implementations cannot talk to each other securely, even
though we are both 'complient' to the Node Req. RFC.  

John

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 26 Feb 2008 18:32:21 -0500

> From: Ed Jankiewicz [mailto:[email-masked]] 

> when required.

Take the case of network routers in non-secure spaces. This should be a
VERY common situation.

Let's assume that I use some form of hardware encryption for everything
traveling between routers, mainly to protect the routing protocol, but
also apply this encryption to any traffic. This could be more than
adequate for such a network, and it avoids the need for IKEv2 in the
routers.

Or forget hardware encryption. I can also use means other than IKEv2 to
identify the crypto algorithm used between my routers, if I have control
of router configuration but these routers may be in non-secure spaces.
Even manual configuration, if the network is not huge. Or SNMP.

> With end-to-end, any two hosts could use IPsec as a 
> network blocks its use.

And this solution doesn't prevent end-to-end IPsec in any way. And yet,
the NIST Profile does not allow the above possibilities.

My fundamental position is that for real, meaningful security, you
either need IPsec between hosts, or at very least you need IPsec between
"security gateways" that are themselves located in secure spaces, *along
with* the hosts. In short, when routers are in non-secure speaces,
there's no way you'll get "security" if you allow only plaintext to
these routers. The onus of IP security goes mostly to hosts or the
security gateways.

Bert

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 26 Feb 2008 15:57:02 -0800

I won't argue against the fact that security is an important part of a 
complete solution. The question for me is whether IPsec is the most 
appropriate solution for highly constrained embedded devices 
(constrained in energy, memory, compute, and link capabilities). From 
the few implementation numbers thrown around this thread, it sounds like 
IPsec is not an option for low-power wireless nodes with 8K RAM, 48K 
ROM, 128B link MTU, and not to mention that any implementation should 
leave enough space for an interesting application and should operate for 
multiple years on modest batteries.

One nice thing is that, given some application scenarios, there are 
other ways to incorporate sufficient security without the need for 
IPsec. For example, link-layer security may be sufficient for private 
networks. Link-layer security may also be sufficient if border 
routers/gateways attach to other traditional IP networks via encrypted 
tunnels.

I'm not a security expert, nor do I know the complete workings of IPsec. 
But I'd be curious if people strongly believe or have ideas on ways to 
squeeze IPsec into devices that I'm interested in. If not, is it at all 
possible to consider developing an alternative end-to-end security 
mechanism that is lightweight. I'm not arguing that this should be used 
between two traditional IP hosts, but that it can be used between a 
traditional IP host communicating with a low-power, wireless device or 
two low-power wireless devices communicating directly.

Gordon Bell observed that we've seen a new class of computing form about 
every decade. IP has so far been able to follow these trends, including 
hand held devices. Now we are at the beginning of yet another class with 
low-power wireless devices based on IEEE 802.15.4, and the 6lowpan 
effort within the IETF has set out to bring IPv6 to this new class. I'd 
be disappointed if we couldn't come to an agreement on how we can 
appropriately bring this new class into the IP framework.

--
Jonathan Hui

---

From: Alain Durand <[email-masked]>
Date: Wed, 27 Feb 2008 10:01:00 +0800

John,

Clarification: I am not talking about set top box, but cable modems. Very
different beast.

  - Alain.

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 27 Feb 2008 04:21:08 +0000

Agreed.
/jim

> Sent: Tuesday, February 26, 2008 5:21 PM
> To: Bound, Jim; Thomas Narten
> The important point as Kevin Kargel mentions is that there
> ARE use cases where security is not required and/or
> end-to-end security is not required and/or IPSec is not required.
>
> Julien
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 27 Feb 2008 04:25:26 +0000

This is clearly the path of least resistance to achieve consensus too and ecumenical in this community to achieve a common agreement.  In this case less could be better (Mark Twain shorter please) but we need to be sure we do not have bugs and have to rev biz updates every 6 months if we are to ever get to a completed work.  Or maybe a completed work is not the objective but a living document?  I don't think our technical job will be that hard if we agree on scope and approach with the talent/knowledge on this list.

/jim

> Behalf Of Julien Abeille (jabeille)
> Sent: Tuesday, February 26, 2008 6:05 PM
> To: [email-masked]
> Cc: [email-masked]
> However, if you are making a product and you do not include
> security as part of the solution, than IPSec then you have  a problem.
>
> John
>
> >Fine with this
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 27 Feb 2008 04:35:47 +0000

I don't think unanimous support is needed just the support within the domain of use and that could be a private or public network with collaboration with the firewall rules at the edge or the node directly in the case of p2p.  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. But do we take social and law enforcement issues into consideration as IETF individuals? We had this debate some time ago and I believe the answer with consensus today might be different. Once while presenting at some form of NGN conference in London on e2e a person who identified them as Law Enforcement asked me if this e2e security existed would that permit bad persons to also be able to do this too (this was after 911) and had to say yes with the caveat I am identifying the technology capability not the social consequences, which is a discussion typically left to the market and those who enforce laws.  But yes the same technology we define for good reasons always can be used for bad reasons.  But I don't think not doing e2e is going to stop bad intentioned criminals.

/jim

> Behalf Of Ed Jankiewicz
> Sent: Tuesday, February 26, 2008 6:08 PM
> To: [email-masked]
> Cc: [email-masked]
> That is a good point, does IPsec depend on unanimous support?
>  We struggled with this in the DoD Profiles.  Our rationale
> for making IPsec mandatory (except at the moment for some
> simple appliances) was that for IPsec to be a feasible
> solution it needs to be available throughout the network.  We
> want it to be universally available so that it CAN be used
> when required.  With end-to-end, any two hosts could use
> IPsec as a solution even if no one else supported it,
> assuming that nothing in the network blocks its use.
> However, given recent news items about ISPs and governments
> wanting to block or throttle certain content, it seems they
> might also want to block something that could hide that
> content from their prying eyes.
>
> Even if the revision were to relax the requirement for IPsec
> (and I don't suggest it should) I believe there should be a
> strong statement about non-interference in the Node
> Requirements so that consenting hosts can count on the
> delivery of packets with IPsec options.
>
> As Thomas said a while back, de-mandating IPsec would not
> make it go away, nor would it remove market incentive for
> vendors to implement it, so existing and new implementations
> would still be available.  DoD would likely still require it
> in products, so if a vendor wanted to sell to DoD it would be
> in their interest to include IPsec.  As always, just my
> security
> > as part of the solution, than IPSec then you have  a problem.
> >
> > John
> >
> >
> >> Fine with this
> >>
> >> cases where security is not required and/or end-to-end security is
> >> not required and/or IPSec is not required.
> >>
> >> Julien
> >>
> could be

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 27 Feb 2008 04:45:45 +0000

Good point and Gordon Bell has almost always been right for me so I know I listen to him.  The key is do these low power and restricted sensor components require security at the IP layer?  If IEEE xxx is secure can we conclude the IP layer is not relevant for sensors, but I would suggest they are for any sensor gateway nodes.  Or can we develop in industry a micro-kernel IPsec implementation in hardware that can be cost effectively added to a sensor or set of sensor unions for a network?  Clearly we are seeing this type of hardware development on microprocessors with the exponential appearance of deep packet inspection providers into the market that are not router/switch vendors.  But is IPsec the right answer is the right question for lowpan for engineering cost reasons as opposed to is it possible?

/jim

> Behalf Of Jonathan Hui
> Sent: Tuesday, February 26, 2008 6:57 PM
> To: [email-masked]
> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not*
> mandatory in Node Requirement)
>
>
> I won't argue against the fact that security is an important
> part of a complete solution. The question for me is whether
> IPsec is the most appropriate solution for highly constrained
> embedded devices (constrained in energy, memory, compute, and
> link capabilities). From the few implementation numbers
> thrown around this thread, it sounds like IPsec is not an
> option for low-power wireless nodes with 8K RAM, 48K ROM,
> 128B link MTU, and not to mention that any implementation
> should leave enough space for an interesting application and
> should operate for multiple years on modest batteries.
>
> One nice thing is that, given some application scenarios,
> there are other ways to incorporate sufficient security
> without the need for IPsec. For example, link-layer security
> may be sufficient for private networks. Link-layer security
> may also be sufficient if border routers/gateways attach to
> other traditional IP networks via encrypted tunnels.
>
> But I'd be curious if people strongly believe or have ideas
> on ways to squeeze IPsec into devices that I'm interested in.
> If not, is it at all possible to consider developing an
> alternative end-to-end security mechanism that is
> lightweight. I'm not arguing that this should be used between
> two traditional IP hosts, but that it can be used between a
> traditional IP host communicating with a low-power, wireless
> device or two low-power wireless devices communicating directly.
>
> Gordon Bell observed that we've seen a new class of computing
> form about every decade. IP has so far been able to follow
> these trends, including hand held devices. Now we are at the
> beginning of yet another class with low-power wireless
> devices based on IEEE 802.15.4, and the 6lowpan effort within
> the IETF has set out to bring IPv6 to this new class. I'd be
> disappointed if we couldn't come to an agreement on how we
> can appropriately bring this new class into the IP framework.
>
> --
> Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 27 Feb 2008 08:13:53 +0100

Hi Jim:

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=1134&CommitteeID=6891) has decided to endorse - and extend when necessary - the work done at 802.15.4 and 6LoWPAN, which means that we will have IPv6-based sensors in the industrial WSN space. I say it's great news and we-IETF should continue in our effort to support the ISA there.

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 RFC 3610, that's a quote for the purists). 

The ISA100.11a Transport level security replicates end to end what is done at the Data Link Layer in order to benefit from the chipset built-in features. No IKE, No IPSec at least for the current spec. A side effect of that design is that we'll be able to elide the UDP checksum in the 6LoWPAN compression by including the IPv6 pseudo header and the UDP ports in the Message Integrity Check computation, pushing the whole computation up a sublayer.

I've come to expect that the encryption will be done end to end at the transport level whereas the integrity and authentication will be played hop by hop over the DLL mesh, but that's a deployment decision.

Pascal

>Sent: mercredi 27 février 2008 05:46
>To: Jonathan Hui; [email-masked]
>Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* 
>mandatory inNode Requirement)
>
>Good point and Gordon Bell has almost always been right for me 
>so I know I listen to him.  The key is do these low power and 
>restricted sensor components require security at the IP layer? 
> If IEEE xxx is secure can we conclude the IP layer is not 
>relevant for sensors, but I would suggest they are for any 
>sensor gateway nodes.  Or can we develop in industry a 
>micro-kernel IPsec implementation in hardware that can be cost 
>effectively added to a sensor or set of sensor unions for a 
>network?  Clearly we are seeing this type of hardware 
>development on microprocessors with the exponential appearance 
>of deep packet inspection providers into the market that are 
>not router/switch vendors.  But is IPsec the right answer is 
>the right question for lowpan for engineering cost reasons as 
>opposed to is it possible?
>
>/jim
>
>> Of Jonathan Hui
>> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory in 
>> Node Requirement)
>>
>>
>part of a 
>> the few implementation numbers thrown around this thread, it sounds 
>> like IPsec is not an option for low-power wireless nodes 
>with 8K RAM, 
>> 48K ROM, 128B link MTU, and not to mention that any implementation 
>> should leave enough space for an interesting application and should 
>> operate for multiple years on modest batteries.
>>
>on ways to 
>> squeeze IPsec into devices that I'm interested in.
>> If not, is it at all possible to consider developing an alternative 
>> end-to-end security mechanism that is lightweight. I'm not arguing 
>> that this should be used between two traditional IP hosts, 
>but that it 
>> can be used between a traditional IP host communicating with a 
>> low-power, wireless device or two low-power wireless devices 
>> communicating directly.
>>
>> Gordon Bell observed that we've seen a new class of computing form 
>> about every decade. IP has so far been able to follow these trends, 
>> including hand held devices. Now we are at the beginning of yet 
>> another class with low-power wireless devices based on IEEE 
>802.15.4, 
>> and the 6lowpan effort within the IETF has set out to bring IPv6 to 
>> this new class. I'd be disappointed if we couldn't come to an 
>> agreement on how we can appropriately bring this new class 
>into the IP 
>> framework.
>>
>> --
>> Jonathan Hui
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Nobuo OKABE <[email-masked]>
Date: Wed, 27 Feb 2008 16:26:26 +0900 (JST)

Hi all,

# I'm surprised that opinion in the ML has changed from 2002.

I agree that IPsec is not a universal security tool
as many people had pointed out.

I also would like to say that IPsec is still one of the useful tools.

So, SHOULD　seems good to me.

Thanks,

From: Thomas Narten <[email-masked]>
Subject: Re: Making IPsec *not* mandatory in Node Requirement
Date: Tue, 26 Feb 2008 11:18:33 -0500

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 27 Feb 2008 00:04:17 -0800

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 approach which sits above UDP or a lightweight version of 
IPsec which sits a bit lower in the layering are both much more 
attractive approaches to me than requiring IPsec, as we know it today, 
on sensor nodes. Of course, we won't get all of the features of a 
full-blown IPsec implementation, but we've got to trade something to 
live in this constrained world. I'm willing to live with that and I'm 
wondering what others on this list think about that. Specifically, is 
there a place for the IETF to specify a lightweight end-to-end security 
scheme in place of IPsec?

The question of IPsec vs. engineering cost is in some sense true, but it 
doesn't capture the entire story. IPsec has significant header 
requirements, compared to the link MTU of IEEE 802.15.4. This translates 
directly to extra buffering requirements, channel utilization, and 
energy cost. You could argue to use bigger batteries, but some 
environments with physical and environmental constraints can't afford to 
do so.

--
Jonathan Hui

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 27 Feb 2008 10:36:19 +0100

Hi,

>  Mobile IPv6 signaling can be secured via simpler mechanisms.

More you have different mechanisms to secure service, more you will
have complexity and more you will have a security hole somewhere ...

> But because of

Sorry, but who are "we"?

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 27 Feb 2008 11:16:31 +0100

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 anymore put my
legs on the dashboard when I am passenger because I am afraid to
active them (i.e. complexity) and I will, maybe (I hope :)), never use
them (i.e. useless). So, why, today, all the cars have such airbags
(BTW, which are standardized I assume)?

More seriously, I was not involved in the IETF when it was decided
that IPsec would be mandatory in IPv6 but IHMO:
- it is always good to have a common security protocol at the IP layer
(i.e. interoperability) that can be used easily when you will need it.
- many protocols have been specified and secured based on the
assumption that IPsec was mandatory
- if today some technologies cannot support IPsec, the next generation
of the same technologies should support them

Now I agree that there is a cost and too much security kills the
security. But do you prefer to pay a "small" cost and have a "spare
wheel" or to pay a "large" later cost because you will have security
issues (and so you will have to stop services until to secure them
correctly)?

Best regards.

JMC.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Feb 2008 18:20:25 +0800

Brian Dickson wrote:
> ...

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 changes the
optimization no longer applies, and may expose unexpected holes. This was in
fact happening at the time the mandate was put in.

> And *this* is why I think that IPsec ought to be downgraded to SHOULD

As I recall we had a lengthy argument about this, and really don't need to
reopen it now. If there is not a single mandatory-to-implement protocol,
there is no way to assure that two random products will have a common means
of secure communication. Again, for a specific deployment or application,
they can do whatever they want, but that does not remove the need for a
common security protocol when it is not known which other device might need
to talk to it 6 months down the road.

Alain's original post is completely bogus. If his devices don't need IPsec,
he is free to tell his vendors not to load it in the image. That is not a
reason to change node-requirements. He is in a closed environment and knows
that a random device will not appear that doesn't speak the security
protocol for that closed environment. The IETF is defining requirements for
IPv6 nodes that will appear in arbitrary environments, where there is no
means to know the availability of a common security protocol, unless it was
specified up front. Making it a SHOULD only ensures that vendors will never
implement it, and force the 47 flavors of not-quite-security.

Tony

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 27 Feb 2008 22:45:16 +1000

> 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 mandating IKEv1/IKEv2 is not so dependent, IMHO, on their
availability; it rather depends on the availability of widley used
credentials that would make us think mandating IKEvx will actually result in
it being used :) 

Hesham

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 27 Feb 2008 13:17:44 +0000

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=1134&CommitteeI
> D=6891) has decided to endorse - and extend when necessary -
> the work done at 802.15.4 and 6LoWPAN, which means that we
> will have IPv6-based sensors in the industrial WSN space. I
> say it's great news and we-IETF should continue in our effort
> to support the ISA there.

Agree this is a very good endorsement from ISA.

>
> 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 RFC 3610, that's a quote for the purists).

Uggh.  As purist I do not trust UDP in the first place :--).  If one can build a stack supporting UPD and all that is required for AES then hearing that IPsec is to heavy for a sensor makes zero sense to me.

>
> The ISA100.11a Transport level security replicates end to end
> what is done at the Data Link Layer in order to benefit from
> the chipset built-in features.

Can you say more because moving link layer control up to a transport in my view not only breaks the Internet Protocol Reference Model but the IEEE layer 1 and 2 models?  Also IEEE does a fairly good job for most media to secure the link at that end?

> No IKE, No IPSec at least for
> the current spec. A side effect of that design is that we'll
> be able to elide the UDP checksum in the 6LoWPAN compression
> by including the IPv6 pseudo header and the UDP ports in the
> Message Integrity Check computation, pushing the whole
> computation up a sublayer.

Ouch I don't even believe you should see any ports until after a decrypt from my security purist view.

>
> I've come to expect that the encryption will be done end to
> end at the transport level whereas the integrity and
> authentication will be played hop by hop over the DLL mesh,
> but that's a deployment decision.

Well for mission critical nets this is clearly not supportive of defense in depth at all.  But I can see it as we are talking for some deployments that do not need defense in depth.

Thanks
/jim

> >Good point and Gordon Bell has almost always been right for me so I
> >know I listen to him.  The key is do these low power and restricted
> >sensor components require security at the IP layer?
> relevant for
> >sensors, but I would suggest they are for any sensor gateway
> nodes.  Or
> >can we develop in industry a micro-kernel IPsec implementation in
> >hardware that can be cost effectively added to a sensor or set of
> >sensor unions for a network?  Clearly we are seeing this type of
> >hardware development on microprocessors with the exponential
> appearance
> >of deep packet inspection providers into the market that are not
> >router/switch vendors.  But is IPsec the right answer is the right
> >question for lowpan for engineering cost reasons as opposed to is it
> >possible?
> >
> >/jim
> >
> there are
> alternative

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 27 Feb 2008 13:20:17 +0000

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 be aware of for sure.

thanks
/jim

> From: Jonathan Hui [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2008 3:04 AM
> To: Pascal Thubert (pthubert)
> Cc: Bound, Jim; [email-masked]
> Subject: Re: IPsec and 6LoWPAN (was: Re: Making IPsec *not*
> 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 approach which sits above UDP or a lightweight
> version of IPsec which sits a bit lower in the layering are
> both much more attractive approaches to me than requiring
> IPsec, as we know it today, on sensor nodes. Of course, we
> won't get all of the features of a full-blown IPsec
> implementation, but we've got to trade something to live in
> this constrained world. I'm willing to live with that and I'm
> wondering what others on this list think about that.
> Specifically, is there a place for the IETF to specify a
> lightweight end-to-end security scheme in place of IPsec?
>
> The question of IPsec vs. engineering cost is in some sense
> true, but it doesn't capture the entire story. IPsec has
> significant header requirements, compared to the link MTU of
> IEEE 802.15.4. This translates directly to extra buffering
> requirements, channel utilization, and energy cost. You could
> argue to use bigger batteries, but some environments with
> physical and environmental constraints can't afford to do so.
>
> --
> Jonathan Hui
>
>
> > The ISA100.11a Transport level security replicates end to
> end what is done at the Data Link Layer in order to benefit
> from the chipset built-in features. No IKE, No IPSec at least
> for the current spec. A side effect of that design is that
> we'll be able to elide the UDP checksum in the 6LoWPAN
> compression by including the IPv6 pseudo header and the UDP
> ports in the Message Integrity Check computation, pushing the
> whole computation up a sublayer.
> >
> >> Of Bound, Jim
> >> Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec
> *not* mandatory
> >> inNode Requirement)
> >>
> >> If IEEE xxx is secure can we conclude the IP layer is not relevant
> >> for sensors, but I would suggest they are for any sensor gateway
> >> nodes.  Or can we develop in industry a micro-kernel IPsec
> >> implementation in hardware that can be cost effectively added to a
> >> sensor or set of sensor unions for a network?  Clearly we
> are seeing
> >> this type of hardware development on microprocessors with the
> >> exponential appearance of deep packet inspection providers
> into the
> >> market that are not router/switch vendors.  But is IPsec the right
> >> answer is the right question for lowpan for engineering
> cost reasons
> >> as opposed to is it possible?
> >>
> >> /jim
> >>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 27 Feb 2008 13:21:16 +0000

Good recap on why Tony it is very important for us to hear this input and quite valid.
thanks
/jim

> Behalf Of Tony Hain
> Sent: Wednesday, February 27, 2008 5:20 AM
> To: [email-masked]
> > 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
> completely understood. Yes for any given situation someone
> can design an optimized protocol, but as soon as the
> situation changes the optimization no longer applies, and may
> expose unexpected holes. This was in fact happening at the
> time the mandate was put in.
>
> >
> > for IPv6 node requirements.
>
> As I recall we had a lengthy argument about this, and really
> don't need to reopen it now. If there is not a single
> mandatory-to-implement protocol, there is no way to assure
> that two random products will have a common means of secure
> communication. Again, for a specific deployment or
> application, they can do whatever they want, but that does
> not remove the need for a common security protocol when it is
> not known which other device might need to talk to it 6
> months down the road.
>
>
> Alain's original post is completely bogus. If his devices
> don't need IPsec, he is free to tell his vendors not to load
> it in the image. That is not a reason to change
> node-requirements. He is in a closed environment and knows
> that a random device will not appear that doesn't speak the
> security protocol for that closed environment. The IETF is
> defining requirements for
> IPv6 nodes that will appear in arbitrary environments, where
> there is no means to know the availability of a common
> security protocol, unless it was specified up front. Making
> it a SHOULD only ensures that vendors will never implement
> it, and force the 47 flavors of not-quite-security.
>
>
> Tony
>
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 27 Feb 2008 13:29:41 +0000

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 the next right thing in the IETF.  IKEv2 is clearly better.  Regarding management of PKI etc that is a red herring argument orthogonal to the technical work on a function in the IETF like IKEv2.  The market will sort out that deployment automatiion issue we need to spec out and define technical criteria for a specification.  Adding foot note that without PKI etc. this will not work well is fine.  Thus if apples-x grown in region-x cause ones legs to cramp but apples-y grown in region-y do not the social agency reporting on such things has the responsibility to say apples-y do less harm to you than apples-x.  In this specific case as a protocol the IETF is the social agency above.  But 
 the market is requiring IKEv2 now and most vendors have figured out it is a done deal if they want to maintain competitive parity in the market.

/jim

> Behalf Of Hesham Soliman
> Sent: Wednesday, February 27, 2008 7:45 AM
> To: 'Thomas Narten'; 'Nobuo OKABE'
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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 mandating IKEv1/IKEv2 is not so dependent,
> IMHO, on their availability; it rather depends on the
> availability of widley used credentials that would make us
> think mandating IKEvx will actually result in it being used :)
>
> Hesham
>
>  >
>  > Thomas
>  >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 27 Feb 2008 15:38:18 +0100

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 RFC 3610, 
>that's a 
>> quote for the purists).
>
>Uggh.  As purist I do not trust UDP in the first place :--).  
>If one can build a stack supporting UPD and all that is 
>required for AES then hearing that IPsec is to heavy for a 
>sensor makes zero sense to me.

I was not there when that decision was made and I do not know all the details. Seems to me that we get a result that is close to D-TLS with a security sublayer sitting above UDP as opposed to a sitting at the bottom of the app layer. That much does not bother me too much because it is an end point thing above standard UDP and the end-to-end principle is respected.

I need to dig but my current understanding is that the ISA approach saves bytes in the packet, which is *critical* in the sensor space; part of that saving comes from using time in the nonce but not passing (all of) it over the air because devices are somewhat synchronized. Anyway, once you have a D-TLS prime and a good L2 security, it's hard to justify you need IPSec as well. I figure that ISA100.11a falls into Tony's "specific deployment or application," because ISA defines both ends of a communication, so this does not bother me too much either. 

What I've been trying to do is make sure that the packets across the backbone (that interconnects LoWPANs) are standard IPv6 packets and that basic rules such as RFC 3448 are taken into consideration in the end points. None of this was a given to start with :) 

>end what is 
>> done at the Data Link Layer in order to benefit from the chipset 
>> built-in features.
>
>Can you say more because moving link layer control up to a 
>transport in my view not only breaks the Internet Protocol 
>Reference Model but the IEEE layer 1 and 2 models?  Also IEEE 
>does a fairly good job for most media to secure the link at that end?

ISA has cleanly defined layers which pretty much echo the TCP/IP model, and has both L2 and upper L4 security, but no L3 security. 

What I've been trying to say here is that the crypto operation is the same at both layers so the crypto engine available for L2 in the chipsets can be reused by the transport security; thus the use of standard AES with CCM* mode. Each layer secures its own data per its own policy; for instance upper L4 will encrypt the payload and L2 will only authenticate the frame. As a result, the crypto engine present in the chipset will run twice. Once and L2 and once at L4 if you're terminating the connection; once to check and once to sign if you're only forwarding over the L2 mesh.

>> the current spec. A side effect of that design is that we'll be able 
>> to elide the UDP checksum in the 6LoWPAN compression by 
>including the 
>> IPv6 pseudo header and the UDP ports in the Message Integrity Check 
>> computation, pushing the whole computation up a sublayer.
>

What we do is a DTLS prime, not an IPSec Prime. So the UDP ports are visible but still we want to prevent tempering with them.

In particular for the UDP checksum, what I'm trying to do is get an IP+UDP pseudo-header included in the MIC computation but not encrypted, to emulate the UDP checksum so that the UDP checksum can be elided. With CCM, it is possible to encrypt only a part of the message, leaving - typically a header - in the clear. Obviously, we elide the pseudo-header as well for transmission. With the checksum trick, UDP is in the clear but still protected against corruption along the path. As a result, the UDP header can be compressed down to 1 byte as opposed to 3 bytes with RFC 4944. 

I'm planning to document that process to 6LoWPAN see if we can get a consensus betweem the 2 organizations that the whole thing is workable.

I hope it is clearer now :)

Pascal

>end at the 
>> transport level whereas the integrity and authentication will be 
>> played hop by hop over the DLL mesh, but that's a deployment 
>decision.
>
>Well for mission critical nets this is clearly not supportive 
>of defense in depth at all.  But I can see it as we are 
>talking for some deployments that do not need defense in depth.
>
>Thanks
>/jim
>
>>
>> Pascal
>>
>>

---

From: <[email-masked]>
Date: Wed, 27 Feb 2008 14:55:14 -0000

--Michael Dillon

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 27 Feb 2008 10:14:12 -0500

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 section 10 mandating IPSec as a MUST for IPv6. 

Someone else also suggested that maybe we can sub categorize the IPSec
requirement based on different devices like big honking router vs. a
small consumer device etc. I don't think that is wise because one has no
clue what devices will come into being in future where devices support
IPv6. 

Also read Tony Hain's email that discusses cable. This mailer has enough
cable experienced folks to give their input.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, February 27, 2008 9:55 AM
To: [email-masked]
Subject: RE: the role of the node "requirements" document

Cable boxes are not much different from general purpose computers
running Linux. In fact, they may use Linux for all I know. In any case,
they are complex devices and if you looked at an architecture diagram
for them they would like rather like a network in a box with many
functions on separate chips (or areas of an FPGA) all communicating with
various internal protocols and busses.

But IPv6 is not just for devices like that. It was also intended to be
something that could be implemented on embedded devices that often use
8-bit CPUs with the IP stack written in carefully handcoded assembly
language. TINI is an example of such a device but there are hundreds of
them out there and manufacturers continue to introduce new 8-bit
microcontrollers all the time.

If you have any contacts with Yokogawa in Japan, they have a lot of
experience in this area and will be able to give a better idea of how
common it is to implement IPv6 without IPsec. WIDE people may also know
more about this.

--Michael Dillon

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 27 Feb 2008 10:26:35 -0500

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 not IPSec, but the security is fairly similar. Public keys are
negotiated between modem and CMTS and data traffic is encrypted between
modem and the CMTS once keys are negotiated. When modem traffic reaches
the CMTS, if the traffic has to be forwarded out from CMTS the packet is
decrypted and sent in the clear. It's a CMTS configuration that mandates
if the traffic from CMTS to the Internet core gets further encrypted if
any IPSec is used between CMTS and the WAN/core router.

Hemant

-----Original Message-----
Tony Hain

> 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 completely understood. Yes for any given
situation someone can design an optimized protocol, but as soon as the
situation changes the optimization no longer applies, and may expose
unexpected holes. This was in fact happening at the time the mandate was
put in.

> for IPv6 node requirements.

As I recall we had a lengthy argument about this, and really don't need
to reopen it now. If there is not a single mandatory-to-implement
protocol, there is no way to assure that two random products will have a
common means of secure communication. Again, for a specific deployment
or application, they can do whatever they want, but that does not remove
the need for a common security protocol when it is not known which other
device might need to talk to it 6 months down the road.

Alain's original post is completely bogus. If his devices don't need
IPsec, he is free to tell his vendors not to load it in the image. That
is not a reason to change node-requirements. He is in a closed
environment and knows that a random device will not appear that doesn't
speak the security protocol for that closed environment. The IETF is
defining requirements for
IPv6 nodes that will appear in arbitrary environments, where there is no
means to know the availability of a common security protocol, unless it
was specified up front. Making it a SHOULD only ensures that vendors
will never implement it, and force the 47 flavors of not-quite-security.

Tony

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 27 Feb 2008 11:18:25 -0500

> 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 conclude is that
security is a non-starter. How can a system be considered secure if the
data is not encrypted when it travels across non-trusted networks?

And, who would consider his comm links secure if he has to trust the
ISP?

The NIST Profile makes this same point about plaintext through routers,
and I concluded the same thing there. Sounds like a non-sequitur.

In principle, authentication, in the non-trusted part of the network, is
all that should be required. If security experts determined that AH is
not so good, then maybe ESP within ISP nets is okay. But this does not
remove the need for e2e encryption, IMO.

> But do we take social and 
> law enforcement issues into consideration as IETF 
> individuals?

The only logical answer is that whatever node inspects the packets has
to be capable of decrypting them. Which means, it must become a trusted
node.

> But I don't think not doing e2e is 
> going to stop bad intentioned criminals.

I'd put it more strongly. Not doing e2e IPsec invalidates the whole
security model. It then becomes just something to show on a viewgraph,
to try to confuse the innocent into believing that the system is secure.

Bert

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 27 Feb 2008 08:37:37 -0800

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 802.15.4 is 
really the header overhead.  For this reason, the security protocol for 
IEEE 802.15.4 allows for variable size IV and ICV, giving the ability to 
make the tradeoffs we need. The basic functions of RFC4309 seem 
particularly applicable for IPsec over 802.15.4 links, but the header 
size is of concern. The IV carried in each packet is required to be 8 
bytes and the ICV is required to be between 8 and 16 bytes. 802.15.4, on 
the other hand, allows smaller fields for both the IV and ICV and gives 
the flexibility to make tradeoffs. When you're working with nodes that 
send very small messages and maximum frame sizes of 128 bytes (including 
link headers), every byte counts.

I'm also concerned on the requirement for automated key distribution. Is 
it possible to claim that you support IPsec without supporting automated 
key management like IKEv2 or something similar?

I'm interested in working through this more in detail to do the study of 
whether IPsec is a viable option and would like to solicit help from 
those that have more expertise in this space. If anyone is interested, 
let me know.

--
Jonathan Hui

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 27 Feb 2008 11:54:42 -0500

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.)

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 deployment 
issues - and in fact we do draw distinctions between Big Honking devices 
and smaller devices to "escape" some requirements where they will not be 
needed.  Our deployment plans do not impose anything on the general 
community.  Similarly, application specifics (for low power sensors, 
mobility, CPE etc.) can be separately documented, and in keeping with 
the "first do no harm" principle, as long as they don't interfere with 
anyone else's use of IPsec, it is reasonable for them to make their own 
exceptions.  Let the buyer beware.  As far as I know, DoD will probably 
only buy stuff with IPsec, but if an ISP doesn't think they need it in 
their CPE, they should be free to save the development cost and memory 
space.

I agree with Hemant (and others' sentiments on this thread) that the 
Node Requirements doc should summarize the requirements for IPv6 nodes, 
and leave the exceptions, extensions and caveats to deployment documents 
like the NIST and DoD profiles and application documents.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Feb 2008 11:58:42 -0500

Basavaraj Patil <[email-masked]> writes:

> 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 not

To be clear, this is a simplistic explanation. Had IPsec (and IKE) not
been used for MIPv6, they would have had to invent a whole new
security protocol for securing things. As we know, coming up with yet
another security mechanism is hugely problematic for the IETF. It is
far from clear that the MIPv6 WG had the necessary competence to do
this, and it is far from clear that the security community would have
found the problem space interesting enough to help the WG get it
right.

> the point that you do not have to use it simply because it happens

THe reason for choosing IPsec was not just because it was "part of
IPv6". It was also chosen because there wasn't really another obvious
alternative to use. And inventing a new one would have been
duanting. (And please don't point to RFC 4285 as the solution. The
IESG note that goes with that document is not to be dismissed
lightly.)

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Feb 2008 12:14:13 -0500

Tony,

> fact happening at the time the mandate was put in.

Right.  Having one way to do things is far better than having 47.

But if we look at the reality of things, IPsec (and we have to include
IKE in evaluating this), IPsec just isn't the ideal one-size-fits-all
technology we'd like it to be.

For example, one big problem is the lack of a proper API for
applications to communicate with IPsec to select services and verify
that a certain level of security is present. Second, good security
says "don't trust anyone but yourself". So, do you trust the OS you
are running on? Do you trust the IPsec embedded in the system that was
implemented by a third party? Smart applications implement their own
security (e.g., TLS) to ease deployment. We'll never get them to rely
on IPsec, at least not until its much more widely available/useable.

There are other examples.

To channel Randy Bush:

>   o the net should have mandatory crypto period
> 
>   o ipsec sucks

This is the dilemma we are in. Personally, I think we are exhibiting a
bit of head-in-the-sand mentality to continue saying IPsec is a MUST,
when we don't even bother include IKE! IPsec without key management is
useless except in very narrow deployment scenarios.

> of secure communication.

Sure.

But I can also see lots of devices that (because of the mix of
applications/functionality of the device) simply won't use IPsec
becuase it doesn't make sense. Why MUST they  implement IPsec when it
won't actually get used?

If you look at reality, IPsec is not  the universal crypto suite. I
suspect the market has spoken.

> protocol for that closed environment.

I agree with this as well. In the case of cable modems, Alain
shouldn't care about what node requirements says. 

Thomas

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 27 Feb 2008 11:21:40 -0600

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 arguments that were the basis for it to be inserted do not apply
in many deployments (especially in networks which do not care about the
route-optimization feature).

-Raj

---

From: James Carlson <[email-masked]>
Date: Wed, 27 Feb 2008 12:20:27 -0500

> 2401).  OTOH, we at DoD and NIST are certainly addressing deployment 

That's an argument for: "if you claim to implement security at all
with IPv6, you must at least implement IPsec as described in {insert
references}."

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."

> like the NIST and DoD profiles and application documents.

If you do that, then the likely outcome is that systems that are
designed to be used in those special, constrained environments where
IPv6 is useful, but IPsec is not, will end up lacking the "IPv6 Ready"
logo and other acceptability marks.

It makes hash of those other profiles by requiring what isn't
necessarily required.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: <[email-masked]>
Date: Wed, 27 Feb 2008 11:43:26 -0600

James,

>> 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 
>> deployment
>
>That's an argument for: "if you claim to implement security at 
>all with IPv6, you must at least implement IPsec as described 
>in {insert references}."
>
>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."

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." I am sure we can find a few corner
cases,
but I find it hard to believe that we can accept this as a general
truism.

The Security Area has clearly stated that security is important; having
mechanisms to secure protocols is manditory; multiple non-madatory
solutions decrease security.  

I interpret this to mean that if you have IPv6, you need a common
mechanism
to secure it.  There is L2 security, and there are things like DTLS and
TLS,
but there needs to be security to be available at the IP layer.

John

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Feb 2008 12:59:53 -0500

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 practice) turns out to be much
harder than "just use IPsec". Really. The corollary to this is that
mandating IPsec (at the node level) doesn't actually get you usuable
security in IPv6.

TO get real security, you have to consider the actual application that
needs securing as well as the operational environment where the
deployment will take place. There are plenty of applications that
already have security that do not use IPsec. Should we/can we force
them to use IPsec? No.

And if an IPv6 node has limited functionality/purpose, and none of
that functionality appears likely to use IPsec (because it has other
means for providing security), what is the point of requiring IPsec?

I think the big message that people are missing is that IPsec has not
become the unbiquitous base-line security that we had once hoped for.

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 that makes or breaks usability.

Mandating IPsec with just static keying just isn't useful in practice.

Thus, continuing to mandate IPsec (while continuing to punt on key
management) just looks silly.

Thomas

---

From: James Carlson <[email-masked]>
Date: Wed, 27 Feb 2008 13:01:20 -0500

> all of the ways that their products will be deployed, so it is extremely

Some platform vendors _do_ sell into markets where deployments are
well understood.  Others, as you rightly note, do not.

I don't see a reason to saddle vendors who don't need a particular
feature with an empty requirement to provide it anyway.

> but I find it hard to believe that we can accept this as a general

If we can't assert that it's true in all cases, then why use "MUST"?

> solutions decrease security.  

I agree with the first and last of those, but not necessarily the
second.  That's why I believe that the text should say:

	SHOULD implement IPsec

and perhaps even:

	if any security protocols are implemented, then MUST implement
	at least IPsec

That leaves room for vendors who have no need of IPsec to comply with
the requirements.

It seems to me that what might be missing here is the definition of
"SHOULD."  It's not a whimsical requirement.  That word has special
meaning in this context:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

In other words, vendors who don't know what they're doing, and don't
understand the full implications of it, are required to follow the
recommendation.  Those who don't follow it need to know exactly what
they're doing and why the choice is right -- which matches up exactly
with your "few corner cases" comment above.

> to secure it.

No ... it means that if you have any common security mechanism, then
you need to provide a single common one.  Providing more than one is
not as good, but, clearly, providing zero is reasonable provided that
you _know_ nobody will use it anyway.

---

From: James Carlson <[email-masked]>
Date: Wed, 27 Feb 2008 13:02:10 -0500

> management) just looks silly.

Indeed.  It's a solution out looking for a problem.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 27 Feb 2008 19:22:46 +0100

Hi Thomas,

> John,

[snip]

>  management) just looks silly.

IMHO, mandating IPsec allows a "Better-Than-Nothing" security (c) :-)

Just a quick example:
Assume that one day, someone finds a security hole in a protocol used
for a specific service and having its own security mechanism. With
IPsec, even with manual configuration, you will be able to continue to
provide this service until a review of the protocol because you know
that the peers have a IPsec implementation. That should limit a
service disruption due to a security issue.

Best regards.

JMC.

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 27 Feb 2008 13:46:03 -0500

James:

> no plans to use those security protocols, so there."
I'll concede that point.  We need to say one or the other (unconditional 
or conditional MUST) and it seems this is the best forum to hash that 
out.  I am not religious about it being an unconditional MUST in the 
Node Requirements.  I am suggesting a "non-interference" statement, that 
to be a good IPv6 citizen you MUST NOT inhibit the use of IPsec. 
> logo and other acceptability marks.
I still believe in choice - customers can extend requirements to add 
special features, and can make choices regarding products without IPsec 
where they are adequate.  IETF can publish another 5000 RFCs that 
mandate IPsec, but vendors and customers are free to build and buy 
products that don't have it.  IETF should state what is necessary for 
interoperability, including statements about non-interference in some 
cases.  As long as I can use IPsec when I want it, why should I care if 
my neighbor has a host without it?  Or if my ISP blindly passes it 
without having any IPsec implementation?  I would care if my ISP blocked 
it because it prevented their "deep packet inspection."
> It makes hash of those other profiles by requiring what isn't
also a good point - exceptions are messier than extensions - but as long 
as exceptions are non-interfering, let the buyer beware.

Ed J.

---

From: Dow Street <[email-masked]>
Date: Wed, 27 Feb 2008 11:27:52 -0800

> no plans to use those security protocols, so there."

As I understand it, the current architecture of the Internet  
explicitly allows for local optimization everywhere but IP itself -  
IP is the one place where global functionality and interoperability  
trumps local optimization.  In defining the requirements for IP  
nodes, we are (I think) essentially defining the properties of the  
Internet itself.  In this case, I tend to think that there should be  
a mandatory security mechanism at the IP layer, at least for any IPv6  
node that is connected to the global Internet (or might be connected  
in the future).  It is less clear to me that IPsec is the best  
mechanism to provide this functionality, but changing to a new  
mechanism now may be worse than just sticking with IPsec.

quick poll - for those opposed to a MUST requirement for IPsec, what  
is your driving objection?

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 mechanism at the IP  
layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc)
4.  I don't care about the architecture of the Internet, because I  
intend to develop devices that are never connected to the global  
Internet (and therefore play no role in defining the Internet  
architecture or adhering to Internet best practices).

R,
Dow

---

From: "Kevin Kargel" <[email-masked]>
Date: Wed, 27 Feb 2008 14:18:01 -0600

> 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 IPSEC is MUST for routing hardware
and SHOULD for end user devices?  That way the end-to-end availablity is
still serviced, but low risk devices can stay simple and cheap.

Kevin

:$s/worry/happy/g

---

From: James Carlson <[email-masked]>
Date: Wed, 27 Feb 2008 15:34:01 -0500

> architecture or adhering to Internet best practices).

I suppose I'm closest to (1) in your list, but I'd still phrase it
differently.

5. IP itself works properly without IPsec -- and demonstrably so.
   It's not a _requirement_; it's not something that without which IP
   simply fails to operate.  It's desirable, and likely highly
   desirable, but it's not a fundamental issue.

It's fine to say that implementations darn well ought to have security
mechanisms unless they've got some really compelling reasons not to.
It's also fine to say that choosing a common one is far, far better
than having several.  However, that's not what "MUST" means.  MUST
means that you have no options for any other possible environment --
do it, or just ignore the RFC.

"SHOULD" carries with it a great deal of force.  You have some real
explaining to do if you choose to ignore the recommendation.  You
can't just do it on a whim.  I'd go so far as to say that if you
choose otherwise, and the result of your choice is that you fail to
fulfill other obligations that you have, then you've chosen
incorrectly and you're not complying with the letter of the RFC -- you
SHOULD have implemented it.

I suspect that the people who are arguing in favor of "MUST" have a
fear that "SHOULD" is just too weak.  I don't see how that's the case
at all, as it does indeed force nearly all implementors (those who
wish to become or remain compliant with the requirements of the RFC)
to implement IPsec -- which is exactly what the "MUST" contingent
wants.

(And, really, the lack of mandated key management does make even the
"SHOULD" language a bit of a farce, as Thomas Narten has correctly
observed.  You're not really getting any security goodness by
implementing a fraction of the bits needed for a real solution.)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Feb 2008 10:07:55 +1300

>    desirable, but it's not a fundamental issue.

I'm close to this position too, but even closer to

6. As long as the IETF specifies a way of securing the IP layer,
it's an implementation, procurement and operational issue
whether it gets used. Words in an RFC have no control over that.

And don't forget what Thomas said about keying.

   Brian

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 27 Feb 2008 16:27:26 -0500

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 implementation, but hesitate to mandate 
something that hardly exists in the near future...

But I would go along with Brian's sentiment about IETF not dictating 
use; that has been said a few times in various ways during this 
discussion.  Reality is even if 4294 is not updated, it makes no 
difference to the actual implementation and use of IPsec; if revision 
says nothing about IPsec, it makes no difference.  If the revision says 
SHOULD or MUST, probably makes no difference.  Implementors will make 
their own choices as will buyers of products.

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 27 Feb 2008 23:43:37 +0100

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 device will be the exception.

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ed Jankiewicz
Sent: mercredi 27 février 2008 13:27
To: [email-masked]
Cc: Brian E Carpenter
Subject: Re: the role of the node "requirements" document

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 implementation, but hesitate to mandate something that hardly exists in the near future...

But I would go along with Brian's sentiment about IETF not dictating use; that has been said a few times in various ways during this discussion.  Reality is even if 4294 is not updated, it makes no difference to the actual implementation and use of IPsec; if revision says nothing about IPsec, it makes no difference.  If the revision says SHOULD or MUST, probably makes no difference.  Implementors will make their own choices as will buyers of products.

Brian E Carpenter wrote:
>>> 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 
>>> mechanism at the IP layer, but IPsec *alone* is insufficient 
>>> (without IKE, key mgmt, etc) 4.  I don't care about the architecture 
>>> of the Internet, because I intend to develop devices that are never 
>>> connected to the global Internet (and therefore play no role in 
>>> defining the Internet architecture or adhering to Internet best 
>>> practices).
>>>       
> 6. As long as the IETF specifies a way of securing the IP layer, it's 
> an implementation, procurement and operational issue whether it gets 
> used. Words in an RFC have no control over that.
>

--
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: <[email-masked]>
Date: Wed, 27 Feb 2008 16:43:37 -0600

>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 will be the exception.

What is the harm if 1 million sensors are not respecting RFC 4294?

John

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 27 Feb 2008 23:53:52 +0100

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-masked] [mailto:[email-masked]] 
Sent: mercredi 27 février 2008 14:44
To: Julien Abeille (jabeille); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: the role of the node "requirements" document

>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 will be the exception.

John

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Feb 2008 16:09:21 -0800

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 capable of IPv6 communication only  
with peers at link-local scope addresses over links that implement  
their own link-layer security.

I say this from the experience of watching IEEE 802.11 progress from  
"security is optional" to "we messed up security really bad, sorry  
about that" to "security is strongly recommended, no really, everybody  
uses it now," and soon to "security is absolutely mandatory, we will  
kidnap your family and disappear you to jail if you don't secure your  
network."

I'll be sad if I have to go through that again with IPv6.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Sean Lawless <[email-masked]>
Date: Wed, 27 Feb 2008 16:46:37 -0800

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 other potential IPv6 nodes do not have the 
hardware resources to support IPSec, or those resources are better spent 
at other tasks.  This may fall under #4 in Dow Street's driving 
objection to RFC 4294 wording of MUST, but not necessarily.  With the 
simplicity of securing IP at the edge router with an IPSec tunnel, the 
point of mandating IPSec for nodes appears unwarranted.  I agree with 
Kevin that IPSec be SHOULD for hosts (but remain a MUST for routers).  
My argument is similar to #5 made by James Carlson.

There are many situations were IPv6 will be deployed without IPSec.  
There is no need to label these devices as non-IPv6 compliant within 
this hosts requirements document.  My gut feeling is that if IPSec MUST 
be supported then why is using it optional?  A MUST that is optional 
wouldn't be the first in IETF history but let it be known that some 
objected.

Some years ago I thought static keyed IPSec to be better than no 
security.  In reality IPSec can be compromised with enough traffic 
analysis, especially if portions of the clear text can be discerned 
(ICMPv6, etc).  Operational security depends on key changing and thus 
key management.  Over time, static keyed IPSec is either masochistic to 
manage or provides only the illusion of security.  Thus I also agree 
with Thomas, Ed and others that mandating static IPSec without key 
management will result in it's non use and now we're back to a MUST that 
is optional to deploy.

In conclusion I believe RFC 4294 be changed to SHOULD for IPSec because 
of #3, #4 and #5 of the poll.

BR,

**Sean Lawless** * | * /*Senior Software Engineer*/ * | * *Blunk 
Microsystems LLC* <http://www.blunkmicro.com> * | 408.XXX.XXXX*

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Thu, 28 Feb 2008 13:40:46 +0900

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 area to consider the reality that many 6LoWPAN implementors
feel hard to squeeze IPsec into the small sensor nodes.
I hope that this discussion trigger either the study of IPSec if it
can be enough lightweight to be applicable on 6LoWPAN nodes, or
practical solutions on sensor network security.

Thanks,

-eunah
(PS)  ISA's choice sounds very interesting for me, although I need to
check the details. Thanks Pascal for the information.

---

From: Nobuo OKABE <[email-masked]>
Date: Thu, 28 Feb 2008 13:54:20 +0900 (JST)

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 of choises for implementors.

Here are our experiences:

  - As I told in this ML,
    one of the problem of IKE/IKEv2 is PK (public key cryptography)
    when applying IPsec to resource limited devices.

  - PK impacts against those devices' sensitive factors:
    footprint/gatesize/throuput/power consumption.

  - Then, if using IKE* w/ PSK (Pre-Shared Key) instead of PK,
    the number of PSK is O(N^2) due to its e2e bases.
    It means scalability issue.

  - So, 3rd trusted party model (= Key Distribution Center model)
    is one of reasonable choices if you use PSK instead of PK.
    Because the number of PSK is O(N).
    # Kerberos is one of KDC models.
    # As FYI, if my understanding is correct,
    # key management of SP100 is also a kind of KDC model.
    # And, centralized management like KDC is fit for
    # the management style of "small-but-many-devices" system.

  - KINK (RFC4430) was designed for that.

  - I guess that many people worry that
    it is nightmare to speak multiple key exchange protocols.
    But, system is not so much complicated
    because resource limited devices usually relay on some servers.
    ex. Cheap devices speak cheap key exchange protocol (=KINK) only.
        Just several servers should be multilingual (IKE*/KINK).

  <A hat of WIDE Project>
  - We have opened reference code of multiple IPsec key exchange
    protocols (IKE/IKEv2/KINK) daemon called Racoon2.
    It can handles those protocols in the same node.
    So, it can be helpful hint for your multilingual servers.
  </A hat of WIDE Project>

Those is why I think IPsec is still useful security tools.

Again, I understand that above approach is not universal.
# and there is no universal approach of security, after all :-)

However, it can solve a part of issues discussed here
which can not be solved with IKE*.
(ex. some applications of sensor/actuator or resource limited devices).

Thanks,

From: Ed Jankiewicz <[email-masked]>
Subject: Re: the role of the node "requirements" document
Date: Wed, 27 Feb 2008 16:27:26 -0500

---

From: Julien Laganier <[email-masked]>
Date: Thu, 28 Feb 2008 10:04:32 +0100

Thomas, all,

On Wednesday 27 February 2008, Thomas Narten wrote:
> 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 changes the optimization no longer applies,
> > and may expose unexpected holes. This was in fact happening at the
> But if we look at the reality of things, IPsec (and we have to
> include IKE in evaluating this), IPsec just isn't the ideal
> one-size-fits-all technology we'd like it to be.
>
> that a certain level of security is present. 

Would that be the major showstopper in using IPsec for other things than 
VPNs, the IETF has chartered the BTNS WG to work on APIs to communicate 
with IPsec. The WG currently has two documents that need reviews:

http://tools.ietf.org/wg/btns/draft-ietf-btns-abstract-api/
http://tools.ietf.org/wg/btns/draft-ietf-btns-c-api/

> Second, good security says "don't trust anyone but yourself". So, do
> you trust the OS you are running on? 

If someone cares about security but doesn't trust the OS he's running 
on, I think the best thing he can do is to not use the OS in question.

> Do you trust the IPsec embedded in the system that was implemented by
> a third party? 

Keeping IPsec mandatory would be one facilitator of the move from IPsec 
implementation from third party to native IPsec implementation shipped 
with the OS that has to be trusted.

> Smart applications implement their own security (e.g., TLS) to ease
> deployment. 

How many applications really implement their *own* security? Many 
applications I'm using daily relies on libraries shipped with the OS 
that has to be trusted, e.g. gnutls and openssl.

> We'll never get them to rely on IPsec, at least not until its much
> more widely available/useable. 

Agree. But I think the availability part can be helped by keeping IPsec 
mandatory (so that it gets in more and more OS's), while the usability 
part can be helped by getting the BTNS WG to deliver its APIs (so that 
applications can finally start using IPsec).

--julien

---

From: Patrick Grossetete <[email-masked]>
Date: Thu, 28 Feb 2008 12:37:42 +0100

Hi,

         Having been through the whole thread, I have to react to 
this last proposal in regards of
operational deployments. I already raised several times the fact that 
IPsec on routers in NOT a generic requirement.

If the "requirements" are generic enough to consider the following 
realities then  I have no more issue

- "Router" definition - it ranges from Core to Edge routers to L3 
switches to low cost CPE devices to "a Node that
interconnects sub-networks by packet forwarding." - all those HW 
having different capabilities, cost and performances.
so, let's review the use of IPsec on "Routers".

- IPsec can be used by control plane features, such as OSPFv3 
Authentication (RFC 4552) or MIPv6 in case the router
act as MIPv6 Home Agent. It is purely a software feature with no real 
impact on hardware. But why should I support
IPsec if none of those features are implemented, let's say on a low 
cost CPE router?

- IPsec as management feature. As indicated by Fred, it looks to me 
that the preferred solution is currently SSH/SSL.
Is everybody agreeing about a potential market shift to IPsec?

- IPsec used by Data plane features, such as router-to-router IPsec 
tunnel where encryption could be hardware assisted.
However, if the IPsec tunnel is not terminated on a router, packets 
will get forwarded as raw traffic. But why should I
support this on a core router or Layer 3 switches which will never be 
configured as tunnel end-point?

- IPsec as end-to-end feature. No question it is used in well 
controlled domains but if it is a generic requirement to
not interact with traffic protected by IPsec, could we indicate that 
all features such as packet filtering, QoS marking
or re-marking, instrumentation are lost? which may not be an issue 
for some people but will certainly be one for others.
And yes, if AH is a "MAY" we need to find a better way to do 
authentication using ESP... a real IETF task.

Best Regards
Patrick

---

From: James Carlson <[email-masked]>
Date: Thu, 28 Feb 2008 08:44:30 -0500

> applications can finally start using IPsec).

You get exactly that same level of goodness with a BCP 14 "SHOULD."
The only difference is that "MUST" causes implementors with differing
fundamental marketing considerations to toss the whole requirements
RFC out on its ear -- because it mandates something that (in their
view) ought not be done or perhaps simply _cannot_ be done with
available resources.

MUST doesn't actually cause any more implementations to appear in
comparison to SHOULD.  I think your argument would work, though, if we
were discussing SHOULD versus MAY.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 28 Feb 2008 15:12:10 +0100

James,

On Thursday 28 February 2008, James Carlson wrote:
> > > We'll never get them to rely on IPsec, at least not until its
> > > much more widely available/useable.
> >
> > Agree. But I think the availability part can be helped by keeping
> > IPsec mandatory (so that it gets in more and more OS's), while the
> > usability part can be helped by getting the BTNS WG to deliver its
> > APIs (so that applications can finally start using IPsec).
>
> comparison to SHOULD.  I think your argument would work, though, if
> we were discussing SHOULD versus MAY.

You are right. SHOULD should be fine.

--julien

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 28 Feb 2008 09:56:09 -0500

> From: Sean Lawless [mailto:[email-masked]] 

> Kevin that IPSec be SHOULD for hosts (but remain a MUST for 

I strongly disagree.

If IPsec is not mandatory for hosts, then it MUST (if anything) be
mandatory for security gateways, NOT routers, with the exception perhaps
of securing the routing protocols. Reason being, you cannot achieve
security unless cybertext only goes through non-secure networks.

What you call "edge routers" I call security gateways. These are likely
routers, but they must not be confused with just any ole ISP router, or
router in any other core network that is not "secure" as far as the
client is concerned.

I think it's important not to give anyone the illusion of security.

Bert

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 28 Feb 2008 17:03:39 +0000

Thomas,

I am coming from 180 degrees where you are but I respect your input.  IPsec is required by any market (this includes VPNs and LAN only IPsec use) the IETF has been successful so I respectfully disagree with your market data.  In addition the infrastructure to support IPsec is not our concern in the IETF IPsec secures layer 3 on networks and that is highly valuable to the market. Each market segment will deal with PKI and user space API and Management issues on their own terms/conditions and methods.  I still think we have debate to move to a SHOULD but even a SHOULD says do this or have a good reason to not do it.  Moving it to MAY is unacceptable to me in the IETF as a note.

/jim

> Sent: Wednesday, February 27, 2008 1:00 PM
> > to understand all of the ways that their products will be
> deployed, so
> > it is extremely hard to state "security is not needed."
>
> What I am saying is that security (in practice) turns out to
> be much harder than "just use IPsec". Really. The corollary
> to this is that mandating IPsec (at the node level) doesn't
> actually get you usuable security in IPv6.
>
> TO get real security, you have to consider the actual
> application that needs securing as well as the operational
> environment where the deployment will take place. There are
> plenty of applications that already have security that do not
> use IPsec. Should we/can we force them to use IPsec? No.
>
> And if an IPv6 node has limited functionality/purpose, and
> none of that functionality appears likely to use IPsec
> (because it has other means for providing security), what is
> the point of requiring IPsec?
>
> I think the big message that people are missing is that IPsec
> has not become the unbiquitous base-line security that we had
> once hoped for.
>
> 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 that makes or
> breaks usability.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 28 Feb 2008 17:10:48 +0000

I believe all IPv6 nodes SHOULD support IPsec.  I don't care about the PKI or other managed parts but if they are referenced to IPsec they should have no known protocol interoperability problems, the market will decide and select on that one is my view.  This should clearly not mandate USE as others have stated.  I also would support a MUST as I agree with Dow and others who can see the value of a MUST but I will not fight to hard if majority wants to move to SHOULD.  If it is 50/50 for consensus I will continue to provide data why MUST has to remain.  And I want to reiterate and note the important mail from Tony Hain for this polling to others as input to our collective thoughts.

Thanks Dow
/jim

> Sent: Wednesday, February 27, 2008 4:27 PM
> To: [email-masked]
> Cc: Brian E Carpenter
> 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 implementation, but
> hesitate to mandate something that hardly exists in the near future...
>
> But I would go along with Brian's sentiment about IETF not
> dictating use; that has been said a few times in various ways
> during this discussion.  Reality is even if 4294 is not
> updated, it makes no difference to the actual implementation
> and use of IPsec; if revision says nothing about IPsec, it
> makes no difference.  If the revision says SHOULD or MUST,
> probably makes no difference.  Implementors will make their
> own choices as will buyers of products.
>
>
> Brian E Carpenter wrote:

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Thu, 28 Feb 2008 17:45:27 -0500

Colleagues,

While I agree with Jim in principal, I should add that the entire
premise of a "one size fits all" IPv6 node description will probably
suffer from being the too low lowest common denominator.  To wit, by
the definition in 4294, a host runs the gamut of complex servers to UDP
speakers attached to simple sensors, e.g., a thermometer.  As a result,
I am not sure how much impact 4294 will have with industry or
government, as the definition is so broad it is almost meaningless.
Just my $0.02.

Best Regards,
 
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bound, Jim
Sent: Thursday, February 28, 2008 12:11 PM
To: Ed Jankiewicz; [email-masked]
Cc: Brian E Carpenter
Subject: RE: the role of the node "requirements" document

I believe all IPv6 nodes SHOULD support IPsec.  I don't care about the
PKI or other managed parts but if they are referenced to IPsec they
should have no known protocol interoperability problems, the market
will decide and select on that one is my view.  This should clearly not
mandate USE as others have stated.  I also would support a MUST as I
agree with Dow and others who can see the value of a MUST but I will
not fight to hard if majority wants to move to SHOULD.  If it is 50/50
for consensus I will continue to provide data why MUST has to remain.
And I want to reiterate and note the important mail from Tony Hain for
this polling to others as input to our collective thoughts.

Thanks Dow
/jim

---

From: "Kevin Kargel" <[email-masked]>
Date: Fri, 29 Feb 2008 09:31:26 -0600

To make a furthur rediculous analogy, SMTP is a wonderfully
functional spec, and it makes perfect sense to mandate that any devices
utilizing SMTP MUST be compliant to the ESMTP spec RFC2821, but it would
be rather silly to mandate that ALL IPv6 connected devices be RFC2821
compliant regardless of whether they have a requirement for SMTP.  

	If the operating system of the nifty internet accessible
doohickey that you wish to patent and sell has no need to exchange
email, then building in ESMTP compliance would be an unecessary expense
that would reduce the profitiability of your venture and would cost
consumers (who ultimately pay for everything) more money. 

	It may be a piddling amount, and a trivial implementation, but
we must bear in mind the straw/camel parable.  Many little things can
aggregate to be a large burden.

> Kevin and many others against mandating (MUST) for IPSec have 
> a valid point.  Many sensors and other potential IPv6 nodes 
> do not have the hardware resources to support IPSec, or those 
> resources are better spent at other tasks. 
.....

---

From: <[email-masked]>
Date: Fri, 29 Feb 2008 09:47:41 -0600

Kevin,

I would say that is not a logical argument, IMO.  The IETF
has long considered security to be an essential part of internet 
protocols.  Pease read http://tools.ietf.org/html/rfc4301.
SMTP in that sense is optional, and not considered a part
of IPv6.  The ability to secure the IP layer has been
seen as a mandatory requirement from the Security AD.

That being said, there seems to be strong feeling that IPsec
support is not being considered mandatory, so the WG needs
to consider how we are able to secure the IP layer.  I do not
think l2 security is sufficient, as L2 security will not
create a security association between two arbitrary nodes
in the interenet.  

I would also mention that some people are looking at more
point solutions or solutions that may be deployed in a 
managed deployment. IMO, those are not the general case
that the Node Req. document is trying to address.

I will try to summarize this thread, but I think it might
be up to the WG chairs to discuss this with our ADs and the
Security ADs to understand what the IESG considers to be
the correct level of security requirements.

John

>Behalf Of ext Kevin Kargel
>Sent: 29 February, 2008 07:31
>To: [email-masked]
>	To make a furthur rediculous analogy, SMTP is a 
>wonderfully functional spec, and it makes perfect sense to 
>mandate that any devices utilizing SMTP MUST be compliant to 
>the ESMTP spec RFC2821, but it would be rather silly to 
>mandate that ALL IPv6 connected devices be RFC2821 compliant 
>regardless of whether they have a requirement for SMTP.  
>
>	If the operating system of the nifty internet 
>accessible doohickey that you wish to patent and sell has no 
>need to exchange email, then building in ESMTP compliance 
>would be an unecessary expense that would reduce the 
>profitiability of your venture and would cost consumers (who 
>ultimately pay for everything) more money. 
>
>	It may be a piddling amount, and a trivial 
>implementation, but we must bear in mind the straw/camel 
>parable.  Many little things can aggregate to be a large burden.
>
>
>> hardware resources to support IPSec, or those resources are better 
>> spent at other tasks.
>.....

---

From: Dow Street <[email-masked]>
Date: Fri, 29 Feb 2008 08:01:13 -0800

> compliant regardless of whether they have a requirement for SMTP.

I'm not an SMTP expert, but if I understand your comments correctly I  
think your analogy actually supports a MUST for IPsec for all IPv6  
nodes.

1.  "Node running SMTP MUST support ESMTP, and enhanced profile of  
SMTP with additional functionality"

is similar to...

2. "Node running IPv6 MUST support IPsec, an enhanced profile of IPv6  
with additional functionality"

Besides, analogies to mechanisms above or below IP are only partly  
useful, if you indeed believe that IP is a special part of the stack  
(the waist, the consensus, the common convergence layer, etc.)

R,
Dow

---

From: "Kevin Kargel" <[email-masked]>
Date: Fri, 29 Feb 2008 11:32:05 -0600

Not quite..  it would be more accurate if you said "

2. "Node running secure protocols MUST support IPsec, an enhanced
profile 
of IPv6 with additional functionality" 

> 1.  "Node running SMTP MUST support ESMTP, and enhanced 
> profile of SMTP with additional functionality"
> 
> is similar to...
> 
> 2. "Node running IPv6 MUST support IPsec, an enhanced profile 
> of IPv6 with additional functionality"
>