Subject: [mobile-ip] list of things for MIPv6

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Dec 2001 10:41:29 -0800

hi everybody,

heres an attempt to list all the issues that need to be
resolved so that Mobile IPv6 can move ahead. and some
suggestions follow them.

-----------------------------------

1. Mobile IPv6 use of Routing Header
        It has been identified that reflector attacks are
        possible with MIPv6 use of routing header. There is
        also a solution for this. If the host processing
        the routing header performs a simple rule of 
        'check if the destination address and the next address
        to be swapped in both belong to the same interface 
        of the node', before processing the routing header,
        we eliminate this threat caused by MIPv6.

2. Mobile IPv6 use of Home Address Option
        The threat in this case is that some trivial source 
        spoofing attacks are possible. The answer to source 
        spoofing has always been smart ingress filtering. 
        its the same in this case too. Using a tunneling 
        approach does not it solve it either. So we have 
        two options
        a. Document this threat in Mobile IPv6 security 
           considerations and leave it.
        b. Solve it by mandating that home address option 
           is not processed unless there is a corresponding 
           binding cache entry (of course created securely). 
           use reverse tuneling through the home agent when 
           a binding cache entry does not exist.

        in my opinion, lets go with (a). (b) is a really bad 
        idea. (b) is too drastic. I can live (a) becase the 
	threat is very insignificant. Source spoofing attacks 
	are possible currently (in the current internet). if 
	the bottom line is 'do no harm' lets go with (a).

3. Protecting the BU. There are three options. pick one. 
        a. new extension header
        b. Authentication Sub-Option only.
        c. Jari Arkko's draft, option 4 which shows how 
           authentication suboption and AH can be used 
           together with minimal changes.

        if we decide to go with (a), lets not go with UDP. 
        instead we should use a new extension header. 
        I personally prefer option (c). Implementing the
        auth suboption is very easy. I can provide the code
        if people think it is complicated to implement.

4. Piggybacking
        Phil described various options in his presentation 
	at Salt Lake City. lets pick one.
        a. lets leave it as it is. it is a 'MAY'.
        b. leave it as it is, but recommend when it is
           good to use and when it is bad to use. 

5. Key Distribution protocol between MN and CN
        a. Return routability vs CGA (Cryptographically 
           Generated Addrs)
        b. Binding Security Association

        for (a), lets go with return routability unless 
	somebody can prove that it is insecure. The added 
	complexity of CGA or Diffie Helman operations is 
	not worth it. no additional gain. so lets go with 
	simple return routability.

        for (b), I am not sure.         

------------------------------------

Lets try to address these issues one by one. And once we 
are done with an issue, we dont visit it again.

It would be good if everybody woud reply to this mail and 
voice their opinions. Once we close an issue we dont want 
people coming back later on saying that they dont agree 
with the conclusions reached. Maybe the WG chairs can 
decide on the concensus. 

Regards
Vijay

---

From: "James Kempf" <[email-masked]>
Date: Thu, 20 Dec 2001 11:00:49 -0800

Vijay,

> simple return routability.

It was not clear to me from the discussion in SLC that
there is any additional decrease in complexity 
over CGA for return routability, if public keys were used
to secure the RR messaging. Clearly, for symmetric
keying, there would be, but that would require a
trust relationship to be set up, which would
require an initial public key exchange/operation
to secure the key distribution.

I believe Gab was going to generate some kind
of analysis of the cost of return routability with
Diffie-Helman compared to CGA?

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Dec 2001 11:19:17 -0800

Gabriel,

> Diffie-Helman compared to CGA?

If this is true, can you do this as soon as possible?
if you are too busy, would you trust somebody else to
do it?

Vijay

---

From: Henrik Petander <[email-masked]>
Date: Fri, 21 Dec 2001 11:27:55 +0200 (EET)

Hi Vijay,

> resolved so that Mobile IPv6 can move ahead. and some

This requirement would make vertical handoffs impossible for mobile hosts.
Wouldn't it be sufficient for the host to check that the next address
belongs to it and that the scope of the next address is not smaller than
that of the destination address? This would stop reflector attacks, and
allow MN to perform vertical handoffs.

