Subject: RE: Next steps on the IPv6 Node requirements draft

From: <[email-masked]>
Date: Wed, 18 Jun 2003 14:22:33 +0300

Hi Peter,

Actually, the idea of the draft was to detail the existing
requirements, based on existing RFCs - not to create new 
requirements.  We've discussed with the Security ADs
that there would be a need for the IPsec WG to create
a list of recommended encryption mechanisms and that this
draft could reference such a spec.

John

> -----Original Message-----
> From: ext Peter Bell [mailto:[email-masked]]
> Sent: 18 June, 2003 02:09
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: Next steps on the IPv6 Node requirements draft
> 
> 
> Along with removing DES from the "SHALL" list, it looks 
> likely that AES
> will be added to the IPSec SHALL requirements, perhaps this 
> draft should
> include AES.
> 
> Peter.
> 
> [email-masked] wrote:
> > 
> > Hi all,
> > 
> > I've updated the draft on 4 major points that were 
> discussed at the IETF.  Roughly
> > they cover stateful address autoconfig support, DHCP 
> support, MIPv6 support and DES
> > support.
> > 
>  
> > 4) DES support removed:
> > 
> >  The "ESP DES-CBC Cipher Algorithm With Explicit IV" 
> [RFC-2405] SHOULD NOT be supported.
> >  Security issues related to the use of DES are discussed in 
> [DESDIFF], [DESINT],
> >  [DESCRACK]. It is still listed as required by the existing 
> IPsec RFCs, but as it is
> >  currently viewed as an inherently weak algorithm, and no 
> longer fulfills its intended role.
> > 
> 
> -- 
> //
> //  Peter L. Bell         [email-masked]
> //                        +61 2 9805 2955
> //  Blessed are the Peacemakers, they shall be called Sons of God.
> //
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 19 Jun 2003 14:05:37 +0300

Hi Robert,

I agree with you - this seems very much a node/user policy
decision, for the reasons you list below.  I don't think
the Node Requirements should impose any new behavior here.

thanks,
John

> From: ext Robert Elz [mailto:[email-masked]]
> Sent: 19 June, 2003 13:57
> To: Alain Durand
> Cc: Loughney John (NRC/Helsinki); [email-masked]
>     Date:        Wed, 18 Jun 2003 17:23:05 -0700
>     From:        Alain Durand <[email-masked]>
>     Message-ID:  <[email-masked]>
> 
>   | So what if the M bit is set _and_ a prefix is advertized?
>   | Should the node give up its stateless autoconfigured 
> address in favor of 
>   | DHCP?
> 
> No, it should do both.
> 
>   | What about statically configured addresses on the same node?
> 
> It should keep that as well, though often if there's to be static
> config it will often also be the case that use of stateless autoconfig
> and dhcp config will be disabled (either explicitly or implicitly)
> 
>   | IMHO, it makes little sense to have both a DHCP allocated 
> address and a 
>   | stateless autoconfigured address on the same interface.
> 
> In that case, you wouldn't config your routers to send the M bit, and
> prefixes with the A bit set, at the same time.
> 
> On the other hand, others may consider it useful to allow nodes to
> autoconfigure themselves addresses (so they always gave one, provided
> there's a working router to make the address useful) and at the same
> time, provide specific addresses to specific nodes (attempting to use
> DHCP doesn't necessarily mean the DHCP server will actually allocate
> an address) where specific nodes are expected to own well 
> known addresses.
> 
>   | However, I see cases where you want
>   | to have nodes using DHCP and nodes using stateless 
> autoconfiguration on 
>   | the same link.
> 
> The very nature of *stateless* autoconfig is that there's no 
> (easy) way to
> configure a node to not do it (manual config on that node 
> excepted).   If
> there was, it would not be stateless.   So, by default, if 
> any node on a
> link is permitted stateless autoconfig (of a prefix) all nodes are.
> 
> It is generally harmless to own an extra address though, having the
> statelessly configured one, as well as a dhcp supplied one should not
> cause any harm.
> 
> That is, I don't think receiving a DHCP allocated address should cause
> an autoconfig'd address to be dropped, there's no need (doing 
> do raises
> all the questions of what you do if you've been running using the
> autoconfig'd address for hours when the dhcp server returns to life
> and allocates you an address).
> 
> All that being said - a request to implementors out there.   
> It would be
> very (*very*) nice to have the ability in a node to ignore prefixes
> that are being advertised from routers, and never autoconfig 
> an address
> in that prefix.   That is, I occasionally see someone advertising a
> prefix that I know doesn't work (they're getting ready for the day it
> will work, and have just jumped the gun - believing in early 
> preparation
> or something).   I'd like to be able to ignore that (no matter what
> router advertises it - so lower level packet filtering doesn't help).
> 
> kre
> 
>

---

From: [email-masked]
Date: Thu, 19 Jun 2003 17:30:32 +0100

> From: Alain Durand [mailto:[email-masked]]
> Sent: 19 June 2003 17:07
> 
> On Thursday, June 19, 2003, at 03:56  AM, Robert Elz wrote:
> Not sure. Two reasons:
> 	- There may be filters in place, for example that only
> 	   allows DHCP assigned addresses to go out.
> 	   (this is not pure fantasy, I've heard people willing 
> to do just 
> that in hot spots).

Certainly it is not fantasy. Indeed I expect to become the norm for all
public access networks.

Mat.