> => 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 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.


>    > => I believe you'll have the same opinion about BU security too (i.e.
>    > byebye RR :-).
>    
>    I don't understand the point and I don't understand the joke.
>    Could you be more explicit?
>    
> => 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'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.


> => 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)

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

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to