Mark Smith | 2 Mar 00:11 2008

Re: Making IPsec *not* mandatory in Node Requirement ( was Re: Updates to Node Requirements-bis (UNCLASSIFIED))

Hi Alain,

On Tue, 26 Feb 2008 13:41:37 +0800
Alain Durand <alain_durand <at> cable.comcast.com> wrote:

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

An alternative argument to making it compulsory is demonstrated by DECT
cordless phone standard. The DECT standard made encryption optional,
and when I went looking for a DECT home phone that had encryption
between the handset and the base station, none of them did. I wanted to
avoid the repeat situation of my neighbours accidently or intentionally
(Continue reading)

Eric Klein | 2 Mar 12:54 2008
Picon

Re: ipv6 as an export issue

Does this mean that Microsoft went and got approval for every Windows PC since XP came out? Or that every PC manufacture (including hand helds and Windows Mobile cell phones) had to do register too?
 
Seems a bit extreme to me.
Eric


 
On 2/29/08, Ed Jankiewicz <edward.jankiewicz <at> sri.com> wrote:
wow.  I've never heard of the Bureau of Industry and Security.  I'll do
a little digging, hopefully can get an opinion from someone at NSA.  It
seems like an overly simplistic assumption that all IPv6 products are
encryption items.  I'll post anything I discover that is "approved for
public release" to the list.

