It might therefore be helpful to take a look at draft-ietf-pkix-x509
before Last Call completes.
++
Why before ???
I think that prefix delegation requirement draft can go forward
with or without draft-ietf-pkix-x509, isn't it ???
Sure. But my point was that if there is change you
Thomas,
I agree with your opinion and also support deprecating site locals. The
discussion you posted is clear and very persuasive.
However, I believe some of the resistance to deprecation may be the result of
people who have implementations and would rather not have to pay the costs of
ripping
Thomas,
I support this change.
Regarding what to do with the DNS server discovery work, I think a BOF would be
an appropriate approach. Steve Deering's serverless discovery is an interesting
approach, and I think it deserves some consideration, but I've heard plausible
reasons why DNS server
But isn't there a simple attack in which the attacker sends an NA message out
with the victim's link layer address in the option but its own address on the
frame? Naturally, if the link layer allows the attacker to send out frames under
a false address, it could fully spoof the victim as well.
I'm in the process of upgrading my home computing infrastructure in order to be
able to use IPv6. Does anybody know a retail ISP in the US that provides IPv6
service (specifically, in the SF Bay Area)?
I did a quick Google search and all the offerings seem to be for backbone
service.
The problem with this proposal is that the AP doesn't exist as far as IETF is
concerned. An AP is not an IP device, and it is not on the map as far as the
Internet architecture is concerned.. Routers do exist and therefore the fast RA
could be standardized in the IETF.
That said, I think the
The problem with this proposal is that the AP doesn't exist as far as IETF
is
concerned. An AP is not an IP device, and it is not on the map as far as the
Internet architecture is concerned.. Routers do exist and therefore the fast
RA
could be standardized in the IETF.
That said, I
Vijay,
I think the issue isn't whether this particular optimization is important or
not. The issue is whether we should leave it in the base spec or put it into a
spec with all the other ND optimization bits.
jak
- Original Message -
From: Vijay Devarapalli [EMAIL PROTECTED]
Hesham,
I wasn't proposing that they be coupled. I see the two as complimentary.
jak
- Original Message -
From: Hesham Soliman (EAB) [EMAIL PROTECTED]
To: 'James Kempf' [EMAIL PROTECTED]; Bound, Jim [EMAIL PROTECTED];
Thomas Narten [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED
A point was brought up on the list that in order to make FastRA defined in
draft-mkahlil-fastra-01.txt work, the MAX_RTR_SOLICITATION_DELAY on the host
must be set to zero and this would cause RS congestion if an access point failed
or a group of mobile nodes moved at once.
While this could be
Hesham,
Do you anticipate that the changes in FMIPv6 for access routers will be in all
IPv6 routers?
jak
- Original Message -
From: Hesham Soliman (EAB) [EMAIL PROTECTED]
To: 'James Kempf' [EMAIL PROTECTED]; Bound, Jim [EMAIL PROTECTED];
Thomas Narten [EMAIL PROTECTED]
Cc
Do you anticipate that the changes in FMIPv6 for access
routers will be in all
IPv6 routers?
= I don't know. But I know that any router can be
an access router. People don't develop a special router
because it will be connected to an ethernet that has a an
802.11 base station at
Nick,
For example, hmipv6 offers one possible way of eliminating the RTT
delay caused by sending BUs. In its current form, it probably
isn't scalable to that level, but sadly I don't have a megapolis
to test it with -- I'm a research engineer not a product engineer :-)
With the latest
I had a look at this draft. Specific comments below.
The IPv6 w.g. chairs believe there are some important open issues that they
would like to see the working group discuss as part of the working group
last call on the IPv6 Flow Label Specification
draft-ietf-ipv6-flow-label-03.txt.
The
Yes, sorry.
jak
- Original Message -
From: Greg Daley [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: Brett Pentland [EMAIL PROTECTED]; Thomas Narten
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, October 15, 2002 10:20 PM
Subject: Re: Changing RS Reply Timing
Thomas,
Seems to me then that this document is a bit narrowly scoped and may
even miss the point. Don't we need to look at the overall problem and
then see what can be done to address the overall problem adequately?
In general, I don't know that its all that useful to focus on a narrow
part
Mohamad Khalil, Brett Pentland, and I just submitted a draft on modifying the RS
reply timing:
http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-02.txt
I didn't see an announcement from the drafts editor in this group.
In summary, the draft amends RFC 2461 to allow at most one
Vlad,
Good point. This would work for the normal circumstance, though it would not
deter an attacker, as you point out.
jak
- Original Message -
From: Vladislav Yasevich [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, October 08
PROTECTED]
To: Pekka Savola [EMAIL PROTECTED]
Cc: Jari Arkko [EMAIL PROTECTED]; [EMAIL PROTECTED];
Bound, Jim [EMAIL PROTECTED]; James Kempf
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, June 17, 2002 12:49 AM
Subject: Re: Securing Neighbor Discovery BOF
On Sat, Jun 15, 2002
Hi Jim,
What is the point of this meeting. We have so many meetings to go to.
Just turn on IPsec whats not in ND to support this?
What problem are you trying to solve?
IPsec works for ND?
We are interested in discussing how to secure IPv6 Neighbor Discovery in
a way that would work
) should be on the table at this point, in addition to other
techniques, such as CGAs.
jak
- Original Message -
From: Michael Thomas [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: Steven M. Bellovin [EMAIL PROTECTED]; Jari Arkko
[EMAIL PROTECTED]; Pekka Savola [EMAIL
Hi Steve,
Key distribution could be done via Layer 2 AAA or using the roaming
consortia idea we had in the ABK draft. However, I think that might
require some change in IPsec policy, because I believe the policy
only
allows IKE or manual keying for key distribution.
That's not correct. In
Message -
From: Pekka Savola [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 07, 2002 1:51 AM
Subject: Re: Securing Neighbor Discovery BOF
On Fri, 7 Jun 2002, James Kempf wrote:
On Tues. afternoon of IETF 54 13:00-14:00, there will be a BOF held
IP Security, for one. The current IPsec can be used, though
it's pretty cumbersome due to (a) large number of similar SAs
needed for manual keying due to destination address being a
part of SA lookup and (b) chicken-and-egg problem for IKE.
The problem (a) could be solved, and the result
Erik,
I know there is considerable prejudice against SLP as a solution to the
general problem, but it certainly is available. It supports discovery
without a 3rd party. The only definitive criticism that I've ever heard
about SLP is the coupling of a directory service function with service
Okabe-san,
Good observation. I believe we have the rough concensus (in the MIP
group at least). The running code is needed yet.
jak
- Original Message -
From: OKABE Nobuo [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 31, 2002 8:35 AM
Subject: Re: Mandating Route
Hi Charlie,
One reason might be that the correspondent node has detected an attempt
to divert traffic to a node which does not legitimately possess the home
address is is trying to divert from. A sysadmin might want to shut off
route optimization until the attacker was discovered or gave up.
.
jak
- Original Message -
From: James Kempf [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; OKABE Nobuo [EMAIL PROTECTED]
Sent: Sunday, June 02, 2002 5:45 PM
Subject: Re: Mandating Route Optimization
Okabe-san,
Good observation. I believe we have the rough concensus (in the MIP
Hello Charles,
In addition to whatever private mail expressions you may have
received,
I should point out that it is highly inappropriate for working group
members
in one working group to supply possibly biased information about the
general state of consensus in another working group. I
Yes, that is correct. Something that is a MUST shouldn't just be an
optimization, it should be necessary for correct, interoperable
implementation.
This leaves open whether to make it MAY or SHOULD. By making
it SHOULD, we make a strong statement that it is necessary for
best operation. MAY
Hi Charlie,
There are at least three kinds of inputs to this process:
data, facts, and opinions.
I've lumped together intuition and expertise under
opinions, and I point out that it is a mistake to
deprecate the latter in the way that some readers of
your note may tend to do. With this
Brett,
OK, thanx that wasn't clear to me. I agree that the number of links will
increase. Route optimization certainly will help, and I am not disputing
that.
jak
- Original Message -
From: Brett Pentland [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: Charles E
Charlie,
8.1. Requirements for All IPv6 Hosts and Routers
Since any IPv6 node may at any time be a correspondent node of a
mobile node, either sending a packet to a mobile node or receiving
a
packet from a mobile node, the following requirements apply to ALL
IPv6 nodes (whether
PekkaS,
OK, I think I understand your comments now. We can incorporate them into
the draft. Thanx.
jak
- Original Message -
From: Pekka Savola [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday
HI Pekka,
I'm not sure how this ended up Cc:'ed to ipng but anyway..
IPNG would be the logical working group that would take it on I think,
since it involves a change in RFC 2461.
A few comments:
3.0 Processing Router Solicitations
A router that is configured to provide fast RAs MUST
Pekka,
Thus, this all is really about zero-configuration security. Such
security, by nature, is never strong by the strict definition of
strong, but it can be *much* stronger than the current no-security
situation. Basically, such security can provide quite a lot of
defence against
Keith,
the only way to reliably know a client is if the client presents you
with
cryptographic proof that they sent that message, and you trust the
keying
material on which that proof is based.
Well stated!
jak
Pekka,
I like the idea of stateless DHCP for defaults configuration. Maybe
separating them would be the right thing, as long as it is clear that a
combined addrconf + defaults conf implementation is possible so not to
negatively impact near term deployment prospects.
jak
-
one thing i don't understand is, why do you think it is not a problem
for ARP, and is a problem for ND.
It is a problem for ARP. To be complete, we should have a solution there
too.
jak
IETF IPng Working Group
Pekka,
I completely agree. Additionally, I'd like to see an
infrastructureless solution to be used anywhere possible.
Why? Basically because an infrastructureless solution means
that we can make it to work with zero configuration, while
any infrastructure necessarily needs that either the
Jari,
So, this is getting a little off topic for this list, perhaps
we should move the discussion elsewhere?
Final comments below.
However, I wouldn't like to design the Internet _just_ for
the ISPs and the commercial providers. If I'm a small business
or a home, I want to set-up my
Alex/Jari
After your reply, my expectations confirm more and more that this is
very much of AAA and PANA issue, and much less of securing the ND.
Simple intuition tells me that if AAA and PANA can help authenticate
the access, then ND is subsequently secured.
Not necessarily. As the ND
Alex/Jari,
I would also like this activity to be only a little part of a greater
Securing Neighbour Discovery. For example, RFC 3041 is already
securing the ND somehow: it provides privacy when Ethernet is used.
RFC 3041 has a security by obscurity facet to it. It really isn't
security,
Markku,
This might belong to IPSEC list, but just give a concrete idea about
it, here is a solution sketch...
Securing ND with existing IPSEC (kernel) only needs to agree on
specific SPI to use and, assuming a special key management daemon,
which would do the following tasks
- inputs
Maybe I'm showing my ignorance here, but how does the host install
this
SA without doing ND? Use the multicast SA to bootstrap?
The special ND key manager generates the keys and installs the SA's
directly. It does not communicate with other hosts at all. Of course,
the key generation
Your attacker is often a legitimate user of the link.
Right, that's the point I was trying to bring up in my response to Alex.
Just because someone has undergone
AAA successfully doesn't mean that they won't disrupt the link.
A person who's trusted on the link can forge packets from any
Erik,
I might have missed this point, but let me ask the question just in case
it hasn't been asked.
One of the purposes of reserving this bit is to avoid bidding down
attacks in Mobile IPv6 binding update security, whereby an attacker
requests a less secure method so it can mount an attack.
Hi Alex,
Sorry its taken so long to get back to you.
The threat document points out valid security concerns with ND. IMHO,
some are easy to deal with and some other are harder, but in any case
not all require total application of the ABK mechanism, noting that
even if ABK's are applied
John,
I think some 90% of the new cellphones, even low end, now have Java on
them. Carriers like it.
But the last spec I saw for the Java MidP (the Java profile that runs on
a cell phone) did not have
a way to open a socket. You could only go through a URL. That may have
changed. So I think it
Margaret,
I don't think that we should publish an informational document that
advises some implementors to do something that specifically
disagrees with a MUST requirement in a standards-track document.
If the standards-track document is broken, we need to fix it
instead.
DAD has a
Pekka,
Related to the debate on the mobile-ip list on whether
MIPv6 should use Routing Header or some other mechanism
to carry the home address to a mobile node that is
away from home, I'd like to solicit for well grounded
opinions on the intended semantics of the Routing Header.
To
I hum as well.
jak
- Original Message -
From: Richard Carlson [EMAIL PROTECTED]
To: Brian E Carpenter [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, January 03, 2002 9:08 AM
Subject: Re: Where are the WG chairs when we need them? [was Re: Flow
Label]
I hum for this.
Brian,
Comments embedded.
I have discussed the flow label with product designers. They are
ignoring
it because the words in RFC 2460 are fuzzy. Yet the IESG has approved
two standards track documents (RFC 2205 and the diffserv MIB) with
specific uses for the flow label in support of the
Margaret,
Given there seems to be so much contention around Tony's proposal,
I agree that Scott's minimal definition along with removal
of Appendix A is a viable alternative.
jak
- Original Message -
From: Margaret Wasserman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent:
Agree.
jak
- Original Message -
From: Brian E Carpenter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 27, 2001 7:43 AM
Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label]
Taking Scott's suggestion, here's another try:
I'd like to propose the
James Kempf [EMAIL PROTECTED] writes:
The most compelling application I've seen is
for QoS classification when the packet
is encrypted. Most of the other applications
people have cited can probably be handled
by other means, as you point out.
Can't we do classification
Scott,
the difserv field is not encrypted so I am not compelled by this
example
If by this you mean that the flow label is not covered
by AH then I agree that this is a weakness in the flow label proposal.
The end node cannot check that the flow label wasn't changed
in transit. To really
Scott,
The traffic field gives the classification. The flow label
could serve as a proxy for the port number and
protocol type,
the whole point of class-based QoS is to not have to deal at the
port and protocol level
Good point, thanx for the clarification.
Perhaps there is some
If by this you mean that the flow label is not covered
by AH
nope - I mean that it is not encrypted thus it can be seen by the
routers
Ah, I think I see what you are getting at.
The transited network can see the source/destination address,
and the flow label. Thus, if the flow
Pekka/Jari,
Thanx for the additional threats and the references. I will fold them
into the document on the next revision.
With regard to:
As with IPv4 and ARP (e.g. gratuituous ARP), it may be that the most
issues cannot be solved, at least without resorting to IPSEC. But that
is
perhaps not
I submitted draft-kempf-ipng-netaccess-threats-00.txt last week on Tues.
but got email from odin.isi.edu on Wed. that the mail had been delayed,
so I am not sure whether it got in on time. The actual email from the
Internet Drafts saying it was received arrived on Thurs. I have not seen
an
Erik Nordmark and I have co-authored a draft on security threats to
public multi-access IPv6 networks, like, for example, a wired or
wireless public access Ethernet. The draft describes a collection of
threats and what mechanisms in RFCs 2461 and 2462 the threats attack,
but does not specify any
62 matches
Mail list logo