Regards,

Henrik
		----------------------------------
		Henrik Petander 		
		Helsinki University of Technology,	
		GO/Core Project 
		[email-masked]
		Office: +358 (0)9 451 5846 
		GSM: +358 (0)40 741 5248	
		----------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Dec 2001 13:05:28 +0200 (EET)

> allow MN to perform vertical handoffs.

An alternative mechanism here would be basically "check that the next 
address is a Home Address of the node".  This depends more on the 
implementation though.

-- 
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: Pekka Savola <[email-masked]>
Date: Fri, 21 Dec 2001 13:16:57 +0200 (EET)

> 	the bottom line is 'do no harm' lets go with (a).

This is the "easy way out".

Your argument about source spoofing does not apply; it's certainly 
possible currently, but there are scenarios (which, unfortunately, I 
appear to have forgot to add in my rh-ha-draft) you can protect against 
without it:

          host1 --- fwrtr1 - rtrISP - Internet - fwrtr2 ---host2
                3ffe:ffff:1::/48            3ffe:ffff:2::/48

Let's assume fwrtr2 is protecting host2 by filtering out all packets the 
source address of which belongs to the local network, like:

deny ip from 3ffe:ffff:1::/48 to any interface from_internet

Now, the attacker host1 could attack:

src = 3ffe:ffff:1::1 (or spoofed if no filtering in fwrtr1, as assumed)
dst = 3ffe:ffff:2::1
 hoa=3ffe:ffff:2::2

The firewall cannot block this, and packets from internal source address 
3ffe:ffff:2::2 can end up in the host2's stack.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Dec 2001 13:29:09 +0200 (EET)

> deny ip from 3ffe:ffff:1::/48 to any interface from_internet
                         ^ 
3ffe:ffff:2::/48, of course!  sorry..

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 15:39:41 +0100

=> the solution has to be written down in a draft and presented
to the IPv6 WG ASAP as a part of the host requirement document.

=> it seems I have to write the IPv6 ingress filtering document
(it is in my TODO list, I'll check with my co-author when we
can write it).

           its the same in this case too. Using a tunneling 
           approach does not it solve it either.

=> tunneling has exactly the same problem (and solution): no miracle
even next Tuesday (:-).

           So we have two options
   
           in my opinion, lets go with (a). (b) is a really bad 
           idea. (b) is too drastic. I can live (a) because the 

=> you already know I agree!

=> I shan't use the argument. The threat is real and we have
to give back the tools against it. The limits of these tools
are simply not in our scope.

=> argh! Which draft/section/etc?

=> I am in favor of (a) because it works without the need
to check if there is some IPsec somewhere. As IPsec codes
are a bit complex (:-) and have strange (:-) interactions
with other parts of stacks, IMHO this is a strong argument.

   4. Piggybacking

=> I presented a generalized version (the IPv6 payload header)
of this at an IPv6 session at SLC. I had to specify that my purpose
was to collect pros & cons, not to really defend the idea,
in order to not be hung with the micro cord... I should release
a new version of the I-D with a lot of cons soon (i.e. before
next IETF).

=> (b) with good to use == never and bad to use == always!

           for (a), lets go with return routability unless 
   	somebody can prove that it is insecure.

=> very easy: put the attacker in the CN default router.

        The added 
   
=> I am afraid that if we do that all CNs will simply reject
BSA establishment attempts. Of course if BSA establishments
are very expensive (a lot of crypto operations) we'll get the
same result. Here we really need a miracle!

           for (b), I am not sure.         
   
=> explain a bit more the (b) issue.

   It would be good if everybody woud reply to this mail and 
   voice their opinions. Once we close an issue we dont want 
   people coming back later on saying that they dont agree 
   with the conclusions reached.

=> hum, perhaps this will work but IMHO this should take months!

   Maybe the WG chairs can decide on the concensus. 
   
=> WG chair job is harder and harder (:-)...

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 15:48:29 +0100

