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

Re: ICMP in IPSec

Hi,

I think that you're trying to approach this problem from a too low
level perspective. The really important question is about trust.

	"Can I trust the sender of the ICMP message?"

	"Can I trust that the ICMP message has not 
	 been changed en-route?"

There's really not much you can do if you don't know anything about
the sender and the ICMP message is not IPSec protected. However, there
is much else that can be done inside one ISP, for instance. You could
state that every ISP router trusts every other ISP router for the purpose
of sending reliable ICMP messages (or subset of them). The ISP routers
as a community could also trust Vorlon VPN routers to issue reliable
ICMP messages regarding Vorlon VPN traffic. Ditto for the Shadow VPN.
All ICMP messages from unknown senders would be scrapped.

Now the problem at hand is authentication, and the avoidance of
creating an IPSec connection from every router to every other router.
Supposing every router has a certificate, there're methods using X.509
to check if the router belongs to one of these sets: ISP, Vorlon, Shadow.
Now, we could make our routers create a hop-by-hop IPSec connection when
they first make contact. Since they're hop-by-hop, there's a limited number
of them. We can then pass ICMP messages along these hop-by-hop IPSec SA's.
No-one outside the group can alter (or see) these ICMP messages, we trust
every router to correctly handle ICMP messages, so we can trust the ICMP
message itself. There's likely some specific handling to be done at the
edges between ISP and Vorlon VPN, for instance, to prevent leaking of information
and incorrect ICMP message passing.

Regards,

	Ari Huttunen
	Ericsson ///


rcharlet@redcreek.com wrote:
> 
> Howdy ()
> 
>         There exists a draft named draft-ietf-icmp-handle-44-00.txt
> which is a template nameing each ICMP message and provides a space
> describing how to handle that ICMP message. The draft is a
> template because none of the descriptions are filled in. Back at the
> 44th (Minneapolis) I believe I recall the working group deciding that
> ICMP handling needed to get more specific befor closing the group. There
> was a call for volunteers to put in effort. I volunteered and here is a
> bit of effort.
> 
>         I have not followed Michael Richardson's draft (icmp-handle) in
> my 'initial thoughts' post. I find it more clear to ponder these out in
> terms of 'situational examples'. I hope (naively??) that my list of
> situations is complete. The goal would be to move from my situational
> format to filling in Michael's draft with the details per message rather
> than per situation.
> 
>         These are my initial thoughts. I am looking for feed back.
> 
> --
> 
> ####################################
> #  Ricky Charlet
> #       (510) 795-6903
> #       rcharlet@redcreek.com
> ####################################
begin:vcard 
n:Huttunen;Ari
tel;fax:+358-9-2992634
tel;work:+358-9-2992472
x-mozilla-html:FALSE
org:L M Ericsson;LMF/T/TK
version:2.1
email;internet:Ari.Huttunen@lmf.ericsson.se
title:Software Designer
adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland
x-mozilla-cpt:;-30024
fn:Ari Huttunen
end:vcard
Follow-Ups: References: