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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Wed, 10 Oct 2001 11:46:52 +1000

> Getting a new extension header is hardly a minor change. It needs
> _every_ IPv6 forwarding engine to be changed, thus affecting the
> ipv6 WG's scope. 
> 
	=> Huh ?? Are you saying routers have to be upgraded
	every time we have a new DST-option addressed to the
	end host ?
	Thats news to me.

> IMHO, people suggesting such a change should first
> go to ipv6 WG to get their opinion on the issue. For the record,
> I believe Francis bravely once already tried this - and, regrettably,
> got rejected.
> 
	=> Francis can speak for himself but I've *never* seen a
	proposal for this in IPng. Probably for a good reason. 
	Francis did propose rearranging all ext headers in general
	and that was not agreed on for reasons that have nothing to
	do with routers.

> If, despite long discussion, there might be a lack of a credible
> solution for AH, why not go ahead with an alternative? IMHO,
> 
	=> I agree, but twe haven't seen *any* criticism for the IPsec
	solution. The only point of difference was piggybacking. 

> people interested in AH should work out the details (see above)
> and come out with a separate description on how to solve the issue,
> without stalling the base draft.
> 
	=> The details are summarised in Jari's draft that is coming out
	soon. Regarding stalling the draft this is really not true to say
the
	least.  

	Hesham

---

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

>      every time we have a new DST-option addressed to the

I believe unknown next header (not discussing option) values "should" result
in the packet being discarded with an ICMP error, e.g., when finding such
in the next header field of the IPv6 header. OK, the RFC allows that there
may exist routers that do not drop the packet. Their forwarding engines do
not have (a moblity-aware) input path (no CN functionality) and they have
selectively implemented forwarding paths. Though yet unknown headers are
easy to attach to most router designs I have seen, their semantics may
need some work before the node can be said to truly support a new protocol.
Let's say that at least all CN-enabled hosts and routers following the
should-rule are affected, if a new header is needed for end host (CN)
mobility support.

>      and that was not agreed on for reasons that have nothing to

I believe his proposal also included a "nice-to-have" suggestion to
introduce a new header type for one of the options currently carried
in destination headers.

>      solution for AH..
>      soon. Regarding stalling the draft this is really not true to say the
>      least.

If that is the case, that would be good.

>      Hesham

-Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 17 Oct 2001 22:03:34 +0200

=> some remarks:
 - the change is a new final header, not an extension one (ie it will
   be always the last one) nor a destination option
 - no IPv6 forwarding engine needs to be changed, the only header
   processings are for the IPv6 header and for an optional hop-by-hop
   header (so it must be just after the IPv6 header and unique).
   The forwarding engine verifies the next header field is not zero,
   it should not check if it knows it (i.e. you have not to upgrade
   your router in order to support SCTP for instance).

=> my purpose was to clarify the different destination option header
stuff and to manage them in the advanced API. The conclusion was
the advanced API has to be fixed and RFC 2460 is near perfect (:-).
As some clarifications seem to be still useful my plan is to publish
a -01 version including the meeting decision.
BTW a consequence of my first remark is that we don't need to go
to the IPv6 WG in order to get the next header value.

Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Oct 2001 23:16:18 +0300 (EEST)

>    your router in order to support SCTP for instance).

True.

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.

Yesterday, I posted a related note to on ipng list with subject:
"Extension Header Capability Discovery needed?", which may be of interest.

-- 
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: Francis Dupont <[email-masked]>
Date: Wed, 17 Oct 2001 22:16:47 +0200

=> my idea was to clean up the 3 (at least :-) different positions
for destionation option headers. As the last (aka note 3) one is used
only for BU, BA and BR I proposed to get a new type for it.
But the proposal was for an extension header so it didn't address
the IPsec selector problem: to solve this issue the header must be
a final one, i.e. piggybacking must be killed.

BTW I have a question about Binding Requests: they have no strong
security requirements but to deal with them as BUs and BAs seems
to be simpler and without overhead (arguments: to put them in
the last destionation option header saves nothing (without piggybacking
consideration) and SAs should be there if BRs can be sent).

Regards

---

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

>         every time we have a new DST-option addressed to the

I was too categorical with this remark, the issue was discussed on
the list and a more refined view, I guess, emerged. I refered to headers,
in general, not options of current destination header type.

> the advanced API has to be fixed and RFC 2460 is near perfect (:-).

Sorry about being imprecise on the proposal, I attempted to refer only
to the discussion after your proposal where having new header types was
discussed, I remember (maybe incorrectly) Deering's comments on
not hearing good reasons now.

> to the IPv6 WG in order to get the next header value.

Hopefully this is the case. I would like just to remark it does affect
some nodes and having a conservative amount of change could be reasonable
when weighing alternatives. Even though new header would be mandatory,
and since mobility standardization lags after other IPv6, there will
be boxes not immediately knowing the new headers.

> [email-masked]

BR,

-Jari

---

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

> a final one, i.e. piggybacking must be killed.

I would like to ask a clarification: What happens if the sender omits
the upper layer (this also makes the packet non-piggybacked), doesn't
this expose any header to potentially be the last one? Wouldn't this
mean that with a new header type for one or more of the current destination
options one could introduce a policy of protecting exactly this signaling?
But, as said, using a well-known UDP port has been suggested as an
alternative.

Also on piggybacking, what would be the consequence, if, say, piggybacking
is not killed, but only disabled at sender when using IPsec?

> consideration) and SAs should be there if BRs can be sent).

Given the recent interest on DOS attacks, wouldn't insecure BRs also
help mounting these, even though BR has weaker requirements? Hence,
if they can be dealt the same way as BUs and BAs, wouldn't this be ok?

BR,

-Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Oct 2001 09:48:44 +0200

I would like to ask a clarification: What happens if the sender omits
   the upper layer (this also makes the packet non-piggybacked), doesn't
   this expose any header to potentially be the last one?

=> this is impossible because extension headers have a next header
field and you have to put something in it (and if you put "no next header"
then the last logical header is "no next header" :-).

   Wouldn't this

=> for a final header this is true (the selector problem comes from the
fact that by definition there is one and only one final header per packet
and a very variable number (zero to many) of extension headers).

=> UDP port 434? This is the cheap alternative to burn a next header value.

=> there are many reasons to kill piggybacking, IPsec incompability
is only one of them... And a new header (or a well-known UDP port)
doesn't work with piggybacking.

=> this is exactly what I think.

Thanks

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 18 Oct 2001 01:19:27 -0700

>    Also on piggybacking, what would be the consequence, if, say,
>    piggybacking is not killed, but only disabled at sender when
>    using IPsec?
> 

Rephrasing: if we mutually exclude IPsec and piggybacking, this would
also mean we use it only with the old style BU (not with the new header
nor UDP). For the "tight pipe" bandwidth reason, it seems like a broken
link whose general applicability to variable-length IP (e.g. browsing)
is questionable. If QoS cannot resolve this or such L2 cannot transparently
mask piggybacking, one could consider introducing a negotiation with a
"don't piggyback" bit in BAck. MN closer to the "tight pipe" when
receiving a BU would know when to discourage piggybacking. If the first
piggybacked BU packet would be so unfortunate as to be dropped at
the entrance to the "tight pipe", the sending MN would then not
piggyback on resends and then get the BAck with "don't piggyback".

What other significant reasons would there be to kill it?

BR,

-Jari