=> it seems that a Diffie-Hellman and a public key operation
have similar costs (too high according to Vijay).

Regards

PS: my concern about CGAs is IPRs by Ericsson and Microsoft.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Dec 2001 09:47:36 -0800

> allow MN to perform vertical handoffs.

Fine with me....

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Dec 2001 10:17:59 -0800

Hi Francis,

> => you already know I agree!

I wish everybody would. it would great if implementors are
given more importance in this WG. then we could have our way.

> => argh! Which draft/section/etc?

draft-arkko-mipv6-bu-security-01.txt, section 6.4. 

> => explain a bit more the (b) issue.

the issue is with the creation of BSAs. do you need the key 
distribution protocol to create BSAs? for example both BU3WAY 
and BAKE use return routability. but BAKE creates a BSA, whereas 
BU3WAY does not. BU3WAY is run everytime the MN sends a BU 
to the CN. There are a few arguments for not creating a BSA 
in Erik Nordmark's draft.

> => hum, perhaps this will work but IMHO this should take months!

I am thinking of closing issues 1-4 in a matter of few weeks.
agreed that 5 will take longer. but it should be doable by
Minneapolis IETF. (being optimistic as always...)

Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Dec 2001 10:42:18 -0800

Hello Francis,

> to the IPv6 WG ASAP as a part of the host requirement document.

The solution depends on the application.  For Mobile IPv6, the solution
is trivial, as has been suggested many times by me and other people.
I can imagine uses of the routing header that would be set up by
security-conscious people who demand certain routability.  I believe
that the IPv6 working group CANNOT predict all the necessary policy
mechanisms to check the correctness of such esoteric uses of the
routing header.

BTW, the current draft does NOT restrict such enhanced capabilities
from the routing header.  It just demands that any existing sequence
of intermediate nodes should be kept as is except that the care-of
address is to be inserted before the home address in the source route.

