Charlie,
> 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
From: "Erik Nordmark" <[EMAIL PROTECTED]>
> > => 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
>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.
>
> => this is a constraint: active network access control is usually done
> at one place.
I wasn't talking about network access control - I
In your previous mail you wrote:
> => 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).
I did read draft-dupont-ipv6-ingre
> => 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).
I did read draft-dupont-ipv6-ingress-filtering-00.txt and it seems to assume
that the
In your previous mail you 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.
=> so you'll be very happy when you'll read my draft which relies onl
Francis wrote:
> I wrote:
>No, but the specification of MIPv6 should wait until the ingress
> filtering
>part is specified.
>
> => 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 thre
In your previous mail you wrote:
You're making assumptions here:
- every packet filter in the internet can
=> every firewall
1) recognize HAO
2) parse it, and
3) match against the address in it
This does not hold *at all*.
=> this holds for every decent fir
In your previous mail you wrote:
AAA for IPv6 is, indeed, quite another problem domain, and
one for which we've hardly started considering the issues.
=> Jari meant network access control, not full AAA with AAA infrastructure.
Furthermore, I am quite reluctant to get
embroiled
In your previous mail you wrote:
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.
=> if "ingress filterin
In your previous mail you wrote:
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 is 4.1 section of
Hello Jari,
Thank you very much for this clarification.
Jari Arkko wrote:
>> 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?
>
> I think you are right Charlie, that is the only downside.
> (There's a bunc
> Ingress filtering and firewalls exist already.
>
> => 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?)
>
> => no, we talk about commercial firewalls even if I
> Here, I disagree, although I clearly understand why you would say
> that.
Fair enough. Reading on...
> 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 th
> There is a downside: destination site's filtering ("spoofing protection"
> from the direction of the Internet) is nullified!
Yeah. Forgot that, sorry!
Jari
IETF IPng Working Group Mailing List
IPng Home Page:
In your previous mail you wrote:
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 b
Francis Dupont writes:
>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
Pekka Savola writes:
> On Fri, 18 Jan 2002, Jari Arkko wrote:
> > > 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?
> >
> > I think you are right Charlie, that is the only downside.
> > (There's
On Fri, 18 Jan 2002, Jari Arkko wrote:
> > 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?
>
> I think you are right Charlie, that is the only downside.
> (There's a bunch of other downsides related to fixi
In your previous mail you wrote:
No, but the specification of MIPv6 should wait until the ingress filtering
part is specified.
=> 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
Charlie wrote:
> > > If the downside is that then
> > > there is vulnerability to (single!) packets being reflected back
> > > to an unsuspecting home address, then: []
> >
> >That is not the only downside. The primary downsides
> >have been discu
> > If the downside is that then
> > there is vulnerability to (single!) packets being reflected back
> > to an unsuspecting home address, then: []
>
>That is not the only downside. The primary downsides
>have been discussed here ad nauseum.
I look
In your previous mail you wrote:
Ingress filtering and firewalls exist already.
=> 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?)
>Seems like this requi
Erik Nordmark writes:
> 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
Charles E. Perkins writes:
> 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
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 addr
- Original Message -
From: "Erik Nordmark" <[EMAIL PROTECTED]>
>
> 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.
For some people, RFC means Request For Comment.
Surely you don't think an RFC mean
> => 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 deploye
>>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.
>>
>> => I never proposed to wait for AAA solutions (as I
> ask
In your previous mail you wrote:
>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.
>
> => I never proposed to wait for AAA solutions (as I ask
>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.
>
> => I never proposed to wait for AAA solutions (as I ask only for network
> access control, not everywher
In your previous mail you wrote:
=> 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.
> - As a general rul
> - 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.
I agree.
But I would personally
33 matches
Mail list logo
