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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 18 Oct 2001 16:52:46 +1000

> >      If not strictly 2460, a legacy firewall may have implementation
> >      which lets packets with some unknown header go through, but it
> 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 ?
> 
> Even though SCTP would be allowed through, a new extension header may
> be problematic, 
> 
	=> This might be a thick question, but what's the difference ?
	Isn't SCTP a NEW header ? Why would that be allowed. 

> 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. 
> 
	=> I understand your logic but I can't see the difference between

	- an "unpiggybacked" BU with a new ext header and 
	- an SCTP payload.  
	Could you tell me why these two are different ?

	If you drop the former then you'd drop the latter ...right ?
	Sounds like a firewall that needs an upgrade. 

> This to motivate
> why some may have reservations letting any unknown headr thru. 
> 
	=> Ok, but so far I heard this from you only :) 
	If more people see this problem then I'm glad you brought
	it up so we can clarify it. 

> 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.
> 
	=> Again I have no problem with using UDP either, but 
	for very different reasons. 

	Hesham

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 18 Oct 2001 00:13:48 -0700

Hesham,

>      Could you tell me why these two are different ?

If protecting boxes "inside" one might want to be sure unknown protocols
passed through are end headers as compared to allowing any (arbitrary)
protocols through. SCTP: end header, "unpiggybacked" BU: ok as long it
is impossible to make a box "inside" also accept it with piggybacking.
Hence a BU with a new header may be more dangerous depending on how it
is specified/implemented (you may send it unpiggybacked, the attacker
tries with piggybacking).

>      Hesham

-Jari

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Oct 2001 10:40:12 +0300 (EEST)

> 	Sounds like a firewall that needs an upgrade. 

The difference is significant.  Perhaps I can help to clarify the 
situation.

 SCTP header would be like:

  IPv6 HDR - SCTP header

 BU with new Ext Header would be like (if I get this right):

  IPv6 HDR - UnknownHeaderBU - TCP/UDP/... header
 
Now consider a firewall filtering traffic.  It may have rules like:

 [...]
 allow proto tcp from any to any established
 allow proto tcp from any to any dst port 22
 deny  proto tcp from any to any

Furthermore, a first rule could be 'allow proto sctp from any to any'
(note: the firewall does not need to know anything about SCTP, just the
protocol number) but that's not necessary.

With UnknownHeaderBU, the real payload is TCP and should be subjected to
firewall's _TCP_ filtering rules, but it cannot.  If the firewall cannot
parse the header, the packet would pass only if:

 - UnknownHeaderBU is explicitly allowed
 - default is to allow all

But in this case, the security could be penetrated as one cannot perform 
the TCP/UDP/... checks for the headers after the unknown header.

With SCTP, the firewall administrator _can_ make a _conscious_ decision to
pass SCTP protocol through (as there are no unknowns before it!),
thinking "those people can protect themselves".

I intend to write an I-D on these issues one of these days...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Oct 2001 13:48:35 +0300

> The difference is significant.  Perhaps I can help to clarify the 

I would like to point out of few things:

1) We propably shouldn't discuss the combination
    of a new header and piggybacking. If we keep
    piggybacking, we can pretty much live with
    the current DO model.

2) Pekka's analysis of the differences between
    BUs and SCTP is correct, but it assumes that
    a priori knowledge of the nature of the BU
    and the SCTP. I.e., they are different because
    Pekka believes one is certain to not be followed
    by more payloads, and the other one is not.
    A router that receives a packet with an unknown
    protocol number has no such knowledge! So it
    can't know all is well even for SCTP.

3) We should propably give some thought not just
    for how the BUs and their MACs are carried, but
    also for how the "weak" authentication protocols
    are carried. Some of these protocols suggest public
    key crypto operations, some protocols might be
    broken in the future and new ones developed.
    Does this point to the direction of UDP ports?
    Maybe, maybe not. Discussion would be helpful
    also on this issue. And should the BUs+MACs be
    carried in the same protocol as e.g. BAKE or
    SUCV? Or in a different protocol? Current
    proposals all seem to be BU suboptions...

Jari

---

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

=> a minor point: a new extension header has no benefit,
the proposal should be a new final/payload/... header
(and has no difference with SCTP).

=> UDP is a valid alternative, this is just a trade-off between
to involve IANA (easy according to our area director) and to reuse
Mobile IPv4 way. Personally I prefer a new final header but I can
live with UDP.

Thanks

[email-masked]

PS: it seems we have to wait the face-to-face meeting in order to
choose between all options, doesn't it?

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Oct 2001 21:02:45 +0300 (EEST)

>     can't know all is well even for SCTP.

The router could have a list of known payload headers, which it knows are 
always final, but doesn't have an idea how to process.

So identification is at least theoretically possible (to some extent), but 
not so probable.