[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC 2401 section 5.2.1

To: Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>
Subject: Re: RFC 2401 section 5.2.1
From: itojun@iijlab.net
Date: Wed, 22 Nov 2000 00:16:29 +0900
cc: Henry Spencer <henry@spsystems.net>, Richard Draves <richdr@microsoft.com>, ipsec@lists.tislabs.com, Francis Dupont <Francis.Dupont@enst-bretagne.fr>, mobile-ip@standards.nortelnetworks.com
In-reply-to: jeanmichel.combes's message of Tue, 21 Nov 2000 13:32:39 +0100. <3A1A6B67.6F5176C6@rd.francetelecom.fr>
Sender: owner-ipsec@lists.tislabs.com


>> since the introduction of IPsec there are so many protocols that rely
>> upon the use of IPsec to protect it.  I wonder what is their underlying
>> security model.

	here are some examples of these.  not sure if they require header
	protection, but they are all tricky - issues with multicast issue
	(source address validation gets tricky), as well as bootstrap issue.
	most of routing protocol needs to somehow protect IPv6 source address,
	as they will use (peers') IPv6 source address as the nexthop router
	information.
	- RIPng (RFC2080, see section 4) 
	- OSPFv3 (RFC2740, see abstract and couple of other places)
	- neighbor discovery and stateless autoconfiguration
	  (RFC2461 section 3.1, RFC2462 p19)
		-> tricky chicken-and-egg problem exist, about how to setup SA
	- router renumbering (RFC2894, section 3 and 7.1)

itojun

Follow-Ups:

Re: RFC 2401 section 5.2.1

From: Henry Spencer <henry@spsystems.net>

References:

Re: RFC 2401 section 5.2.1

From: Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>

Prev by Date: Re: RFC 2401 section 5.2.1
Next by Date: Re: RFC 2401 section 5.2.1
Prev by thread: Re: RFC 2401 section 5.2.1
Next by thread: Re: RFC 2401 section 5.2.1
Index(es):
- Main
- Thread