Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access

From: Michael Thomas <[email-masked]>
Date: Tue, 8 Jan 2002 10:20:25 -0800 (PST)

[Phil suggested I add mobileip back which was
 dropped somewhere along the way]

Francis,

I'm not sure we're communicating, so let me be a little
more explicit with what I had in mind:

1) MN arrives on new AR
2) It sends a packet using its home address as the 
   *source* address -- no HAO at all.
3) AR recognizes that the source address is not one of
   the subnets it subtends and sends an ICMP message
   to MN which explains the problem
4) MN sends AR a normal CN binding update
5) AR lifts the restriction for that source address
6) MN now sends packets as in (2), but unimpeded

If MN knows that there is likely to be a source
address check on AR, it can delete steps 2 and 3.
ICMP seems like a natural here because the router
really is reporting a network problem back to MN
(or not MN if a host were incorrectly configured,
etc).

If this is a subset of your proposal, fine. It
does seem that what I propose gets rid of the HAO
altogether which you don't seem to agree with.
However, may I suggest that it's the AAA part that
has become the lightning rod? And that maybe it
shouldn't be quite so ambitious? :-)

	 Mike

Francis Dupont writes:
 >  In your previous mail you wrote:
 > 
 >       No, actually, it was to have the MN send the
 >       BU's directly to the access router. On a router
 >       the BU just has an additional effect of removing
 >       any restrictions on source addresses it will 
 >       let through.
 > 
 > => I believed your proposal was BU snooping. But you can name it
 > as you'd like, the purpose is to provide the knowledge of bindings,
 > so there is no deep difference with my proposal (i.e. I can say
 > you use a non-standard network access control device, as I don't
 > specify one (I only give an example with AAA because it is the best
 > on the paper) I could argue your proposal is included in mine :-).
 > 
 >       Hence Pekka's question about use of ICMP was correct.
 > 
 > => I am reluctant to define new ICMPs for anything. There is already
 > a format for BUs, why a new thing?
 > 
 > Another point: HAOs are inside packets, to look at them is legitimate
 > for my firewall but not for any router on the path, i.e. I'd like
 > to have the check done once and others to trust it (this idea is
 > exactly the network access control).
 > 
 > Regards
 > 
 > [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Jan 2002 11:33:32 +0100

1) MN arrives on new AR

=> many (academic or R&D) sites I know don't use firewalls
(they use a router for filtering) but have a passive management box
which detects new addresses and builds a database with MAC, IP,
name, location, etc, something very useful in case of problems.
So even if classical network access control is not performed on 1)
at the first packet, unusual behaviors are detected (i.e. there is
a passive and without automatic reaction kind of network access control).
 At the opposite I know some (commercial) ISPs which use the (traditional)
network access control to punch holes in the firewall for outbound
traffic, i.e. all source addresses are blocked by default and
network access control is used to open some of them (in AAA term
the authorized resource is the Internet access): this is ingress
filtering at the address level, usually it is done at the access
device (e.g. modem) level too.

=> I propose that the packet is sent to the home agent (or something
similar).

=> perhaps I should add a statement in the draft with a requirement
(modulo ICMP rate limitation) for ICMPs when a HAO is filtered out.
I believe a router should implement this by default but a detailed
text should help.
What ICMP? I propose 4 (Parameter Problem) - 2 (unrecognized IPv6 option),
as the router is not the destination of the packet the MN should
understand what's happened. Note that 1 (Destination Unreachable) -
1 (administratively prohibited) is too ambiguous.

=> 4) is what I consider as a kind of network access control.

=> the difference with my proposal is here, I propose to accept
corresponding HAOs, you propose to directly open the ingress filtering.
See more comments after.

=> i.e. active/reactive modes.

=> in any case ICMP errors have to be sent when packets are dropped,
I believe we can reach a consensus about this very quickly.

=> in order to get rid of the HAO your proposal has to be
supported on every ingress filtering devices where a packet
from the MN can go though. This is not in fact like path MTU
discovery (which is already difficult to get in the real world)
because your proposal uses a signaling with all the usual
problems of signaling (scalability, security, ...).
 Even if to get rid of the HAO would be very nice, I don't
believe this will work in practice. To summary this has the
same kind of problems (i.e. limitations) than micro-mobility
(i.e. mobility based on host routing).

=> I insist about AAA: AAA is not an essential part of
my proposal, it only brings extra goodies:
 - an instance of network access control which is well known
   and already has proposed extensions for (mobile) IPv6
 - remote network access control
 - a connection between local and remote access control.

=> too ambitious for a global deployment, and for local/special cases
I am afraid that micro-mobility is more attractive (it gets rid
of the routing header too).

Regards

---

From: Michael Thomas <[email-masked]>
Date: Wed, 9 Jan 2002 11:27:43 -0800 (PST)

As originally advertised, I am now convinced that
this was indeed a crazy idea -- a bit too good to
be true. Thanks for the link on the "loose" RPF
checking; I wasn't aware of that. Having to signal
many routers in the path would be a non-starter,
and ISP's certainly have incentive to perform the
loose RPF, therefore this is an insurmountable
obstacle.

Oh well.

	Mike

---

From: Jari Arkko <[email-masked]>
Date: Sun, 13 Jan 2002 19:20:23 +0200

Folks,

We've had a very long discussion on what to do with MIPv6 Home
Address Options and Ingress Filtering, basically centering around
(a) solutions restricting HAOs to nodes that employ Route Optimization,
(b) solutions employing AAA in firewalls, and (c) solutions that
discard HAOs altogether and use BU authentication procedures (e.g. RR)
from the access router to the MN.

I'm not sure we are near consensus yet -- though we could be,
it's hard to say on the list because just a handful of people
have participated the discussion.

In any case, I'm thinking about how to go forward in a practical manner.
We need a solution. And we don't have much time to redesign MIPv6, so I'd
really like to see a solution that doesn't need too much new work. But
how do we decide between a-c?

I have a proposal. But first, let me make some observations:

- Most people do seem to agree that HAO reflection is an
   issue that needs to be dealt with somehow.

- A restriction can be relaxed easier than tightened. User
   groups with better technology can run relaxed versions, or
   future standard versions can have relaxed rules if we see
   that the infrastructure around us allows it.

- As a general rule, I'd like the Internet to use end-to-end
   mechanisms more than network assistance. This isn't just
   an architectural principle, but it will also ensure that
   we can deploy our things without waiting for providers to
   catch up.