mtaylor.design <at> yahoo.com wrote:
> Hello Ed,
>
> We have been fighting this battle directly with government personal
> at the Bureau of Industry and Security
> (http://www.bis.doc.gov/about/index.htm)
> both by email and by phone.  It has been going on for months.  We finally
> had a phone conversation with a higher level manager at BIS just the
> other day and as I expected by then we were told basically that if IPv6
> is mentioned anywhere in our product's documentation (even for socket
> layer protocols like FTP or Telnet that happen to be able to run over
> IPv6 sockets) that we MUST submit these products as encryption items
> and fill out Supplement No. 6 to Part 742—Guidelines for Submitting
> Review Requests
> for Encryption Items and that they will have to go to the NSA and
> others for review.
> The mistake we made before is that we tried to submit these items as
> if they did
> not include any encryption capabilities, which of course they do not,
> but this manager
> informed us that in that case the review is done by lower level people
> who absolutely are
> trained that if it says IPv6 then it is an encryption item because, as
> this manager told us
> repeatedly, IPv6 by definition includes security so any products that
> support IPv6 are
> by definition encryption items and must be reviewed by BIS as such.
> And this
> review is done by different people than the ones who review non-encryption
> items.  We tried to explain again to him that technically it simply
> wasn't true that
> IPv6 really has built-in security but as I expected it wasn't any use.
>
> He assured us that so long as we explained in supplement 6 that in so
> many words
> the products were "passive" with regard to security, i.e, had no means
> of influencing
> whether or not any security was applied to the application data, then
> it would not
> be a lengthy process and we should get them through pretty easily.
> But he also
> explained that the goverment doesn't care where the actual security
> operations
> get carried out in the code.  That is, the fact that it is all done by
> a separate
> IPsec module and that we can sell our IPv6 code without IPsec is
> irrelevant.
> The issue as best we can tell seems to be whether the product provides
> an API
> by which a user of the product could influence/configure the use of
> security.  Of
> course none of our socket-layer products have such an API, and in fact
> our IPv6
> stack doesn't even have such an API.  Only the IPsec product itself
> has such
> an API.
>
> So once we explained this to him he acknowledged that probably we will
> in the
> end be able to export the IPv6 products, without IPsec, under a lesser
> export
> license (I forget the number) than an actual encryption item such as
> IPsec itself.
> However, the products MUST still go to the correct people for review
> and thus
> MUST be submitted with Supplement 6 as potential encryption items or they
> will never get through.  The laughable part is that every single part
> of Supplement
> 6 will end up being filled out as N/A since this form asks you to
> supply the
> details, like supported maximum encryption key lengths, for the supposed
> encryption item.  It's like some episode of MASH.
>
> So it really aggravates us that because this misguided notion has been
> propagated
> that IPv6 somehow has "built-in" security we must now go through this
> lengthier and
> more involved process than we otherwise would have.  Especially since,
> as we all know,
> IPv6 has does not have built-in security any more than does IPv4 and
> yet apparently
> because of the IPv6 node requirements document mandating that IPv6
> nodes must
> support IPsec the goverment has been lead to believe that IPv6 by
> definition has
> built-in security.
>
> Regards,
>
> Mike Taylor
>
>
> ----- Original Message ----
> From: Ed Jankiewicz <edward.jankiewicz <at> sri.com>
> To: Mike Taylor <mtaylor.design <at> yahoo.com>
> Cc: ipv6 <at> ietf.org
> Sent: Friday, February 29, 2008 10:22:47 AM
> Subject: Re: ipv6 Digest, Vol 46, Issue 33
>
> Can you provide a citation to some authority for export restrictions on
> IPv6?  I have not heard that before and find it surprising (though not
> impossible).  That would be troubling, because IPsec in and of itself
> (and by association IPv6) does not necessarily contain any cryptographic
> code, although an implementation might.  Also, not all algorithms would
> be subject to export control.  Nothing in IPv6 or IPsec compels an
> implementor to include any restricted cryptographic code.
>
> I am definitely not a cryptography expert, nor am I an authority on US
> export regulations.  However, in my day job I deal with IPv6 standards
> for US DoD and interact with a lot of vendors.  I don't recall this
> coming up with any vendors, but if there is a chance this will be an
> issue, I need to do some homework.  In particular, for DoD use we may
> require more advanced algorithms (see RFC 4869 and
> http://www.nsa.gov/ia/industry/crypto_suite_b.cfm) and I don't know what
> the restrictions on export of that code would be.
>
> Ed J.
>
> Mike Taylor wrote:
> >
> > And while it isn't a surmountable problem
> >
> >
> >
> > 5. We are being forced to treat all of our IPv6 enabled protocols such
> >
> >    as FTP as encryption items by the U.S. export authorities because
> >
> >    the U.S. government thinks they must be since IPv6 "includes
> >
> >    security".  It's just plain silly since our IPv6 is no different
> >
> >    than our IPv4 - both get all their security from our IPsec which
> >
> >    is sold separately.  But we can't convince them otherwise because it
> >
> >    has been mandated that all IPv6 nodes shall support IPsec.
> >
> >    We can sell our IPv6 code without any trace of IPsec save for a few
> >
> >    lines of interface code that are #ifdef'd out when IPsec isn't
> present
> >
> >    and yet our IPv6 stack and worse yet, all of the socket-layer apps
> >
> >    that support IPv6, are viewed as encryption items.  Good grief.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Mike Taylor
> >
> >
> >
> > > R,
> >
> > > Dow
> >
> > >
> >
> > >
> >
> > > ------------------------------
> >
> > >
> >
> > > _______________________________________________
> >
> > > ipv6 mailing list
> >
> > > ipv6 <at> ietf.org <mailto:ipv6 <at> ietf.org>
> >
> > > https://www.ietf.org/mailman/listinfo/ipv6
> >
> > >
> >
> > >
> >
> > > End of ipv6 Digest, Vol 46, Issue 33
> >
> > > ************************************
> >
> > ------------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6 <at> ietf.org <mailto:ipv6 <at> ietf.org>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>

--
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or  ed.jankiewicz <at> sri.com


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Alexandru Petrescu | 3 Mar 09:48 2008
Picon

Re: IPv6 as an export issue

Thomas Narten wrote:
> Mike Taylor <mtaylor.design <at> yahoo.com> writes:
> 
>> And while it isn't a surmountable problem
>> 
>> 5. We are being forced to treat all of our IPv6 enabled protocols 
>> such as FTP as encryption items by the U.S. export authorities 
>> because the U.S. government thinks they must be since IPv6 
>> "includes security".  It's just plain silly since our IPv6 is no 
>> different than our IPv4 - both get all their security from our 
>> IPsec which is sold separately.  But we can't convince them 
>> otherwise because it has been mandated that all IPv6 nodes shall 
>> support IPsec. We can sell our IPv6 code without any trace of IPsec
>>  save for a few lines of interface code that are #ifdef'd out when 
>> IPsec isn't present and yet our IPv6 stack and worse yet, all of 
>> the socket-layer apps that support IPv6, are viewed as encryption 
>> items.  Good grief.
> 
> This sounds completely bogus to me. I've never heard of this problem
>  before. Who else has this problem?

Sorry, I've not followed the complete thread, I just follow on this
message snippet.

A while ago, when planning for implementing an IPv6 stack, we faced some
regulating issues.  Namely that because 3des, sha-1 and md-5 were
necessary parts for ESP and AH, necessary parts of IPv6, and because
this code was clearly under US export control regulations at that time,
and because we were in a country different than the one controlling its
export, and because in that country use of encryption software was
regulated differently - we decided to write our own implementations of
these algorithms and submit it to different regulators in a way we
wanted to.  The goal was not to circumvent these controls, which are
really the law, but to have control about how to be controlled, if I can
say so.  This was successful to a certain degree, but also faced many
hurdles to get through.

Remark that similar worries circulated when linux kernels started
including IPsec features by default (from freeswan was that?).  I'm not
sure where is it now, but I think linux 2.6 kernels are widely deployed
and include this security code.

Remark also that, for example, SHA-1 code wasn't available in an RFC
except until recently.  I'm not sure IETF faces these RFCs to the
different export regulations of different countries.

Just some thoughts, and and I'd like to stress the various local
regulations on security code are far from approaching any level of
bogusness and can backfire very nasty - one should learn the different
governments' requirements and act responsibly.

Alex

> 
> Thomas
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6 <at> ietf.org Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Merike Kaeo | 4 Mar 04:51 2008

Re: ipv6 as an export issue

I used to follow export issues in 1997/1998 at which time any 'hard- 
to crack' encryption was not exportable [hence all sorts of  
implementations using 40 bit keys]......yet any crypto used solely  
for authentication purposes was exempt.  This has changed over the  
years and of course different countries have different regulations.