> (it is in my TODO list, I'll check with my co-author when we

This sounds like a real piece of hard work.  Can you give a preview
of what you have in mind?  Are you looking for co-masochists?

> => you already know I agree!

I wholeheartedly agree with this approach.  I hope we can get
consensus on it soon and move forward.

> are simply not in our scope.

I agree that there is a real threat.  I don't think it's huge, and
I do think there are tools that we can build to protect against it.
I also think that the threat posed by additional delay of Mobile IPv6
is larger than the threat posed by this source-spoofing attack.

> with other parts of stacks, IMHO this is a strong argument.

I'm not so enthusiastic about (a), because I know it's a pile
of work to do it.  On the other hand, in the abstract without
consideration of wearing out my keyboard, I would be happy to
support it in hopes of getting closure towards getting the draft
through working-group Last Call.

> a new version of the I-D with a lot of cons soon (i.e. before

In previous e-mail, I have pointed out why arguments for the
generalized IPv6 payload header are different than the arguments
for including Binding Update as an option within a stream of
data.  Briefly, it has to do with the timeliness of the control
messages and the naturalness of inclusion along with the data.

> => (b) with good to use == never and bad to use == always!

This isn't right.  It's almost always good to use, because it
almost always offers a performance improvement.  There are times
when the performance improvement could make the difference in
even the feasibility of smooth voice handovers, due to the
decrease in jitter (as was pointed out in work from Cedric Westphal).
There is practically zero downside for the receiver.  The downside
at the sender is that it takes more code.  Arguments about channel
sizing and dropping outsized packets apply only to systems with
broken IPv6 implementations.  Every IPv6 implementation is mandated
to be able to deliver such packets.

So I strongly suggest that we _allow_ platforms to be built that
offer the better performance, without by any means mandating that
such piggybacking MUST be done by the sender.

> => very easy: put the attacker in the CN default router.

This is not "easy", and furthermore to prevent such an attack
would take a LOT more mandated protocol than is likely to be
promoted as part of any realistic solution.  I reckon that
compromising the default router is one of the worst things
that could happen at any enterprise, and afterwards nobody
will give a rat's patootie about what happened to Mobile IPv6.

> same result. Here we really need a miracle!

No, but we could use less hysteria.  I would suggest that we
build and test some of the proposed approaches, and carry out
some reasoned discussion after we have more experience.  This
whole argument is sounding to me about how insane it would be
to use your credit card over the Internet.  As it turns out,
life is not so horrible after all.

Regards,
Charlie P.

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 21 Dec 2001 21:18:38 +0200

> 1. Mobile IPv6 use of Routing Header

Agree that a rule is needed, and expect the rule to be
sufficient. Need to work on exactly what the rule is, though.

> the bottom line is 'do no harm' lets go with (a).

I believe there is a real difference in current spoofing
attacks compared to the ones enabled by the home
address option. Namely, ingress filtering or other techniques
can prevent source address spoofing but I can't see how
they could prevent HAO spoofing.

However, regarding the exact strength of the attack opened
through this whole I think the jury is still out. We had a discussion
with Erik and Gabriel about trying to classify the threat in some
sort of a 'Richter scale'. For instance, this attack seems to evade
all known automatic tracing and detection techniques unlike e.g.
typical TCP SYN attacks, but on the other hand it does not
produce any packet amplification. Still, it could be used as a
part of a DDoS to hide client locations.

My preliminary answer here would be (b) unless we
can think of something else, or a believable reason why
the attack isn't serious enough.

>            together with minimal changes.

I'd like to see this as two separate issues, actually. The
first issue is whether PKI and RR/CGA-based authentication
are *alternatives* of which exactly one is used for one packet,
or whether they are complementary, possibly used together.
On this first question I have lately come to the conclusion
that I'd prefer them to be possibly used together. This is
because the methods prove different things. CGA e.g.
proves address ownership while PKI proves you belong to
the group of good guys. You might want the other one too,
even if you already did one.

The second issue is which protocol actually protects the
BUs. Here my preferences are options 6.2 or 6.4 from my
draft. (I seem to recall that we had some consensus in
SLC about using rather a new protocol or UDP than IPv6
DOs... if so, then 6.2 would be clearly possible as well).

>         b. Binding Security Association

First of all, I think the main alternatives are either pure
RR without D-H or RR+D-H+CGA. The reason for this
is that if you end up doing bignum math in D-H you might as well
get the full protection with CGA at the same time.

Secondly, for the performance concerns, I believe we can rule out
effects to small mobiles, given that there exists crypto offload
mechanisms (see CAM-DH) that can take care of this. Servers
and HAs, on the other hand, may have more of an issue but there
are otoh lots of crypto hardware accelerators available, if a server
wants to do RO with a large number of clients. I believe Gab intended
to post some performance information to the list.

Thirdly, there seems to be some differences in the security
strength of RR vs CGA. There even seems to be some differences
in v4 security vs. MIPv6 + RR. Whether these are significant, 
needs to be discussed. I intend to write something about this
to the list -- but after christmas. My personal preference is
D-H+CGA, because it's the only solution that truly proves address
ownership.

Fourth, recent discussion in the list under the "Risks of not verifying
the care-of address" seem to have concluded that in order to
avoid the 3rd party bombing attacks, we need to verify CoA RR
not just once, but on every movement. To me, this implies that
if we use just RR, then we may not find BSAs very useful (and hence
all the discussion IPsec vs. -14 is moot). On the other hand, if CGA
is used then there's a clear advantage to BSAs still since the bignum
math can be done just once, while RR and some symmetric crypto
is still done on every movement. So, RR => no BSA, CGA => BSA.

Fifth, we need also some further decisions, such as whether to
do an RR test  to CoA as well as the HoA (I think we do), and some
DoS resistance tricks (e.g. puzzles vs. RR at the bottom of CGA, I believe
RR is a better choice for this), and possibly some others.

Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Dec 2001 13:11:46 -0800

> they could prevent HAO spoofing.

Ingress filtering could put some restriction on this.
For instance, it could be enforced that only one home
address could be associated to a particular care-of address.
This would eliminate most of the "fun" that would be
associated with such spoofing.  We could also say that
a correspondent node has to do such filtering.  After
these two measures are taken, I think that no self-respecting
bad guy would waste time on such a low-payoff exploit.

>>            a binding cache entry does not exist.
           ..........
> the attack isn't serious enough.

(b) is a pretty heavy thing to mandate, especially if you agree
with my comments above after the previously cited paragraph.
Perhaps we could say "SHOULD" verify the feasibility of the
Home Address Option by some means, possibly including existence
of a Binding Security Association (BSA).  And then busily make
such a protocol for establilshing BSAs viable (work which I
reckon is currently going on).

At least in this way we could make progress without handicapping
all future implementations.

> even if you already did one.

I agree that they do different things, and that they both
do good things, but I can't see mandating CGA, for all of the
reasons that have been mentioned elsewhere.

> DOs... if so, then 6.2 would be clearly possible as well).

I don't recall that there was consensus gauged about
anything, except _very briefly_ whether people would like
to see a new header type for Mobile IPv6 messaging.
I was a bit disconcerted that the call for consensus was
taken without any discussion on the issues, but even so
the results have to be taken into account.

Supposing we had a new header type.  Wouldn't it be
appropriate to make the necessary signaling for protecting
Binding Updates to also fit in the same container?

I'll have to postpone discussion on your other points about
CGA ==> BSA until later...

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: 22 Dec 2001 10:51:07 +0100

"Charles E. Perkins" <[email-masked]> writes:
> some reasoned discussion after we have more experience.

Anyone wishing to play today with a return routability implementation,
please consider MIPL archives: there's a patch for 0.8.1 that
establishes an MN-CN key with BAKE.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 16:03:34 +0100

Your argument about source spoofing does not apply; ...

   

=> you say you have a source spoofing attack when the source firewall
doesn't filter anything. I have not to read further in order to say
you should be right and you add nothing to the debate...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 16:34:27 +0100

=> I am still in favor of (a) because (a) really gives the choice
between using Mobile IPv6 (aka application) specific stuff or
plain IPsec. This is related to piggy-packing too (and I am strongly
opposed to it).

   
=> first I believe that in some circumstances BAs have to be secured too.
As I believe the return routability itself is not enough secure there
is no advantage to have an ultra light weight scheme, i.e. to create
a BSA should be paid off by possible reuse.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 17:17:29 +0100

> to the IPv6 WG ASAP as a part of the host requirement document.
   
   The solution depends on the application.

=> I agree but today the general problem is known so we have to both
fix the general case (even with drastic statements like by default
hosts should drop packets with routing headers with segleft != 0)
and specify the Mobile IPv6 solution.

=> the specs should keep a open door for new usages but now
the open door is for attacks and the priority is there.

   This sounds like a real piece of hard work.  Can you give a preview
   of what you have in mind?

=> explain DDoS and iDDoS threats, how ingress filtering is a reply
to DDoS, how smart ingress filtering (ingress filtering + responsible
usage of the network + access control extension) is a reply to iDDoS.

   Are you looking for co-masochists?
   
=> no, I should have written this document with Claude Castelluccia
(the whole thing is not new for us) at the beginning of this year...

   of work to do it.

=> no, this is just a statement in the IANA section.

   >(piggy-backing)

=> all these arguments still apply if this is done by the link-layer.
IMHO this is a typical case of mobility = wireless confusion.

   > => very easy: put the attacker in the CN default router.
   
   This is not "easy"

=> I disagree: the formal proof (of insecurity) is easy.

   and furthermore to prevent such an attack
   
=> we are talking about formal proofs... at least, this is what
I understood from Vijay's question.

   > same result. Here we really need a miracle!
   
   No, but we could use less hysteria.

=> the real issue is we don't know what can be accepted by the market
between cheap & not secure and expensive & very secure. Obviously
there is a balance and to strike it seems to be hard.

   I would suggest that we build and test some of the proposed
   approaches, and carry out some reasoned discussion after we have
   more experience.

=> IPsec/IKE was built and tested, so we have already a point in
one side of the spectrum (too far from the middle according to the IESG).

   This whole argument is sounding to me about how insane it would be
   to use your credit card over the Internet.

=> I agree this is more FUD than a real problem. But we have to take
care of possible FUD against Mobile IPv6... unfortunately not since today.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 17:52:24 +0100

=> it seems the only real consensus is we have none (:-).

=> yes of course, same for binding acknowledgements.
I don't know about binding requests but as this costs nothing
(in fact this can remove some complexity) I am in favor
to get a new terminal header type in order to put the whole Mobile IPv6
signaling, including dedicated security, in it.
   
Regards

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 22 Dec 2001 10:05:17 -0800

Hello Francis,

I reckon we're not too far from agreement.  Comments below:

>                .............

> => no, this is just a statement in the IANA section.

I wish.  No, I (as editor) would have to specify the exact placement,
and interactions with possibly every other IPv6 header type.
Plus who knows what other interactions will rear their ugly faces
just at the last minute when we thought we had finally made it
through Last Call...?!

> IMHO this is a typical case of mobility = wireless confusion.

But it's not.  The point of my statement about this, is that sending
the control signal along with the data is very helpful as noted.
The link-layer cannot distinguish between control and data.
And we aren't supposed to be in the business of favoring those
distinguished link-layers that know a lot about bundling packets.

Furthermore, I will claim that I am usually pretty aware of the
distinction between mobility and wireless, but hey nobody's perfect.

> => I disagree: the formal proof (of insecurity) is easy.

An easy proof is not the same as a worrisome threat.

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 Dec 2001 20:13:22 +0200 (EET)

> you should be right and you add nothing to the debate...

fwrtr1 is irrelevant in this scenario; it's all about what fwrtr2 can be 
trusted to do.

Without HAO, destination site can still protect from the attackers
spoofing the source as one of the destination site's internal addresses.  

With HAO this filtering, which you _can_ rely on, is nullified unless 
firewalls keep state of the bindings (or somehow know enough of them).

A relevant threat, as those addresses could be viewed to be more trusted
than most addresses in the internet.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 19:47:13 +0100

=> me too.

   No, I (as editor) would have to specify the exact placement,
   and interactions with possibly every other IPv6 header type.

=> terminal (simple, no interaction).

=> same answer.

=> there are tons of reasons showing this is a bad idea.
In general control and data need different policies for something
(security (so IPsec issue), QoS, etc) and this is hard to apply
two different policies to the same packet. Just put them
in the same frame (-:)?

=> make it more clever, i.e. recognize binding update in the "to be
transmit" queue and put them in front of the "next to go" frame
(but see the PostScriptum).

=> but very slow or very fast link-layers for different reasons
can take benefit from a knowledge of what is in packets.
I agree I don't want to open door to backones with routers look at
inside my packets (they need the length only in order to aggregate
packets into super-frames) but I am not against not-dumb first/last
slow link-layers.

=> you should recognize piggy-backing is less useful on an Ethernet
or a 802.11b/802.11a. I consider piggy-backing as an over-optimization
(as RSVP in fact) in most cases, i.e. this really makes sense with
some link-layers which are very hard (i.e. too expensive) to improve
(this is the case of mobile phone in Europe, nobody wants to buy
a second license in some countries just to get more bandwidth :-).

Regards

PS: the netcontrol class selector is still defined. If someone uses it
in order to prioritize (?) BUs and if the link-layer knows class selectors,
this will be better than piggy-backing: BUs will be delivered ASAP without
waiting for the end of long frames. Aggressive link-layers can even
cancel a long transmission in favor of a BU...
(note I consider there is important to deliver BUs ASAP which is the case
for home registration, piggy-backing is essentielly a slow down mechanism
because it waits for something into piggy-back... My IPv6 payload header
was smarter because it was designed in order to compress the "to be transmit"
queue, i.e. it was always more efficient)

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 19:58:27 +0100

=> fwrtr1 is the place where smart ingress filtering can be done.
Without it, the job of fwrtr2 is far more difficult. And look at
my conclusion.

=> this is trivial anti-spoofing.

=> I agree: the protection of the home domain needs to know the home
registrations, by BU/BA spoofing and/or with HA collaboration.

=> usually the potential home addresses are known so it is possible to
give them less trust than for local addresses of fixed nodes.

But I prefer to rely on smart ingress filtering because if you have
no ingress filtering you have no good reply to ordinary DDos, i.e.
this is a question of are you dead or more dead (:-)?

Regards

PS: if we continue this discussion, can you put the whole scenario
in order to be understable (not only boring :-) for others?

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 22 Dec 2001 21:38:41 +0200

> bad guy would waste time on such a low-payoff exploit.

Well, to me this seems to depend on how the CoAs are
assigned.  If the MN is allowed to use stateless autoconfiguration,
it can generate a few thousand different CoAs for itself,
and use each CoA separately to send different home addresses
in the Home Address Option.  Ingress filtering wouldn't
notice this, each packet just would seem to originate
from a different host.  In an ethernet like network it is
even possible to use a different MAC address each time.

--Pekka Nikander

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 Dec 2001 22:00:13 +0200 (EET)

> Without it, the job of fwrtr2 is far more difficult. And look at

fwrtr2 can only protect what it knows, that is, the local site not being 
spoofed.

But as that is the only filtering you can _rely on_ (there might not be 
smart ingress filtering at fwrtr1!), it MUST NOT be compromised.

> => this is trivial anti-spoofing.

It is trivial, but vital.

> registrations, by BU/BA spoofing and/or with HA collaboration.

I disagree with your conclusion.  I didn't say "it's ok to drop this issue
and require the firewall know the registrations".  I think I know my 
opinion about the subject already :-).