- The different solutions have different impacts on
   various use cases of MIPv6. Some benefit regular MNs,
   some those that use RO with a CN, for instance.

So, my proposal is as follows:

1. We will not use the alternative (c), because it is not
    an end-to-end mechanism, because multi-hop ingress
    filtering could generate delays, and because scalability
    of intermediate routers with ingress filtering feature
    might become a question mark if there's a lot of state to
    hold. As a tradeoff, we have to carry HAOs in our packets.

2. We will have a two-phased approach to the MIPv6 spec and
    its treatment of reflection attacks: the first phase uses
    method (a) and the second phase relaxes the rules to allow
    also (b). The first phase will be put to the MIPv6 RFC.
    When and if experience shows that we can have AAA-based
    filtering in access routers and firewalls, an extension
    can be defined to allow the more relaxed use of HAOs.

Comments or other proposals are welcome.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Jan 2002 10:59:33 +0100

=> for (b) I prefer network access control (AAA is only one way
to provide it).

   
=> so it seems we have to wait for the face-to-face meeting.

   
=> we have to deal with it but we don't need a stronger solution
than today ingress filtering which is a BCP, i.e. something like
a SHOULD.

   - A restriction can be relaxed easier than tightened...

=> this doesn't work in practice because this is a security issue.
In the functionality vs security tradeoff, networking people always
choose the security, especially when they get no direct benefit from
the functionality. There are only a few counter examples (ingress
filtering is one of them).
   
   - As a general rule, I'd like the Internet to use end-to-end
      mechanisms more than network assistance.

