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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 18 Oct 2001 14:37:12 +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 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. 
> 
	=> Jari, it is fairly simple to configure the firewall to pass
certain
	header numbers. If an implementor/adminstrator chooses not 
	to do so then they are effectively choosing not to support 
	mobility. Just like  an implementor may choose not to
	support the BU at all.
	The same issue appears with new transport protocol 
	headers. 

> 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.
> 
	=> There are alternatives, people also suggested reserving
	a UDP port. 

> 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,
> 
	=> Yes, just like a CN that does not support route opt at all.

> 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?
> 
	=> Well, if we choose to have a new header number, we can
	simply copy the current header and just give it a new
	number. It becomes an IANA issue really. 
	I'm obviously only considering the issue of getting a 
	new ext header as I understood your question. 

	Also let's not forget the scond option: A UDP port.

	Hesham

---

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

Hesham,

>      filter that does not wish to implement the hdr has hard time scanning
>      box does not know this when not implementing the header.
> 
>      => Jari, it is fairly simple to configure the firewall to pass certain

If not strictly 2460, a legacy firewall may have implementation
which lets packets with some unknown header go through, but this depends
really what one means by support; knowing it is an end header that can
safely be let through and having the possiblity and willingness to
configure letting this header through can be called filtering support
for the new header. I am not sure this support is always there.

>      => There are alternatives, people also suggested reserving

Actually, from the other dimension of alternatives you refer to here,
the UDP could be a better one than a new header; it can be known to be
supported also by all old and new firewalls, and even by all end nodes.

>      above. Secondly, an end node (CN) may send an ICMP or just drop the packet.

Actually, it might be good to look at all the complexity
this may introduce.
 
>      Also let's not forget the scond option: A UDP port.

I agree with this one, with new hdr, implementations need to have protocol
switches to two headers. And while one accepts all destination options,
another does not accept the same set of options, introducing some
extra logic. Then, the UDP, though a bit artificial, does not seem
very complex.

>      Hesham

-Jari

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Oct 2001 08:36:26 -0700 (PDT)

Jari T. Malinen writes:
 > really what one means by support; 

   I think that the legacy firewall is going to
   choke on the 0110 in the version field :-)
  
 > knowing it is an end header that can

   Jari,

   What you are in effect pointing out is a tautology:
   end to end suffers when there are L3 non-transparent
   boxes in the middle. This is true of all firewalls,
   and most especially application layer gateways and
   their NAT henchmen. There is really nothing we can
   do about this because the IP architecture make no
   such assumptions about translucent middle boxes. I
   would suggest that people who use these things have
   already made their deal with the devil, and that 
   it's really their problem to sort it out. If we
   want to embrace this kind of architecture, this is
   the tiniest tip of the iceberg; for starters, IP
   is a lousy architecture for an intelligent network.

 > supported also by all old and new firewalls, and even by all end nodes.

   I'm sort of in favor of UDP mainly because I'm
   parsimonious about doling out new protocol numbers.
   Also, UDP inherits checksums and ECN, along with
   the advantages you point out.

		      Mike