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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 18 Oct 2001 15:42:34 +1000

> >      => 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.
> 
> 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.
> 
	=> Ok, so what would these "old" firewalls do about SCTP ?

> >      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.
> 
> Actually, it might be good to look at all the complexity
> this may introduce.
> 
	=> Are you referring to the IANA process ? I guess
	you're referring to your earlier statement about firewalls.
	If so my answer above applies. 
>  
> >      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.
> 
	=> I don't have a problem with the UDP solution either.

	Hesham

---

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

Hesham,

>      which lets packets with some unknown header go through, but it depends

Even though SCTP would be allowed through, a new extension header may
be problematic, if it just very straightforwardly re-uses dst.hdr logic
at end points, as I understood you were suggesting.

Suppose the following: A firewall simply lets a new header with some
protocol number through. Entering an empty header to a packet sent to
the header-aware end node would let the rest of the packet pass unchecked.
That is, if the firewall has filtering rules, e.g., TCP port -based,
it can no longer enforce these since not scanning past the unknown
header. If the receiver inside the corporate network scans past the
empty header, any new-header -aware node inside would be wide open
since the sender could then just add the upper layer such as TCP.
Hence, in case of a new header type, also the receiver MUST enforce
not to allow piggybacking with it, adding a bit of complexity.

Even while disallowing piggybacking, any unknown header can be used
to set up an open channel between cooperating nodes. This to motivate
why some may have reservations letting any unknown headr thru. Hence,
with a known header type, such as with the UDP port alternative, all
firewalls can more precisely be configured to let only signaling go
through.

>      => Are you referring to the IANA process ?

It would be good to know implementation complexities of each solution
to help choosing one (my remark above).

> Then, the UDP, though a bit artificial, does not seem very complex.
> 

-Jari