=> ingress filtering is network assistance and is enough.
If we try a strong solution we'll get more security (i.e. a reply
to a minor improvement to an attack) and we'll weaken the functionality
(i.e. we'll lose the triangular routing).

     This isn't just an architectural principle, but it will also
     ensure that we can deploy our things without waiting for
     providers to catch up.

=> clearly you don't believe in current ingress filtering.

=> HAO is not MIPv6 only (i.e. be prepared to relax it :-).

   
=> I agree: (c) is unrealistic.

=> no, a two phase approach won't work because we'll stay at
the first phase. And you put the burden on the wrong people:
this is an ingress filtering problem, not a MIPv6 one, so
the solution should be in an ingress filtering improvement,
not in a new restriction for MIPv6.

=> if there is a consensus to do that, I propose to split the
MIPv6 document into a basic one about bidirectional tunneling
with the home agent and a special one about routing optimization,
i.e. the lost of the triangular routing should not have only
drawbacks.

=> this won't have interest, as soon as the use of HAOs will be
marginal, it will no more be considered as a real world security
threat.

Today firewall people have the choice between to ignore HAOs
(easy way for them because they have nothing to do) and to filter
them out (easy too but they are reluctant to kill HAO). My proposal
is to give a third solution (how to do an intelligent filtering),
your solution is to kill the HAO for them (so they won't complain :-).
Of course your proposal is safe, but I believe the price is a bit
too high. Frankly MIPv6 has already enough problems...

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jan 2002 20:44:18 +0100 (CET)

>    we can deploy our things without waiting for providers to

I agree.
But I would personally make a stronger statement since I'm concerned with
the direction of piling more and more requirements and dependencies on
AAA. Thus I think the AAA approach is the wrong one - if we collectively
can make AAA/Diameter do the things needed to make Radius more usable
(reliabiliy, security, some extensibility) I think we've collectively
have been successful. Keep piling more stuff on the AAA system and it might
very well get too heavy to be able to fly...

Also, waiting for AAA solutions to be available (specified, implemeted,
and deployed) before MIPv6 can be used seems to be counter to our desire
to finish up MIPv6 soon.

>     can be defined to allow the more relaxed use of HAOs.

While I have concerns with using the AAA per above I think the phased approach
(where the AAA approach continues to be discussed and further understood) 
makes sense to me.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 Jan 2002 10:59:09 +0200 (EET)

On Mon, 14 Jan 2002, Francis Dupont wrote:
[snip]
> the first phase.
[snip]

If we'd stay at the first phase, that'd probably mean that the 
stateful network access control mechanism wasn't attractive and 
wide-spread enough? -- Which is one of the points here.

If one would want to differentiate between "network access controlled (no 
checks in end-nodes)" and "in god we trust, others must be checked", 
perhaps Home Address Option sub-options could be used? (or identically 
defined another HAO.)

> And you put the burden on the wrong people:

(a bit tongue-in-cheek)

If QWERTY working group would define a new mechanism for storing effective
source address in a varying location of IP header chain, under some
destination option's freshly defined fourth option's third sub-option
(padded to 2n+x), would digging that out and just coping with it be
"ingress filtering problem" too?

If AZERTY working group would make new requirements (caused by said
working group's new proposal) for ingress filtering, so that it could not
be done in practise, would finding new ways to do ingress filtering befall
ingress filtering people too?

-- 
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: Tue, 15 Jan 2002 11:46:01 +0100

=> first I have submitted the draft, second I tried to make clear
that my proposal relies only on (any kind of) network access control
(i.e. anything more that just plug and play). AAA is an implementation
option which has extra benefits.

   I agree.

=> for my purpose Radius is enough (only a new attribute is needed
for the home address, a new version of RFC 3162 ?)

=> I agree but AAA is the only way to provide (one day) remote network
access control (*not* necessary but fine).

=> I never proposed to wait for AAA solutions (as I ask only for network
access control, not everywhere but enough to make HAO spoofing unattractive).

=> have you still concerns with using network access control in a BCP?

Regards

PS (for the IPv6 WG list): my draft is about HAO vs ingress filtering,
I assume there is a consensus about traditional ingress filtering, i.e.
RFC 2827 is applicable to IPv6 (i.e. we don't need another document and
we'll get tradition IPv6 ingress filtering (access lists and unicast RPF)
support in the next router software version (I apologize if this is
already available)).

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Jan 2002 12:22:54 +0100

[snip]

=> no, you haven't understood. The problem is not technical,
it is psychological: you can't have this kind of two phase approach
for a security device, you won't be able to relax something,
in fact it will be hard to get the first phase not be hardened.
For instance RFC 2401 explains that in tunnel mode the outer source
address should not be checked, most implementers do the check just
because it seems a bit more secure...

=> I have no concern about "in god we trust"... This is already the case
for ingress filtering and this is effective, i.e. random source address
spoofing is no more heavily used in DDoS attacks. This follows the same
mechanism than vaccination against an epidemic.

   (a bit tongue-in-cheek)

=> I think so (this is why I prefer the firewall based part of ingress
filtering because firewalls have to be prepared to dig into packets
anyway).

   If AZERTY working group would make new requirements (caused by said
   working group's new proposal) for ingress filtering, so that it could not
   be done in practice, would finding new ways to do ingress filtering befall
   ingress filtering people too?
   
=> this depends on who gets the benefits: if there are mainly global
benefits (as for home address declarations in order to limit HAOs),
I believe this is a topic for ingress filtering people, if there are
mainly benefits for a particular population (as for HAO filtering using
remote network access control, i.e. certified/verified home addresses),
I believe this is not a topic for ingress filtering people (in my
example this is a topic for AAA people).
We can consider where are the difficulties too but in a well engineered
system both should be equivalent (this is a practical problem too,
if you get the difficulties and not the benefits nothing will happen,
this is my concern about correspondent node based features).

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jan 2002 11:32:33 +0100 (CET)

> access control, not everywhere but enough to make HAO spoofing unattractive).

Are you proposing to wait until network access control is available?
(specified, implemented, and deployed)

If not, what do you propose to do in the interim until network access control
for HAO is available?
Seems like this requires a two-phase approach: phase 1 before it is available
and phase 2 when/if it become available.

What am I missing?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Jan 2002 14:35:48 +0100

=> we don't need to wait because mobile IPv6 is not yet fully specified.
IMHO the only thing we need is to be ready and the first step should
be to get (traditional) ingress filtering and firewalls with IPv6 support
(or do you suggest to stop IPv6 until they are implemented and deployed?)

   If not, what do you propose to do in the interim until network
   access control for HAO is available?

=> decide if we keep or kill the triangular routing. In parallel (because
even if the triangular routing is killed there are still similar mechanisms
based on tunnels with the same security issue) give this idea to
network access control people (both RADIUS/DIAMETER and firewall) in
order to know what concrete proposal we can/should do (for instance a
new RADIUS attribute for IPv6 inner source address declaration). IMHO
this second part is mainly not technical (i.e. out of the scope of IETF).

   Seems like this requires a two-phase approach: phase 1 before it is
   available and phase 2 when/if it become available.
   
=> you are acking what will happen after some kilometers in a deep fog:
today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress
filtering, IPv6 firewalls, ...

   What am I missing?
   
=> mobile IPv6 is not yet in last call, in fact we don't know if it will be
this year. So we only need a paper solution against the future and
potential minor security threat of HAO with ingress filtering.
But I agree we have to know where we are going or we could lose more
than our time in this kind of discussions (i.e. implementers don't like
to follow random moving specs).

Regards

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jan 2002 16:32:46 +0200 (EET)

> (or do you suggest to stop IPv6 until they are implemented and deployed?)

Ingress filtering and firewalls exist already.
 
> filtering, IPv6 firewalls, ...

You know full well that e.g. ip6fw, ipf, iptables (all free) etc. support
IPv6 ingress filtering and firewalling rather nicely; they've had the
support for some time now.  They're still a bit raw, as is understandable,
but usable.

So why do you spread FUD?

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jan 2002 15:37:20 +0100 (CET)

> (or do you suggest to stop IPv6 until they are implemented and deployed?)

No, but the specification of MIPv6 should wait until the ingress filtering 
part is specified.

If we (the IETF) really care about security we need to make sure that we don't
create holes in the set of standards track RFCs we issue. That is
all the IETF need to worry about. (Others need to worry about complete
security of products and a third set of folks need to worry about the security
of their operational network using those products.)

For the IETF I think this means that we should not issue a proposed standard
(e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be
made  aware of HAO). If we want to go this path I think we need a community
supported ingress filtering RFC (BCP or standards track) that handles HAO no
later than when MIPv6 becomes Proposed Standard.

I don't think we should use the fact that 1) there are IPv6 products with
incomplete security and/or 2) existing IPv6 operational networks have
incomplete security as arguments that we can have an IPv6 story where the
standards have security holes. Even if we say "we'll fill that hole really
quickly by later producing an HAO aware ingress filtering RFC" or
something similar.

> this second part is mainly not technical (i.e. out of the scope of IETF).

It seems like the IETF pieces (RFCs) that need to be completed to
have complete (i.e. not security holes in the combination of specs)
specification for network access control is sizeable: some fireall spec
(perhaps informational), some radius and diameter extensions.
This sounds like more delay for MIPv6 to me.

The two-phase approach removes this delay.

> filtering, IPv6 firewalls, ...

You're confusing specifications, products, and deployed practise.
People can build ingress filtering and firewalls for IPv6 today without
waiting for a specification from the IETF.

That wouldn't be true if we issue a MIPv6 specification which, in order to
avoid ingress filtering, depends on some yet to be written RFCs that specify
network access control for HAO.

> potential minor security threat of HAO with ingress filtering.

But we don't want to delay MIPv6 any more than we need to.

  Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 Jan 2002 08:49:24 -0800

Hello folks,

I'm pretty far behind on reading these voluminous e-mails, but
I would at least like to express again my belief that we could
go forward with the HAO as it is.  If the downside is that then
there is vulnerability to (single!) packets being reflected back
to an unsuspecting home address, then:

- This is not a completely horrible problem

- It is amenable to solutions that can be deployed later,
  as IPv6 itself becomes more widely deployed

- Solutions involving use of security associations between
  mobile and correspondent will be developed more rapidly if
  there is motivation for use with Proposed Standard Mobile IPv6

- We can be done almost immediately, and begin to productively
  tackle the issues more effectively with experience.

I think there is a very real possibility that we are getting
stalled in worrying over a problem that is not going to happen.

A couple of other points:

> => we don't need to wait because mobile IPv6 is not yet fully specified.

That is purely a matter of opinion.  People have built it and tested it
and it works.  I think it would be far more proper to say that Mobile IPv6
is in fact fully specified, but we have identified more things to do.
Those things should be in new specifications.  I would compare your
statement to be the same as saying "IP was not fully specified until
we had CIDR".  That is manifestly absurd, unless you are willing to
also contend that IP and IPv6 both are not even yet fully specified.

In my opinion, we are not moving forward because we are being
required to boil the ocean before even being allowed to take a drink.

>    access control for HAO is available?

I'd say let's try it.  The likely access controls are not going to
affect the handling at the correspondent node anyway.  The downside
isn't very bad anyway.  If I were a malicious hacker, why would I mess
with that when there are so many other low-hanging fruits to spear?

> filtering, IPv6 firewalls, ...

Phase one is basically requiring reverse tunneling for virtually all
mobility, killing route optimization, and probably along with it any
hope of QoS for many years.  It means that nodes will typically not
receive packets containing the Home Address option, and thus the feature
will rust.

> this year.

Well, technically speaking, it was already in Last Call last year (and
the year before).  But I guess that is really a moot point.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Jan 2002 11:01:53 -0800 (PST)

Charles E. Perkins writes:
 > to an unsuspecting home address, then: []

   That is not the only downside. The primary downsides
   have been discussed here ad nauseum. 

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Jan 2002 11:06:58 -0800 (PST)

> later than when MIPv6 becomes Proposed Standard.

   I agree 100% with Erik here, and add this:
   security needs to be thought of in terms of
   layers. Ingress filtering is a useful, but
   incomplete layer. Ultimately hosts need a means
   to defend themselves too since we can't assume
   that anything will have complete coverage.

		 Mike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Jan 2002 17:11:21 +0100

=> for IPv6? I'd like this is true but can you say more
(which IOS version has IPv6 unicast RPF and/or IPv6 advanced access lists,
which commercial firewalls have IPv6 support?)

   > filtering, IPv6 firewalls, ...
   
   You know full well that e.g. ip6fw, ipf, iptables (all free) etc.

=> no, we talk about commercial firewalls even if I share my not-expressed
opinion about them.

=> I don't want to spread FUD, I just wanted to show what is FUD...

Regards

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 18 Jan 2002 08:22:05 -0800

>  >                                       If the downside is that then

I looked at a lot of stuff, but that's the only one I saw,
even though it can be dressed up in different ways.
What else is there?

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 18 Jan 2002 18:40:10 +0200

> => no, we talk about commercial firewalls even if I share my not-expressed

Francis, I really don't want to define the word "exists" as equivalent
to "included in IOS". Nor do I equate it with "exists commercially".
So, like Pekka Savola noted, there's a open source OSes that deal
with both v6 packets as well as with v4 packets in their firewall and
filtering functions. I also know some leading firewall and VPN vendors
who are working on v6 versions of their products.

But perhaps you meant that ingress filtering isn't generally applied for
v6 yet. That might well be true. But I still don't want you take away my
possibility to go out tomorrow and buy a linux box/product and configure it to
do ingress filtering in my home!

Jari

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Jan 2002 18:40:59 +0200 (EET)

> which commercial firewalls have IPv6 support?)

