Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 18 Oct 2001 13:17:27 +1000

> >      But the sending node will have to know that the destination will
> >      support this new header, else the packet is discarded.
> > 
> >      Especially if destination is CN, this may or may not be possible.
> > 
> >      => Agreed. Hence the need for a standard !
> >      The Home Address option MUST be supported by
> >      all IPv6 nodes. This solves your concerns.
> >      The BU option and potentially the new ext header
> >      SHOULD be supported .... voila.
> 
> If both BU and the new header are optional, header type of BU
> is recognized, that of the new header is not. Filtering forwarders
> not knowing these options will possibly let the BU go through (knowing
> at least the destination header type), but they do not know the new
> header, most likely dropping it. This may be a problem.
> 
	=> The point raised by Pekka was reagarding the understanding 
	of headers e2e. How intemediate filters treat the headers is a
separate
	issue. However to answer your question, filters can typically 
	be configured to let / stop cetain ext headers from passing 
	through.
	I'm guessing that's what you mean by "filtering forwarders"
	or do you just mean "routers" ?
	If you mean routers, then I think it's quite clear now that
	they don't need to be aware of these new headers.

	Whether the new ext header is optional or not, has not
	been discussed. 

	Hesham

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 17 Oct 2001 21:27:12 -0700

> "Hesham Soliman (EPA)" wrote:
> 
>      of headers e2e. How intemediate filters treat the headers is a separate

I was considering the issue of filters, where following 2460, having a
filter that does not wish to implement the header has hard time scanning
past it. There are headers with different length field semantics, even
though we would define it to follow that of the destination header, the box
does not know this when not implementing the header. Hence, I am not sure
it is as simple as configure it to ignore it; it most likely drops the
packet with no alternative to this.

>      Whether the new ext header is optional or not, has not

So let us discuss.. The optionality may be what one can hope in practice,
however leaving a new header optional may lead to the problem described
above. Secondly, an end node (CN) may send an ICMP or just drop the packet.
I guess these cases all can fall back to non-route optimized traffic,
but many CNs may end up being without route optimization.
A second question is the complexity of having a new header and the old BU,
is this a problem?

>      Hesham

-Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Oct 2001 14:17:40 +0200

it most likely drops the packet with no alternative to this.

=> I don't believe that firewall vendors are so silly they don't
provide an extension hook for filtering of new next header/protocols...
or do you argue that SCTP is unusable because 132 is new in tables?

=> it should send an ICMP. Both an unknown option or an unknown header
should give ICMPs.

=> I can't see a difference between options and headers for that.

=> complexity is always a problem. I'd like to get only the more general
solution. BTW the IPsec issue doesn't apply only end-to-end, i.e.
a security gateway can get the same kind of problem if it is used
with a fine granularity.

Regards

[email-masked]