And even if we did this, it would not help.  The firewalls of sites where 
CN's are (perhaps not wanting _anything_ to do with MIPv6) would have to 
have these mappings as well, not just home domains.

The reality might be that:
 1) those that don't care or understand the problems pass this through
 2) some (perhaps even most) home domains implement what you suggest
 3) the rest of home domains and probably about all CN sites (people who 
care) drop all packets with HOA.

> this is a question of are you dead or more dead (:-)?

Ingress filtering requires it is done at the source.  This is not always 
done.  Every site should implement egress filtering -- it's for their own 
safety even if they couldn't care for others'.

> in order to be understable (not only boring :-) for others?

I'm not sure how to make it clearer.

I've added this to my draft:

http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-rh-ha-security-01bis.txt

The only changes are in section 3.1 "The Source Address Spoofing Problem"

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Dec 2001 15:38:32 +0100

in the Home Address Option.

=> this behavior is so different than standard MN's one that
the ingress filtering should block it.

   Ingress filtering wouldn't notice this, each packet just would seem
   to originate from a different host.

=> I don't understand your argument.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Dec 2001 15:46:29 +0100

=> this is why there is something to do (next answer(s)).

   
   
=> you are talking about spoofing of local addresses. For a CN which
is not in the home or the visited domain, a HAO makes no difference.

=> (3) is exactly what we don't want.

   done.

=> we can't enforce it but this is not our role too.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Dec 2001 13:56:01 +0200 (EET)

> is not in the home or the visited domain, a HAO makes no difference.

Good point.  Nevertheless, picture a scenario where the site has only a 
couple of MIPv6 users: would it be okay to require AAA for their sake (for 
local firewall, and for interacting with remote AAA systems for ingress 
filtering)?

> => (3) is exactly what we don't want.

Sure, but that's still what me might get..

Consider: whoever got the idea that ICMPv4 is harmful?  For some odd
reason it's being blocked in many firewalls (breaking all sorts of
things).  It appears these kind of blocks can be installed even for much
smaller concerns than spoofability, or no reasons at all...

---

From: Michael Thomas <[email-masked]>
Date: Sat, 29 Dec 2001 13:21:19 -0800 (PST)

> given more importance in this WG. then we could have our way.

   You know, it would be great if the number of obviously
   inflammatory remarks were kept to a minimum. If it
   weren't for IESG interference here, we'd likely have
   a looming WEP-esque disaster caused primarily by
   impatient developers spurred on by impatient PHB's.

			Mike