If one vendor does not please you, you can try another (not that others
would have better support for these, necessarily) or bug them and/or wait
:-)

RPF is not required for ingress filtering, but sure makes it much easier.

> => no, we talk about commercial firewalls even if I share my not-expressed

Why again we should care about commerical firewalls?  Apparently their 
interests lie elsewhere; IPv6 is not significant enough for them and no 
one wants to pay for the extra.  Therefore those that care use free 
products.

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 18 Jan 2002 18:53:56 +0200

> even though it can be dressed up in different ways.

I think you are right Charlie, that is the only downside.
(There's a bunch of other downsides related to fixing
with AAA the hole HAO leaves in ingress filtering, but
that's another issue.)

The primary danger of unconstrained HAO is having even a small
number of attackers spoof HAOs and use a large
number of CNs as reflectors to attack a specific
target even if your network has ingress filtering.
Basically, it voids ingress filtering.

2-way i-trace would still detect the source of these attacks, at least
in some cases. However, my concern is that i-trace isn't ready,
isn't deployed and frankly I don't really believe it being deployed
anytime soon. A hypothetical "Care of Address Option" for MIPv6
would have the same detection power. The trouble with both of
these as opposed to ingress filtering is that they act after the attack
is done or over, while ingress filtering prevents attacks.

In situations where you have no ingress filtering there's really
no difference whether we use HAOs or not.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Jan 2002 18:11:39 +0100

=> I don't see why? Or do you argue that the ingress filtering part
is impossible or very long to specify (obviously not)? The purpose
to move this thread to the IPv6 WG mailing-list is just to fix it
in parallel.

   If we (the IETF) really care about security we need to make sure
   that we don't create holes in the set of standards track RFCs we
   issue.

=> I agree but in this case the target is explicitely "not introduce
significant new vulnerabilities that are not present in IPv4 today".
The new vulnerability has not be proved to be significant and the
proposed reply is designed to get back to the IPv4 situation (where
the reply to the threat, I have to say it again, is a BCP).

   That is all the IETF need to worry about.

=> I disagree, the IETF need to worry about holes in the set of
standards track RFCs we have already issued (the RFCs) and missed (holes).
(this should not happen but we know it's happened)

   made aware of HAO).

=> I believe you'll have the same opinion about BU security too (i.e.
byebye RR :-).

   If we want to go this path I think we need a community supported

=> supported = saying this is the solution or
   supported = have implemented it or
   supported = have deployed it
First is fine, second is possible (MIPv6 people will put pressure on
firewall people, IMHO firewall people need to be more aware of IPv6
in general). The last one is out of the scope of the IETF.

   ingress filtering RFC (BCP or standards track) that handles HAO no
   later than when MIPv6 becomes Proposed Standard.

=> I never use the "we'll fill" argument. My idea is "we can fill/we know
how to fill" in order to not slow down MIPv6 specifications. To move
the thread to the IPv6 WG is for the same purpose.

=> we need only some radius extensions (diameter extensions already
exist (as an author of one of the diameter for MIPv6 drafts, I may
claim this), firewall specs are not really in the scope of the IETF).
Of course if diameter for MIPv6 becomes a real AAA WG activity
(this is in the charter of AAA, the AAA/mobility RFC is very well
written (it makes no difference between IPv4 and IPv6), but AAA
people believe MIPv6 will be ready in many months/years).

=> not if it is done in parallel.

=> by dropping in practice the second phase, no thanks!

   > => you are asking what will happen after some kilometers in a deep fog:
   
   You're confusing specifications, products, and deployed practice.

=> no, I just reject all arguments based on what will happen in the future
at the exception that we want to get IPv6 smart ingress filtering
deployed not after than mobile IPv6. The IETF has no control over
deployment, its control is only over document publication, so the
only thing we can ask is to provide smart ingress filtering documents
before MIPv6 (we can do a bit more because we can implement them too).

