On Wed, Jul 21, 2010 at 1:36 PM, Bob Hinden wrote:
> Julien,
>
>> That being said I agree that for constrained devices it might be desirable
>> not to implement IPsec and IKE. The question is, should we lower the node
>> requirements bar for all devices because of constrained devices. I don't
>
On Fri, 23 Jul 2010 09:20:54 -0400
"STARK, BARBARA H (ATTLABS)" wrote:
> > To summarize, the current document
> > - retains SLAAC as a MUST
> > - lists DHC (for address config) as a MAY
> > - makes DHC for other configuration a SHOULD.
> > - lists rfc5006bis (DNS RA Config) as a SHOULD
>
>
Hi,
My first choice was (in respect with RFC 2119):
- a MUST for IPsec
Because IPsec is the security architecture for the IP layer.
- a SHOULD for IKEv2
Because,
o Anti-replay service available for AH and ESP requires automated
SA management (cf. RFC 4301)
o Regarding scalability/deployment,
Hi,
writes:
> IPsec and IKEv2 are network layer protocols that are available in the
> security toolkit. And so are TLS, ssh, Kerberos etc.
TLS, ssh and Kerberos are available in "the security toolkit" but they
are not network layer protocols. IP and IPsec are.
> The IETF cannot force the choi
IPsec and IKEv2 are network layer protocols that are available in the security
toolkit.
And so are TLS, ssh, Kerberos etc.
The IETF cannot force the choice of a security protocol on applications or
other protocols
that need security. The choice of using IPsec and IKEv2 is available at all
ti
> To summarize, the current document
> - retains SLAAC as a MUST
> - lists DHC (for address config) as a MAY
> - makes DHC for other configuration a SHOULD.
> - lists rfc5006bis (DNS RA Config) as a SHOULD
I would prefer if nodes were required (MUST) to support one or the other
mechanism for