This wiki is actually pretty good in terms of a synopsis on the  
history in US:
http://en.wikipedia.org/wiki/Export_of_cryptography

Any vendor shipping IPsec (or any other technology utilizing  
cryptographic algorithms) since mid 1990's will be familiar with the  
export rules (and their permutations).   All companies shipping  
products with encryption [or thinking of doing so] need to look at  
http://www.bis.doc.gov/encryption/default.htm ..... and http:// 
www.bis.doc.gov/encryption/lechart1.htm

I guess the Bureau of Industry and Security may need some re- 
education since in practice not all IPv6 implementations support  
IPsec with encryption capability (some initial implementations that  
did IPsec as a checkmark only shipped IPsec AH).   To me it also  
seems an education process for new vendors that deal with v6 and have  
no prior export issue experience.......while it seems ridiculous to  
fill out paperwork with N/A in all  
fields........well............whatever it takes to get the right  
license.

- merike

On Feb 29, 2008, at 12:47 PM, Ed Jankiewicz wrote:

> wow.  I've never heard of the Bureau of Industry and Security.   
> I'll do
> a little digging, hopefully can get an opinion from someone at  
> NSA.  It
> seems like an overly simplistic assumption that all IPv6 products are
> encryption items.  I'll post anything I discover that is "approved for
> public release" to the list.
>
> mtaylor.design <at> yahoo.com wrote:
>> Hello Ed,
>>
>> We have been fighting this battle directly with government personal
>> at the Bureau of Industry and Security
>> (http://www.bis.doc.gov/about/index.htm)
>> both by email and by phone.  It has been going on for months.  We  
>> finally
>> had a phone conversation with a higher level manager at BIS just the
>> other day and as I expected by then we were told basically that if  
>> IPv6
>> is mentioned anywhere in our product's documentation (even for socket
>> layer protocols like FTP or Telnet that happen to be able to run over
>> IPv6 sockets) that we MUST submit these products as encryption items
>> and fill out Supplement No. 6 to Part 742—Guidelines for Submitting
>> Review Requests
>> for Encryption Items and that they will have to go to the NSA and
>> others for review.
>> The mistake we made before is that we tried to submit these items as
>> if they did
>> not include any encryption capabilities, which of course they do not,
>> but this manager
>> informed us that in that case the review is done by lower level  
>> people
>> who absolutely are
>> trained that if it says IPv6 then it is an encryption item  
>> because, as
>> this manager told us
>> repeatedly, IPv6 by definition includes security so any products that
>> support IPv6 are
>> by definition encryption items and must be reviewed by BIS as such.
>> And this
>> review is done by different people than the ones who review non- 
>> encryption
>> items.  We tried to explain again to him that technically it simply
>> wasn't true that
>> IPv6 really has built-in security but as I expected it wasn't any  
>> use.
>>
>> He assured us that so long as we explained in supplement 6 that in so
>> many words
>> the products were "passive" with regard to security, i.e, had no  
>> means
>> of influencing
>> whether or not any security was applied to the application data, then
>> it would not
>> be a lengthy process and we should get them through pretty easily.
>> But he also
>> explained that the goverment doesn't care where the actual security
>> operations
>> get carried out in the code.  That is, the fact that it is all  
>> done by
>> a separate
>> IPsec module and that we can sell our IPv6 code without IPsec is
>> irrelevant.
>> The issue as best we can tell seems to be whether the product  
>> provides
>> an API
>> by which a user of the product could influence/configure the use of
>> security.  Of
>> course none of our socket-layer products have such an API, and in  
>> fact
>> our IPv6
>> stack doesn't even have such an API.  Only the IPsec product itself
>> has such
>> an API.
>>
>> So once we explained this to him he acknowledged that probably we  
>> will
>> in the
>> end be able to export the IPv6 products, without IPsec, under a  
>> lesser
>> export
>> license (I forget the number) than an actual encryption item such as
>> IPsec itself.
>> However, the products MUST still go to the correct people for review
>> and thus
>> MUST be submitted with Supplement 6 as potential encryption items  
>> or they
>> will never get through.  The laughable part is that every single part
>> of Supplement
>> 6 will end up being filled out as N/A since this form asks you to
>> supply the
>> details, like supported maximum encryption key lengths, for the  
>> supposed
>> encryption item.  It's like some episode of MASH.
>>
>> So it really aggravates us that because this misguided notion has  
>> been
>> propagated
>> that IPv6 somehow has "built-in" security we must now go through this
>> lengthier and
>> more involved process than we otherwise would have.  Especially  
>> since,
>> as we all know,
>> IPv6 has does not have built-in security any more than does IPv4 and
>> yet apparently
>> because of the IPv6 node requirements document mandating that IPv6
>> nodes must
>> support IPsec the goverment has been lead to believe that IPv6 by
>> definition has
>> built-in security.
>>
>> Regards,
>>
>> Mike Taylor
>>
>>
>> ----- Original Message ----
>> From: Ed Jankiewicz <edward.jankiewicz <at> sri.com>
>> To: Mike Taylor <mtaylor.design <at> yahoo.com>
>> Cc: ipv6 <at> ietf.org
>> Sent: Friday, February 29, 2008 10:22:47 AM
>> Subject: Re: ipv6 Digest, Vol 46, Issue 33
>>
>> Can you provide a citation to some authority for export  
>> restrictions on
>> IPv6?  I have not heard that before and find it surprising (though  
>> not
>> impossible).  That would be troubling, because IPsec in and of itself
>> (and by association IPv6) does not necessarily contain any  
>> cryptographic
>> code, although an implementation might.  Also, not all algorithms  
>> would
>> be subject to export control.  Nothing in IPv6 or IPsec compels an
>> implementor to include any restricted cryptographic code.
>>
>> I am definitely not a cryptography expert, nor am I an authority  
>> on US
>> export regulations.  However, in my day job I deal with IPv6  
>> standards
>> for US DoD and interact with a lot of vendors.  I don't recall this
>> coming up with any vendors, but if there is a chance this will be an
>> issue, I need to do some homework.  In particular, for DoD use we may
>> require more advanced algorithms (see RFC 4869 and
>> http://www.nsa.gov/ia/industry/crypto_suite_b.cfm) and I don't  
>> know what
>> the restrictions on export of that code would be.
>>
>> Ed J.
>>
>> Mike Taylor wrote:
>>>
>>> And while it isn't a surmountable problem
>>>
>>>
>>>
>>> 5. We are being forced to treat all of our IPv6 enabled protocols  
>>> such
>>>
>>>    as FTP as encryption items by the U.S. export authorities because
>>>
>>>    the U.S. government thinks they must be since IPv6 "includes
>>>
>>>    security".  It's just plain silly since our IPv6 is no different
>>>
>>>    than our IPv4 - both get all their security from our IPsec which
>>>
>>>    is sold separately.  But we can't convince them otherwise  
>>> because it
>>>
>>>    has been mandated that all IPv6 nodes shall support IPsec.
>>>
>>>    We can sell our IPv6 code without any trace of IPsec save for  
>>> a few
>>>
>>>    lines of interface code that are #ifdef'd out when IPsec isn't
>> present
>>>
>>>    and yet our IPv6 stack and worse yet, all of the socket-layer  
>>> apps
>>>
>>>    that support IPv6, are viewed as encryption items.  Good grief.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Mike Taylor
>>>
>>>
>>>
>>>> R,
>>>
>>>> Dow
>>>
>>>>
>>>
>>>>
>>>
>>>> ------------------------------
>>>
>>>>
>>>
>>>> _______________________________________________
>>>
>>>> ipv6 mailing list
>>>
>>>> ipv6 <at> ietf.org <mailto:ipv6 <at> ietf.org>
>>>
>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>
>>>>
>>>
>>>>
>>>
>>>> End of ipv6 Digest, Vol 46, Issue 33
>>>
>>>> ************************************
>>>
>>> -------------------------------------------------------------------- 
>>> ----
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6 <at> ietf.org <mailto:ipv6 <at> ietf.org>
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
>
> -- 
> Ed Jankiewicz - SRI International
> Fort Monmouth Branch Office - IPv6 Research
> Supporting DISA Standards Engineering Branch
> 732-389-1003 or  ed.jankiewicz <at> sri.com
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 <at> ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Julien Laganier | 5 Mar 10:53 2008
Picon

Re: Update for ikev2-ipv6-config draft

On Wednesday 13 February 2008, Pasi.Eronen <at> nokia.com wrote:
> Hi,
>
> I have posted a new version of the ikev2-ipv6-config draft
> (http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-ipv6-config)
> which incorporates some new ideas based on good discussions
> in Vancouver (Hemant and Dave, thanks!).
>
> In particular, Section 5 has new text discussing the most important
> design choices to be made, and Appendix A has additional solution
> sketches for several design choice combinations.
>
> Section 6 still proposes the same solution as in draft version -01;
> that is, point-to-point link model where prefixes are assigned in
> IKEv2 configuration payloads, and access control is enforced by
> IPsec (traffic selectors in SAD/SPD). To me this seems to be the
> simplest solution -- however, the additional sketches in Appendix A
> should make it easier to compare different alternatives; and
> comments about them would be especially welcome!

Hello Pasi,

Thanks for updating your draft. I think this is useful work.

I have some comments below:

3.2.  Link-Local Addresses

   The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6
   addresses of all types are assigned to interfaces, not nodes. [..]
   All interfaces are required to have at least one Link-Local unicast
   address".

   Currently, the virtual interface created by IKEv2 configuration
   payloads does not have link-local addresses.  This violates
   [IPv6Addr] and prevents the use of protocols that require link-local
   addresses, such as [MLDv2].

Here you could mention DHCPv6 as well (and you are in Section 3.5, with 
DHCPv6 PD). If one has a link-local address, it can use DHCPv6 to 
retrieve various configuration parameters from the DHCPv6 server, 
besides IPv6 address and DNS server address which are already handled 
via the CFG_* exchange. That would allow to decouple introduction of 
new configuration parameters from IKEv2 since only DHCPv6 support would 
be needed.

3.4.  Interface Identifier Selection

   In the message exchange shown in Figure 2, the gateway chooses the
   interface ID used by the client.  It is also possible for the client
   to request a specific interface ID; the gateway then chooses the
   prefix part.

   This approach complicates the use of Cryptographically Generates
   Addresses [CGA].  With CGAs, the interface ID cannot be calculated
   before the prefix is known.  The client could first obtain a non-CGA
   address to determine the prefix, and then send a separate CFG_REQUEST
   to obtain a CGA address with the same prefix.  However, this approach
   requires that the IKEv2 software component provides an interface the
   component managing CGAs; an ugly implementation dependency that would
   be best avoided.

nit: s/an interface the/an interface to the/

4.1.  Main Requirements

[...]

   o  A VPN client can be assigned multiple prefixes for use on the
      client-gateway link.  The client does not have to know beforehand
      how many prefixes are needed.

[...]

   o  It should be possible to share the VPN access over a local area
      network connection, without requiring anything special from other
      hosts in the local network (beyond minimal IPv6 node requirements
      specified in [RFC4294]).

These two requirements turn into the ability for client to be delegated 
prefixes while not assigning them to the client-gateway link. They 
could then be included in the negotiated TS's and routed appropriately 
by the gateway to the client.

The ability to do prefix delegation with DHCP within the IPsec tunnel 
interface could be useful for NEMO prefix delegation. Right now it is 
not possible to use DHCP PD out of the box for NEMO prefix delegation 
since multicast DHCP messages cannot be sent through an IPsec tunnel 
between the NEMO Mobile Router and the Home Agent.

--julien
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Bob Hinden | 5 Mar 19:50 2008
Picon

6man Agenda for the Philadelphia IETF

Hi,

The agenda for the 6man session for the Philadelphia IETF is posted at:

   http://www.ietf.org/proceedings/08mar/agenda/6man.txt

Let us know if we missed anything.

The presenters should send us their slides the day before the meeting  
so we can upload them to the IETF site so they will be available for  
people not in the room.

Thanks,
Bob & Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

john.loughney | 5 Mar 20:46 2008
Picon

Security Requirements for IPv6 Node Req summary

Hi all,

The RFC 4294-bis draft has the following requirement, which comes from
the initial RFC.

 8.1. Basic Architecture

   Security Architecture for the Internet Protocol [RFC-4301] MUST be
   supported.

 8.2. Security Protocols

   ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be supported.

We have had a lot of discussion that people basically feel that these
requirements
are not applicable and should be moved to SHOULD.  I would say that
there is rough
WG Consensus on this.  Do people feel if there should be additional text
to explain
this?

I suggest that the WG Chairs and our ADs discuss this with the Security
ADs to ensure
that this is a reasonable consensus to adopt - so that we do not run
into issues
during the eventual IETF/IESG review.  I am not sure that we can go much
further in 
discussions in the WG.

Does anyone have comments on this approach?

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Vishwas Manral | 5 Mar 21:12 2008
Picon

Re: Security Requirements for IPv6 Node Req summary

Hi John,

RFC4301 states AH is optional. Is there a reason why we are making it
a MUST be supported feature. Below quoting RFC4301:

"IPsec implementations MUST support ESP and MAY
   support AH."

Thanks,
Vishwas

On Wed, Mar 5, 2008 at 11:46 AM,  <john.loughney <at> nokia.com> wrote:
> Hi all,
>
>  The RFC 4294-bis draft has the following requirement, which comes from
>  the initial RFC.
>
>   8.1. Basic Architecture
>
>    Security Architecture for the Internet Protocol [RFC-4301] MUST be
>    supported.
>
>   8.2. Security Protocols
>
>    ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be supported.
>
>  We have had a lot of discussion that people basically feel that these
>  requirements
>  are not applicable and should be moved to SHOULD.  I would say that
>  there is rough
>  WG Consensus on this.  Do people feel if there should be additional text
>  to explain
>  this?
>
>  I suggest that the WG Chairs and our ADs discuss this with the Security
>  ADs to ensure
>  that this is a reasonable consensus to adopt - so that we do not run
>  into issues
>  during the eventual IETF/IESG review.  I am not sure that we can go much
>  further in
>  discussions in the WG.
>
>  Does anyone have comments on this approach?
>
>  John
>
>  --------------------------------------------------------------------
>  IETF IPv6 working group mailing list
>  ipv6 <at> ietf.org
>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>  --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

john.loughney | 5 Mar 21:14 2008
Picon

RE: Security Requirements for IPv6 Node Req summary

Sorry, that was a cut & paste mistake. AH is a MAY.

John 

>-----Original Message-----
>From: ext Vishwas Manral [mailto:vishwas.ietf <at> gmail.com] 
>Sent: 05 March, 2008 12:12
>To: Loughney John (Nokia-OCTO/PaloAlto)
>Cc: ipv6 <at> ietf.org
>Subject: Re: Security Requirements for IPv6 Node Req summary
>
>Hi John,
>
>RFC4301 states AH is optional. Is there a reason why we are 
>making it a MUST be supported feature. Below quoting RFC4301:
>
>"IPsec implementations MUST support ESP and MAY
>   support AH."
>
>Thanks,
>Vishwas
>
>On Wed, Mar 5, 2008 at 11:46 AM,  <john.loughney <at> nokia.com> wrote:
>> Hi all,
>>
>>  The RFC 4294-bis draft has the following requirement, which comes 
>> from  the initial RFC.
>>
>>   8.1. Basic Architecture
>>
>>    Security Architecture for the Internet Protocol [RFC-4301] MUST be
>>    supported.
>>
>>   8.2. Security Protocols
>>
>>    ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be 
>supported.
>>
>>  We have had a lot of discussion that people basically feel 
>that these  
>> requirements  are not applicable and should be moved to SHOULD.  I 
>> would say that  there is rough  WG Consensus on this.  Do 
>people feel 
>> if there should be additional text  to explain  this?
>>
>>  I suggest that the WG Chairs and our ADs discuss this with the 
>> Security  ADs to ensure  that this is a reasonable consensus 
>to adopt 
>> - so that we do not run  into issues  during the eventual IETF/IESG 
>> review.  I am not sure that we can go much  further in  
>discussions in 
>> the WG.
>>
>>  Does anyone have comments on this approach?
>>
>>  John
>>
>>  --------------------------------------------------------------------
>>  IETF IPv6 working group mailing list
>>  ipv6 <at> ietf.org
>>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>  --------------------------------------------------------------------
>>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Brian E Carpenter | 5 Mar 22:21 2008
Picon

Re: Security Requirements for IPv6 Node Req summary

If we write a SHOULD we really do need some guidance
as to when it doesn't apply. Otherwise we make it too
easy for product managers to simply cross it off the list.
How about

  The normal expectation is that a complete IPv6 stack
  includes an implementation of ESP. However, it is
  recognized that some stacks, implemented for low-end
  devices that will be deployed for special purposes
  where strong security is provided by other protocol
  layers, may omit ESP.

Regards
   Brian Carpenter
   University of Auckland

On 2008-03-06 09:14, john.loughney <at> nokia.com wrote:
> Sorry, that was a cut & paste mistake. AH is a MAY.
> 
> John 
> 
>> -----Original Message-----
>> From: ext Vishwas Manral [mailto:vishwas.ietf <at> gmail.com] 
>> Sent: 05 March, 2008 12:12
>> To: Loughney John (Nokia-OCTO/PaloAlto)
>> Cc: ipv6 <at> ietf.org
>> Subject: Re: Security Requirements for IPv6 Node Req summary
>>
>> Hi John,
>>
>> RFC4301 states AH is optional. Is there a reason why we are 
>> making it a MUST be supported feature. Below quoting RFC4301:
>>
>> "IPsec implementations MUST support ESP and MAY
>>   support AH."
>>
>> Thanks,
>> Vishwas
>>
>> On Wed, Mar 5, 2008 at 11:46 AM,  <john.loughney <at> nokia.com> wrote:
>>> Hi all,
>>>
>>>  The RFC 4294-bis draft has the following requirement, which comes 
>>> from  the initial RFC.
>>>
>>>   8.1. Basic Architecture
>>>
>>>    Security Architecture for the Internet Protocol [RFC-4301] MUST be
>>>    supported.
>>>
>>>   8.2. Security Protocols
>>>
>>>    ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be 
>> supported.
>>>  We have had a lot of discussion that people basically feel 
>> that these  
>>> requirements  are not applicable and should be moved to SHOULD.  I 
>>> would say that  there is rough  WG Consensus on this.  Do 
>> people feel 
>>> if there should be additional text  to explain  this?
>>>
>>>  I suggest that the WG Chairs and our ADs discuss this with the 
>>> Security  ADs to ensure  that this is a reasonable consensus 
>> to adopt 
>>> - so that we do not run  into issues  during the eventual IETF/IESG 
>>> review.  I am not sure that we can go much  further in  
>> discussions in 
>>> the WG.
>>>
>>>  Does anyone have comments on this approach?
>>>
>>>  John
>>>
>>>  --------------------------------------------------------------------
>>>  IETF IPv6 working group mailing list
>>>  ipv6 <at> ietf.org
>>>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>  --------------------------------------------------------------------
>>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 <at> ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


Gmane