=. can I translate your argument in the network access control for HAO
documents should be available (or enough stable) before the MIPv6 one
in the same state? This is unrealistic for DIAMETER (because of the
AAA state), easy for RADIUS and out of the scope of the IETF for
firewalls (I am not a firewall expert, I only know that many commercial
firewalls have a network access control module... in fact the whole
idea is from a team with some firewall persons so I know the whole
thing was put in a commercial firewall more than two years ago but
the @#$... people don't believe there is a market, grr...).

=> my purpose was never to delay MIPv6 but we obviously disagree
about what kind of stuff can be removed safely (i.e. with the
possibility to put them back after) from MIPv6 in order to speed it up.

Regards

PS: we are losing time: keep or kill the triangular routing?

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Jan 2002 19:36:12 +0200 (EET)

[snip]

There is a downside: destination site's filtering ("spoofing protection" 
from the direction of the Internet) is nullified!

(This attack is especially nasty in "send an UDP exploit" scenarios -- not
necessarily DoS.)

This can be more or less partially repaired, by e.g. allow incoming HAO
with local Home Address only from local MN's, or local MN's that are known
to be outside, or even local MN's that match a specific binding and are
outside.

However, for security, that requires packet filters wanting to protect
from this must have the ability to go into extension headers and match
against HAO.. this is not yet implemented anywhere that I know of; 
requirinig this for security of HAO might be too much.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2002 09:41:09 -0800 (PST)

> from the direction of the Internet) is nullified!

   Thank you. That was exactly what my point was.
   It's not just the reflector attack; the HAO
   nullifies all of the ingress filtering present
   on the net right now. That is distinctly worse
   than the status quo.

	      Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2002 09:48:01 -0800 (PST)

> the reply to the threat, I have to say it again, is a BCP).

   Positing AAA as the necessary band-aid is a non-starter.
   Positing the kind of fix I proposed as a "crazy idea"
   runs into problems with middle of the network RPF
   checking and will, in practice, sink any use of 
   route optimization. HAO's cannot defeat ingress 
   filtering. That is distinctly worse than the
   current net.

   I think we seriously need to consider whether
   we should sever route optimization from this
   draft. Sigh.

		Mike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Jan 2002 19:04:31 +0100

=> I agree but it seems there is the real point...

=> a two phase approach works never in the security domain or
the triangular routing needs HAO support everywhere to make sense.

=> I still believe the idea to send IPv6 questions to the IPv6 WG
is the correct one. In fact the decision of keeping or killing
the triangular routing is in the hands of IPv6 implementors
(they are supposed to read the IPv6 WG list from time to time).

=> to get stalled is the worst way to get a decision.

   
   > => we don't need to wait because mobile IPv6 is not yet fully specified.
   
   That is purely a matter of opinion.

=> or of what is the meaning of fully specified. It seems I am the author
of this statement so I meant "not yet ready for publication".

=> this one of the drawbacks of security issues...
I am not commenting other remarks because we agree.

=> is a new last call after important changes due to IESG concerns
required? It seems we'll get a new WG last call, and perhaps some
last calls about other (than the spec) MIPv6 documents.

Regards

PS: you are in favor of keeping the triangular routing, aren't you?

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 18 Jan 2002 20:38:47 +0200

> from the direction of the Internet) is nullified!

Yeah. Forgot that, sorry!

Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 18 Jan 2002 09:45:30 -0800

Hello Jari,

Thank you very much for this clarification.

> with AAA the hole HAO leaves in ingress filtering, but

AAA for IPv6 is, indeed, quite another problem domain, and
one for which we've hardly started considering the issues. 

> Basically, it voids ingress filtering.

Here, I disagree, although I clearly understand why you would say
that.  The reason I disagree, is that I can specify an augmented
ingress filtering router that will work with HAOs (and, actually,
have already begun to done so). I do understand that such a thing
is harder to build.  Furthermore, I am quite reluctant to get
embroiled in a design discussion about building ingress filtering
routers (notwithstanding (*) below), when what I really want to
do is to move the Mobile IPv6 specification forward.

> is done or over, while ingress filtering prevents attacks.

But the larger problem is that we are being fantastically careful
about avoiding a possible future problem that is:
1) solvable in a backwards compatible way
2) not so horrible,
3) delaying by years the specification, and consequently
4) causing other design dislocations in, e.g., 3G.

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

In an effort to be constructive, here are some further ideas about
how to limit the damage from the packet reflection which can be
caused by malicious use of unrestricted HAOs.

1) The correspondent node can strictly limit the number of
   care-of addresses available to any one home address (to,
   say, one or two).  It _could_ even do so for the number
   of care-of addresses assignable to home addresses on a
   particular subnet, if we wanted to go to the trouble of
   putting the prefix length back into the Binding Update.

2) The ingress filtering router can strictly limit the number
   of HAOs transmitted from any particular subnet prefix
   per unit time (*).

These are the first things that come to mind, and I believe
they are quite simple to implement.   (1) certainly is.
Plus, I believe that, for the purposes of handling HAOs,
we should begin to distinguish between home addresses that
have security associations established with the correspondent
node, and home addresses that do not.  It is the latter
variety that need to have the strict numerical limitations.

Regards,
Charlie P.

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 18 Jan 2002 20:45:48 +0200

> that.

Fair enough. Reading on...

>  The reason I disagree, is that I can specify an augmented

Yes. Your approach is a good one, but I think the concern
people have is that they are doubtful whether a sufficiently
good solution exists. I simply don't believe in the AAA approach
to fix this problem, for instance (even if I'm a big fan of AAA for
other purposes and even partially behind the Diameter base spec).
So, if you were able to give some clue to the plan how what
you intend to achieve, perhaps we could go with this approach then.
However, for the moment as has appeared such a hard problem
to me that I really need to see a some convincing parts of the solution
at least before I'd believe this really can be done.

> caused by malicious use of unrestricted HAOs.

Excellent!

>    putting the prefix length back into the Binding Update.

Unfortunately I don't think this will work. One property of the
HAO reflection vulnerability is that the number of nodes offering
"reflection service" is roughly the size of the IPv6 Internet. So,
any rate limitation / address limitation etc will not help if the
attacker chooses another CN the next time.

>    of HAOs transmitted from any particular subnet prefix

This is better than the previous one. But I'm still not too
happy with it. How do we ensure that what seems like
a small bandwidth at the Nokia Research Group router
isn't going to feel like a catastrophy at my home link?
And what if everyone in the Nokia Research Group wanted
to use HAOs at the same time, would their traffic capacity
be cut down too much? What would the value be? What
will it require from the router, is state involved or can you
do it in stateless way?

