Christian Huitema wrote:
Don't get me wrong, I like SEND. My point was just that if we allow
"transparent" bridges at all, then we essentially allow the same
man-in-the-middle attacks that are also possible with ND proxy.
But doesn't the layering inherent in the SeND vs. IEEE make this rather
diff
> ... I spoke to the NOC about it, and found out that they had only
> allocated enough address space for 256 hosts, and there were well over
300
> people in the room, many of whom were knowledgable networking
researchers.
> Somebody was ARP spoofing, stealing addresses because not enough had
been
>
James,
In 2002, I was sitting in the conference room at Mobicom browsing one of the
papers when my 802.11/IPv4 network connection started to act up. It would go
away, then come back, then hang for a long period of time. When I looked
into the matter more deeply, I discovered that the DHCP lease on
>SEND secures the mapping between an IPv6 address and a MAC address, but
>it does nothing to guarantee that the L2 topology actually delivers the
>packets to the intended destination. When we expand all that energy
>signing neighbor discovery packets, have we really improved security?
Here's a con
Christian Huitema wrote:
The general case of proxy ND, which this specification uses, can not
provide any security against MiTM because by definition the proxy is a
MiTM. Thus it is completely unreasonably to assume that SeND will
solve this.
What do you mean, unreasonable? It is certainly possible
Christian Huitema wrote:
SEND secures the mapping between an IPv6 address and a MAC address, but
it does nothing to guarantee that the L2 topology actually delivers the
packets to the intended destination. When we expand all that energy
signing neighbor discovery packets, have we really improved se
So, thinking some more about it, I have this nasty feeling about the
usefulness of SEND. Compare the two topologies:
Host-A <---> learning bridge <---> Host-B
Host-A <---> ND-Proxy<---> Host-B
SEND will work just fine with the learning bridge topology, but will not
work wi
> The general case of proxy ND, which this specification uses, can not
> provide any security against MiTM because by definition the proxy is a
> MiTM. Thus it is completely unreasonably to assume that SeND will
solve
> this.
What do you mean, unreasonable? It is certainly possible to write and
si
Dave Thaler wrote:
The fact that SEND doesn't yet support proxy ND is not specific to
this specification, it's something for SEND to solve.
The general case of proxy ND, which this specification uses, can not
provide any security against MiTM because by definition the proxy is a
MiTM. Thus it is
Cc: Thomas Narten; Margaret Wasserman; Brian Haberman; IPv6
> Subject: Re: Request to Advance:
[RESEND]
>
> Brian E Carpenter wrote:
> > > First, lets keep in mind that this is an Informational document.
> >
> > I wonder whether Experimental wouldn't send a
Some comments on draft-ietf-ipv6-ndproxy-00.txt...
Substantive comments:
I think this document would be more appropriately published as an
Experimental RFC rather than Informational. The inconsistencies
between the requirements for securing IPv6 neighbor discovery and
allowing dynamic addition/rem
Soliman, Hesham wrote:
FWIW I don't have a problem with ndproxy being published while incompatible
with SeND. There are other examples of completely insecure experimental
RFCs, e.g. Fast handoffs. It's essential to make the document consistent though.
what is being discussed is incompatibility betw
I know NDproxy is a WG item, but I think this problem space deserves a
discussion on its own. Although it has implications on IPv6 ND, I think
stretching subnets beyond links mean further than that. And there is
already another proposal contending for a similar problem space,
Rbridging. Before we
> Alain Durand wrote:
> ...
> > The argument that NDproxy will only be used in a certain
> environments
> > where SEND is not needed is clearly bogus, The IETF is not about
> > defining standards for special cases but for the whole Internet.
>
> I disagree as a matter of principle. It i
On Jan 27, 2005, at 6:02 AM, Brian E Carpenter wrote:
Alain Durand wrote:
...
The argument that NDproxy will only be used in a certain environments
where SEND is not needed is clearly bogus, The IETF is not about
defining standards for special cases but for the whole Internet.
I disagree as a matte
Alain Durand wrote:
...
The argument that NDproxy will only be used in a certain environments
where SEND is not needed is clearly bogus, The IETF is not about
defining standards for special cases but for the whole Internet.
I disagree as a matter of principle. It is perfectly OK to have
specs that
On Jan 24, 2005, at 3:14 PM, Jari Arkko wrote:
Erik Nordmark wrote:
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
That would be better than informational.
I agree. But I also think that if the document has
inconsistencies
D]>; "Thomas Narten" <[EMAIL PROTECTED]>; "Margaret
Wasserman" <[EMAIL PROTECTED]>; "IPv6"
Sent: Tuesday, January 25, 2005 8:51 PM
Subject: Re: Request to Advance: [RESEND]
> James,
>
> >specifically, speakeasy has a program listed on thei
On Tue, 2005-01-25 at 23:51, Bob Hinden wrote:
> >specifically, speakeasy has a program listed on their web site where you get
> >credits for routing your neighbor's traffic through your .11 ap. perhaps
> >other isps too?
>
> Thanks. Could supply a link to additional information on this?
http:/
James,
specifically, speakeasy has a program listed on their web site where you get
credits for routing your neighbor's traffic through your .11 ap. perhaps
other isps too?
Thanks. Could supply a link to additional information on this?
Bob
--
James Kempf wrote:
specifically, speakeasy has a program listed on their web site where you get
credits for routing your neighbor's traffic through your .11 ap. perhaps
other isps too?
sonic.net is another case.
Erik
IETF IPv6 w
I apologize if I've missed this particular point earlier in the discussion -
Experimental seems appropriate to me unless there is widespread deployment
of some version of the protocol that this document is specifying. And I
agree about correcting any inconsistencies prior to publication...
- Ralph
Erik Nordmark wrote:
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
That would be better than informational.
I agree. But I also think that if the document has
inconsistencies those should be corrected even before
publishin
> >> The counterexample is that there are ISPs that have their home users
> >> with 802.11 run public hotspots and get some compensation from the
> >> ISP. In this case, since it is a public access 802.11, SeND would be a
> >> good thing to use. And 802.11 is also a key scenario for proxynd.
> >
>
On Jan 24, 2005, at 6:03, [EMAIL PROTECTED] wrote:
Brian H,
First, lets keep in mind that this is an Informational document.
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
I can see how this could be very useful in certain
Brian Haberman wrote:
I take it from your detailed responses below that you see it in IETF's
best interest to publish this document and protocol without any quality
improvements to neither the document nor the protocol. Did I understand
that correctly?
I never said that. I was commenting on the v
Brian E Carpenter wrote:
> First, lets keep in mind that this is an Informational document.
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
That would be better than informational.
But I still think the document should say
Brian H,
> > First, lets keep in mind that this is an Informational document.
>
> I wonder whether Experimental wouldn't send a clearer signal
> that there is some doubt about the viability of the solution.
>
> I can see how this could be very useful in certain types of
> network environment, a
> First, lets keep in mind that this is an Informational document.
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
I can see how this could be very useful in certain types of
network environment, and publishing as Experiment
Erik,
On Jan 21, 2005, at 0:34, Erik Nordmark wrote:
Hello Brian,
For the most part, there has been less than optimal public
discussion. The minutes from Seoul indicate that Thomas was less than
happy with the level of comments. However, the people who did speak
up were in favor of it.
Hmm - I'm s
Hello Brian,
For the most part, there has been less than optimal public
discussion. The minutes from Seoul indicate that Thomas was less than
happy with the level of comments. However, the people who did speak
up were in favor of it.
Hmm - I'm spoken up in more than one IPv6 WG meeting pointing ou
Hi Erik,
On Jan 18, 2005, at 14:14, Erik Nordmark wrote:
I for one missed the last call, because I was on vacation during much
of those two weeks. Given that there isn't likely to be an IETF-wide
last call, I'd wish the WG and/or ADs take these comments into
account.
I think there are several s
Bob Hinden wrote:
[Corrected error in subject line]
Margaret & Thomas,
On behalf of the IPv6 WG, the chairs request the advancement of:
Title: Bridge-like Neighbor Discovery Proxies (ND Proxy)
Author(s): D. Thaler, et al.
Filename: draft-ietf-ipv6-ndproxy-00.txt
Page
[Corrected error in subject line]
Margaret & Thomas,
On behalf of the IPv6 WG, the chairs request the advancement of:
Title : Bridge-like Neighbor Discovery Proxies (ND Proxy)
Author(s) : D. Thaler, et al.
Filename: draft-ietf-ipv6-ndproxy-00.txt
34 matches
Mail list logo