Also, if the HAO reflection would be used to hide DDoS
attack clients in a number of places, rate limitation at
single router might not help.

> variety that need to have the strict numerical limitations.

I'll treat this as the third offered solution. Like I think Pekka
mentioned some time ago, there's ways of coming up with
SAs that don't necessarily live up to this standard, even if
such SAs would be useful for e.g. preventing passive wiretapping.
But given that Opportunistic IPsec is not deployed much yet, maybe
we could put that consideration aside. Perhaps we should then
consider a rule that forbids HAOs if there's no SA involved? That
would be a possibility. The downside is that you'd still have to
provide for bidir tunneling for cleartext communications. Then
I could also ask that if you bothered to do 2xRSA+1xD-H and
keep at least a few hundred bytes of state at both ends, why
couldn't you use RO at that time too?

In conclusion I like these ideas better than the AAA approach.
However, I still think we'd need something even better to
start considering this alternative for real.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Sat, 19 Jan 2002 18:43:08 +0100

=> this argument works only when this is at least one commercial proposal.

=> ingress filtering can be divided in router-based, aka unicast RPF,
and firewall-based, aka intelligent access lists. If my proposal applies
to the second one, I've never considered the first as superfluous:
we need both and we have no commercial product of any of them.
This is a dangerous and unbearable situation (and has nothing to
do in this thread).

   > => no, we talk about commercial firewalls even if I share my not-expressed
   
   Why again we should care about commerical firewalls?

=> because by definition the market cares about them.

   Apparently their interests lie elsewhere; IPv6 is not significant
   enough for them and no one wants to pay for the extra.

=> this is what we should change.

   Therefore those that care use free products.
   
=> you know this is simply not true in the real world...
(what we'd like to be as nothing to do there)

Regards

PS: I've answered to your message because I should reuse it if one day
someone argues "this is only implemented in free products"...

---

From: Pekka Savola <[email-masked]>
Date: Sat, 19 Jan 2002 19:50:00 +0200 (EET)

> This is a dangerous and unbearable situation (and has nothing to

Wrong.  Ingress filtering done with non-RPF mechanisms does not need to
intelligent.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 19 Jan 2002 19:06:05 +0100

=> this is 4.1 section of my draft:
 - the vulnerability can exist *only* if there are some home agents
   inside the site (this is a strong constraint)
 - the defense is basically the same: the filtering devices have to
   know the bindings (the home registrations are enough) by the way
   you'd like (several work, the only implementation I know uses
   BU/BA snooping with success).

=> no, this can be fully repaired. And in most cases very easily:
no home agent = no binding = just apply the anti-spoofing to everything
that can be a source address.

   against HAO..

=> if your packet filter doesn't already do that, change it ASAP.

   this is not yet implemented anywhere that I know of; 

=> this was implemented 30 months ago somewhere I know of.
(I can ask for a testimony if you really want it)

   requiring this for security of HAO might be too much.
   
=> if I apply your argument to the routing header it should be forbidden...
I strongly disagree: stupid defects in some stupid firewalls should not
be admissible arguments against a protocol feature.

Regards

PS: the position of the HAO in packets was required by some firewall people,
so I believe there are at least two firewall expert teams which already
managed how to deal with HAOs...

---

From: Francis Dupont <[email-masked]>
Date: Sat, 19 Jan 2002 19:15:48 +0100

=> if "ingress filtering" is your message is anti-spoofing, I've answered
in a previous mail, so I consider this is the traditional ingress
filtering.
I believe you made a confusion between causes and effects. Ingress
filtering itself as no value, ingress filtering is a reply to
the source address spoofing threat which itself is only an option
to the DDoS threat. So the HAO problem is *only* the reflector attack
in this context (i.e. without anti-spoofing considerations).

Regards

PS: we do no progress. After Monday I'll answer only comments to
my draft and threads proposed by the mobile-ip WG chairs.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 19 Jan 2002 21:51:57 +0200 (EET)

> => this is 4.1 section of my draft:

I know.

You're making assumptions here:

 - every packet filter in the internet can
   1) recognize HAO
   2) parse it, and
   3) match against the address in it

This does not hold *at all*.  I doubt very much even a half of IPv6 packet 
filters, router access-lists etc. would do this in a few years' time (look 
how long it has taken to e.g. get anycast implemented, and to what 
success..).

The easiest method, which *might* be deployable soonish would be a check 
whether HAO exists or not (1) above), and drop all packets with it.  
However, this would kill all the use for HAO too; not good enough.
  
Iff 3) above holds, every site which does not have mobile nodes of its own 
can be protected.  (If it has MN's, state/AAA or more lax security for the 
addresses is required.)

In my opinion, this is an unrealistic requirement.

> that can be a source address.

See above.
 
> => if your packet filter doesn't already do that, change it ASAP.

I don't know of any alternative.
 
> (I can ask for a testimony if you really want it)

I'm interested, sure.

But really, I'm not all that interested if it was implemented just 
somewhere and not integrated with any firewalling products.
 
> be admissible arguments against a protocol feature.

Perhaps, perhaps not.  But I was not advocating Routing Headers be 
filtered in firewalls; I was not advocating HAO be either (because both 
are difficult problems which I think will not be deployed in the real 
world very widely).

Instead, I was advocating stronger checks in the end-nodes, thus
eliminating the need for firewall security checks except for those 1% who 
really want to go and build the AAA system to get the extra control and 
security.  For routing headers, it appears this issue will be clarified.  
For HAO, this is still open as it would require bigger modifications.

> managed how to deal with HAOs...

Wrong assumption.  This means some firewall people have analyzed what it 
seems to be required to manage HAO at all: whether it can be checked under
every circumstance (e.g. IPSEC secured data) and where it is usually 
located (check for the existance of the header, not necessarily the 
content).  This speaks nothing for implementing parsing for it, or 
anything.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 20 Jan 2002 14:54:47 +0100

=> Jari meant network access control, not full AAA with AAA infrastructure.

   Furthermore, I am quite reluctant to get
   embroiled in a design discussion about building ingress filtering
   routers (notwithstanding (*) below), when what I really want to
   do is to move the Mobile IPv6 specification forward.
   
=> I agree, the ingress filtering stuff should be dealt with in parallel.

   
=> I don't believe in defense at CNs with triangular routing,
I am afraid this will catch only buggy attacks.

=> this can be useful in order to detect abnormal situations
(i.e. attacks) but not to fix them (it is too hard to distinguish
between legitimate and fake HAOs so the system can be itself
the target of a DoS attack).
The best passive protection is BU/BA snooping (all interesting
parameters are in the exchange and BAs are easy to check) but
if it is effective when possible (no too much ciphered fields,
snooping devices in the path), I personnaly prefer more active
schemes (mainly because they give far better proofs in the legal
meaning... but I believe firewall people prefer snooping which is
more common in their context).
BTW I've interpreted your statement as the number of *different* HAOs
transmitted...

=> with current specs a MN must have a home registration with is
always acknowledged so BU/BA snooping is the next step of your idea.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 20 Jan 2002 15:48:40 +0100

=> this depends on what is wanted: if filtering at the address level
(i.e. not only at the prefix level) is required (and there are good
reasons to do it when it is possible) then the access-list system
has to be intelligent (i.e. static rules are not enough).
By default we can consider that firewalls are intelligent so
there is no problem to ask them a bit more when we don't rely on
the extras.

Please note this si more than traditional local ingress filtering,
is a reply to more than random source address spoofing and usually
is implemented with the help of the network access control system.

A final remark: source address spoofing in the same prefix can become
a real problem with IPv6 (just rename it interface ID spoofing...).

Regards

PS: this point is exactly like network access control and AAA,
the first can be needed, not the second but it will be very fine
to get the second.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 20 Jan 2002 16:21:11 +0100

=> every firewall

      1) recognize HAO
      2) parse it, and
   
   This does not hold *at all*.

=> this holds for every decent firewalls: they do URL filtering and you
are trying to say they don't know how to dig into a packet?

   I doubt very much even a half of IPv6 packet filters, router
   access-lists etc. would do this in a few years' time

=> I assume we'll get at least the same level of technology which is
used today near everywhere for IPv4.

=> I agree that today situation for HAO is "ignore all" and the next step
is "drop all". I expect a third step (I am optimistic (:-) and this
is a problem of balance between mobility industry and firewall industry).

   can be protected.

=> yes, to know there is no binding at all is a perfect knowledge of
current bindings (:-).

   (If it has MN's, state/AAA or more lax security for the 
   addresses is required.)
   
=> please use "network access control" in place of AAA because some FUD
is based on the confusion between network access control and AAA
infrastructure.

=> what is unrealistic is to believe firewalls are not commonly used...

   > anti-spoofing stuff...
   
   See above.
    
=> anti-spoofing is different because the simple case is "no HA" which
should be far more common than "no MN". The way to use firewalls is
more usual too and gives more freedom.

    
=> I know at least one but it is not yet commercially available
(I can privately give some pointers). I believe there are others
(ready but not available).

=> a network access control please, no the AAA system

   security.

=> this doesn't work: if we kill the triangular routing following your
suggestion there will be no exception at all.
   
   > managed how to deal with HAOs...
   
   Wrong assumption.

=> please let Charly Perkins (or these persons) answer.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Sun, 20 Jan 2002 17:23:25 +0200 (EET)

> there is no problem to ask them a bit more when we don't rely on

Some might want this, some not; I don't require intelligence and 
complexity from a firewall/packet filter.

The point is, there are three kinds of mechanisms:

1) ingress filtering done with RPF-like -mechanisms
2) ingress filtering done with access lists
3) "intelligent ingress filtering"

Additionally, any of these can be done either in a firewall or a 
router. (3) in a router might be a little tricky though.)

You're neglecting 2) and assuming everyone who doesn't use 1) will want to
have the extra pains of 3); this is not the case.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 20 Jan 2002 16:41:12 +0100

=> intelligence and complexity is the price of security
(or you lose a lot of features).

   
   
=> (3) is usually out of the scope of a router (example: (3) is not
standard IOS, i.e. IOS without the "firewall feature set").

=> no, I assume that most people using or not (2) have a firewall
which can provide (3) with "most" is in fact "enough to make HAO
spoofing unattractive". If you object can you provide numbers about
people using (2) (not so high, it seems that many people rely on
their ISP to do ingress filtering :-) and about people using firewalls
(both for IPv4 for course).

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 10:42:08 +0100 (CET)

Francis wrote:
> I wrote:

It's just that I haven't seen credible solution to distributed ingress
filtering of packets with HAO that doesn't resort to have a global AAA
infrastructure to solve the hard problem.
I personally think we need solutions that don't required additional
infrastcuture.

> (this should not happen but we know it's happened)

Sure, in addition to make sure that new stuff doesn't have holes we either
need to fix or deprecate existing stuff with security holes.
I don't think I said anything to the contrary.

> => I believe you'll have the same opinion about BU security too (i.e.

I don't understand the point and I don't understand the joke.
Could you be more explicit?

> in general). The last one is out of the scope of the IETF.

If youn read the whole sentence before interjecting the comments (it's below)
you'll see it was about an RFC. BCP and Proposed standards are not required
to be implemented and/or deployed in order to be publishes as such.

> in the same state? 

Yes, this is what I said several times now.
No PS for MIPv6 with a security hole in my personal opinion.
Means that a PS or BCP smart ingress filtering (set of) RFC need to exist
at that time as MIPv6 becomes PS.

> This is unrealistic for DIAMETER (because of the

Above you said it wouldn't delay MIPv6 to do this (because of it being done
in parallel) but now you seem to say it would delay it because of various
reaons. So you seem to agree with me about the delay? 

> PS: we are losing time: keep or kill the triangular routing?

I say: Remove the unauthenticated and unauthorized use of HAO which
has the effect that tringular routing isn't an option. The only options
are bidirectional tunneling through the HA and route optimization.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 21 Jan 2002 12:34:24 +0100

=> so you'll be very happy when you'll read my draft which relies only
on *enough* of any kind of network access control (even passive one,
aka BU/BA snooping which can have the favour of firewall folk).

=> we agree.

   
=> your statement could suggest the IETF doesn't need to worry about holes
in already published standard track RFCs (we agree this is *not* the case).

   
=> RR is known to be a bit weak from a security point of view so
as a MITM vulnerability can be considered as a hole, your opinion should
be in disfavour of RR, isn't it? (smile again)

   
=> I apologize: I was afraid of overinterpretations of the term supported.

   > =< can I translate your argument in the network access control for HAO
   
   Yes, this is what I said several times now.
   No PS for MIPv6 with a security hole in my personal opinion.
   Means that a PS or BCP smart ingress filtering (set of) RFC needs to exist
   at that time as MIPv6 becomes PS.
   
=> thanks, now there is no possible ambiguities about your opinion.
BTW I fully agree with you about this point.

   reasons.

=> where are the reasons (in document publication, cf above) of delays?
This can only be about the connection between network access controls
and firewalls:
 - there is no IETF protocol about this
 - it seems the current consensus is this is not in the IETF scope
 - this exists, in general in the purpose to be applied to remote
   and/or mobile users, for instance
   http://www.evidian.com/accessmaster/netwall/features.htm#Broad
In many AAA and PANA drafts (including mine :-), there are references
about when the terminal is authentified the firewall is opened for it
(i.e. authorization is "to access to the Internet"). I can't find
details about how this is done, can some firewall folk help us?
(if you know some, can you forward this to them)

   So you seem to agree with me about the delay? 
   
=> one thing we agree is we don't want delay.

   
=> so we disagree only about the necessity to remove the unauthenticated
and unauthorized use of HAO (my argument is there is no such necessity
about source address themselves).

Thanks

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 14:28:02 +0100 (CET)

> aka BU/BA snooping which can have the favour of firewall folk).

I did read draft-dupont-ipv6-ingress-filtering-00.txt and it seems to assume
that the architecture only needs to support ingress at one place.
I think we need to allow ingress filtering to take place at multiple
"levels" such at each college dorm room router, between the college and
the ISP, between leaf ISPs and transits, etc.
I don't see any difference between saying 
 - we can trust the access network to do ingress filtering
 - we can trust the host to not use bogus source addresses
Fundamentally it is an issue about trust boundaries.
If an ISP doesn't do ingress filtering themselves the ISPs that provide
service to it might want to filter. The architecture should not prevent
such flexibility.

> be in disfavour of RR, isn't it? (smile again)

I'm answering the serious underlying question/assumption:

You seem to have not read the abstract in the BU3WAY document.
I never claimed it was the best approach.

In fact, if CGA was free (no IPR concerns and no performance concerns for
the PK operations) doing CGA (in combination with RR to deal with certain
DoS attacks) would be the obvious answer IMHO.

> (if you know some, can you forward this to them)

If we feel that we (the IETF) can't produce documents that say how firewalls
should behave then it would seem foolish for us to produce standards that
assume certain behavior in firewalls.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 21 Jan 2002 19:37:22 +0100

=> this is a constraint: active network access control is usually done
at one place.

=> it seems you have a very bad feeling of your ISP (:-).

=> I fully agree: this is a trust/responsability issue so I am not
surprised when this can be described with AAA terms (for instance
this is about "the authorization to use this home address").

   The architecture should not prevent such flexibility.

=> what does prevent flexibility is the only current technical
concrete form of trust/responsability is network access control systems.   

=> IMHO BU3WAY is an attempt to get the faster/cheaper security
scheme for BUs (the opposite of IKE+AH).

=> so I've put again a smile.

=> if CGA was free we have a lot of better solutions to many problems
(including the HAO vs ingress filtering one) but it has both IPR and
performance concerns...
   
   If we feel that we (the IETF) can't produce documents that say
   how firewalls should behave

=> this is about details of communication between network access controls
and firewalls, not about firewall behavior. BTW my draft is essentially
a firewall behavior specification.

   then it would seem foolish for us to produce standards that
   assume certain behavior in firewalls.
   
=> firewall people were not enough (? :-) foolish to wait for us
to specify how network access controls and firewalls should communicate.
More seriously I've looked at what is available:
 - it seems a lot of firewalls support this kind of feature for
   remote/mobile access (all the commercial firewalls still in the market)
 - IPF (well known open source firewall) has the auth/preauth actions
   which do exactly what is needed (unfortunately the IPv6 support of IPF
   is questionable and has not (*yet*) HAO support.)

Regards

---

From: Alpesh Patel <[email-masked]>
Date: Mon, 21 Jan 2002 11:22:26 -0800

Sharath,

Just to let you know, the code where I thought would be a problem was
an oversight. That is the reason, I just asked if it was tested. I think
Roy
added this code, but would wait for him to respond

-a

Sharath Veldanda wrote:

> Alpesh,
>
> Do you have the DDTS number handy ??
>
> -S
>
> >Date: Mon, 21 Jan 2002 11:01:07 -0800
> >From: Alpesh Patel <[email-masked]>
> >X-Accept-Language: en
> >MIME-Version: 1.0
> >To: [email-masked], [email-masked]
> >Subject: Questions about ipmobile_AddAddrTypeExt() in ipm_standby.c
> >Content-Transfer-Encoding: 7bit
> >
> >Team,
> >
> >Wondering if the ddts that added the code related to the function
> >ipmobile_AddAddrTypeExt() was tested /regression tested.
> >
> >If it was tested, the owner needs to work with a DT to add it into
> >regression suite.
> >
> >-a
> >

---

From: Michael Thomas <[email-masked]>
Date: Mon, 21 Jan 2002 11:35:13 -0800 (PST)

Alpesh Patel writes:
[]

Yet another oops. Can we *please* change this to
not be reply-to: mobile-ip? Who is the list owner???

       Mike

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 21:21:52 +0100 (CET)

> => this is a constraint: active network access control is usually done

I wasn't talking about network access control - I was talking about ingress 
filtering. 
While e.g. an ISP/subscriber relationship might have some network access
control that isn't the only place ingress filtering might need to be done.

> => it seems you have a very bad feeling of your ISP (:-)

Yes I do, but I don't trust the whole edge around the whole Internet.
There probably exists at least one ISP on the planet that will
allow any source address in the packets sent by their subscribers.

Thus it needs to be possible to ingress filtering at other places than
just the ISP/subscriber boundary.

> concrete form of trust/responsability is network access control systems.   

Sorry, wrog subject. We were talking about ingress filtering and
not network access control I think :-)

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Jan 2002 22:37:37 +0200 (EET)

> not be reply-to: mobile-ip? Who is the list owner???

I fail to see how it would have changed the situation here?  It seems more 
likely someone had a bad email shortcut.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 23:34:38 +0100 (CET)

Charlie,

> receive packets containing the Home Address option, and thus the feature

I don't understand the meaning you assign to "basically" above.

Phase 1 would allow either bidirectional tunneling or route optimization
(in both directions). The thing it wouldn't allow is the triangle when packets
from the MN go directly to the CN, but the other path is through the HA.

   Erik