Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 16 Nov 2004 10:12:16 -0800

Marcelo,

Comments inline..
 
  > 
> > I had a few comments/questions on this draft. Sorry if some of them
> > have already been
> > asked (i did not look closely at the archives).
> >
> > 1) In section 1,
> >
> >    In addition, it should also be noted that it
> >    is not required that all interface identifiers of the addresses of
> > an
> >    HBA set are equal, preserving some degree of privacy through changes
> >    in the addresses used during the communications.
> >
> > To create all addresses (for various prefixes) with same interface
> > identifiers, what is the
> > change that would be needed ? Does including the multi-prefix
> > extension and removing the subnet-prefix
> > in the second hash calculation (Hash1 in CGA draft) sufficient ?
> 
> Yes, but this imply not to be compliant with CGA spec.
> in other words, if we are compliant with CGAs, the iid will be
> different and it wouldn't be possible to have equal iids
> 
> we felt that cga compatibility was more important than supporting equal
> iids in the HBAs of a given set (note that we do see some value in
> having equal iids, for instance for simplified management, but this
> cannot be provided in the CGA format)
> 
I thought we have 3 different types of addresses now. The procedure to
compute the hash is different depending on HBA or CGA  i.e include the
public key or extended modifier depending on CGA or HBA. So, why does
it matter if we can specify something different for HBA address ? Both ends
know they are operating on an HBA address. So, what is the compatibility
issue ? Could you elaborate on that ?

> >  It might be worth mentioning the procedure.
> >
> > 2) If HBA is used and the node wants RFC 3041 privacy addresses, it
> > means that it needs to
> > periodically regnerate the HBA ?
> 
> i think so
> 
> >  Though this is more expensive than RFC 3041 privacy addresses,
> 
> I guess that it depends in the Sec value...
> If Sec =0 then i guess than generating an HBA is similar to generate a
> random number. I mean, you only need to add 1 to the modifier and
> perform a hash operation (probably generating random addresses requires
> a similar effort)
> If Sec>0 then i agree
> 

Agreed.

> > there is not much we can do here i guess. Perhaps, this should be
> > mentioned somewhere.
> >
> 
> Ok, i will mention this in the privacy consideration, thanks
> 
> > 3) In section 2,
> >
> >       First, the current Secure Neighbor Discovery specification [2]
> > uses
> >       the CGAs defined in [1] to prove address ownership.  If HBAs are
> > not
> >       compatible with CGAs, then nodes using HBAs for multihoming
> > wouldn't
> >       be able to do Secure Neighbor Discovery using the same addresses
> > (at
> >       least the parts of SeND that require CGAs).  This would imply
> > that
> >       nodes would have to choose between security (from SeND) and
> >       reliability (from multi6)
> >
> > What do you mean by reliability here ?
> 
> fault tolerance i.e. the fault tolerance and other features provided by
> the  multi6 protocol based on the usage of HBAs
> 
> i will try to reword this in the draft
> 
Okay.

> >
> > 4)When the multi6 state is setup, i assume that the CGA parameter is
> > exchanged between the
> >   communicating parties.
> 
> if you mean the CGA parameter data structure including the multiprefix
> extension, then yes
> (BTW i need to state this explicitly in the draft)
> 
Yes, that's what i meant. I assumed that whatever is not there in this
draft is present in one of the other 5 drafts :-)

> > I was wondering whether it would make any difference between including
> >   the prefix Vs the whole address itself in the CGA parameter data
> > structrure ?
> 
> i am not following you here.
> The CGA parameter data structure is used to generate the iid of the
> addresses, so how can you include the complete address in it if you
> still haven't generate it yet.... i am probably missing your point here
> 
I mean, you can generate the address and include it..but it is not needed as
you mention below..

> >  I am not able
> >   to see anything less secure by including the whole address itself.
> > One possibility is that
> >   the peer can compute and validate the address ahead of time (which
> > is of no use if rehoming
> >   will never occur) and hash verification becomes a simple comparison
> >   when a packet with different locator comes in.
> 
> but this can be done with the current CGA parameter data structure,
> right?
> i mean, the HBA set generation only uses the info contained in the CGA
> parameter data structure, so once the peer has the CGA parameter data
> structure, it can regenerate the whole HBA set before the rehoming, as
> you suggest.
> 
> i mean, i think you can do this that you suggest already
> 
Agreed.  I was thinking in a slightly different direction which may not
be needed i guess. Somebody in one of the multi6 meeting raised a point about
computing the hash and verifying it as expensive. First, the hash is not computed
always i guess. Only after the rehoming occurs. But once the rehoming occurs, you
have to recompute always as long as the locator does not match the ULID. Is that right ?
Then i was wondering whether it is a real problem because it affects the fast path processing
of the packet. Perhaps not because it can be pre-computed. But it may not be necessary
i guess. The first packet after rehoming will trigger the hash computation, but that can
be cached i guess. Hence the subsequent packets can be compared directly
with the cached value. Does that make sense ?

> >   I am not saying we should do it this way.
> >   I was mainly trying to understand what it means  to include the
> > address instead of prefix.
> >
> >
> > 5) Security considerations need to be improved.
> 
> agree
> 
> >  It would be good to discuss what attacks it
> >    addresses with respect to the threats document.
> 
> agree, but note that HBAs are not a complete multihoming solution, and
> are useful to prevent certain attacks, not all the threats described in
> the threats drafts
> 
> > In the beginning of the document,
> >
> >       This memo describes a tool that can be used to provide
> > protection against some
> >       of the potential attacks, in particular against future/
> > premeditated
> >       attacks (a.k.a.  time shifting attacks in [6]).
> >
> >    I hope the future version of the document would explain more on
> > this. Is there a document
> >    that explains what threat needs to be addressed by multi6 solution
> > ? (the threats document
> >    mentions this in a few places, but does not look like requirements
> > to me).
> 
> well, i guess that the arch document that we are suppose to write next
> should at least specify the security goals that the designed solution
> is trying to achieve
> 
That should be  sufficient.

> >
> >    One of the inferences from the security consideration section is
> > that the attacker cannot create an HBA
> >    set given a set of victim's addresses. It was not very obvious by
> > reading the security consideration section.
> >
> 
> agree, i will include an example of usage and possible attempts of
> attacks, and see if this improves this point
> 
> >    Also, how important is return routability for the locators  before
> > they are used ? It is not discussed here.
> >    As it is hard for the attacker to redirect packets to a victim, is
> > it needed ? Can it be optional ?
> 
> very good point
> HBAs are mainly used to prevent hijacking attacks and to prevent
> flooding attacks. We will need reachability tests to prevent flooding
> attacks. I will include this also in the doc.
> 
I am not sure i understood the above sentence. First you say that HBA can
be used to prevent flooding attacks and then you say that we need
reachaility tests to prevent flooding attacks. 

-mohan

> Thank you very much for your constructive comments
> I hope i can address them in a satisfactory manner in the next version.
> Please let me know if i wasn't successful
> 
> regards, marcelo
> 
> >
> > -mohan
> >
> >
> ------------------------------------------
> Please note that my former email address
> [email-masked] is no longer in use
> Please send mail to:
> marcelo at it dot uc3m dot es
> ------------------------------------------
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 Nov 2004 19:37:49 +0100

below...

> issue ? Could you elaborate on that ?

Well, the HBA is defined always (in the 3 cases) as an extension of the 
CGA.
i agree with you that we could define the HBA as an extension of the 
CGA when the CGA is also used (i.e. the HBA/CGA hybrid) and define the 
HBA in a different way when the CGA are not used (HBA only mode)
But i am not sure this is worthy, since i guess it would be more 
complex since you need to handle multiple generation algorithms, 
depending in the case. suppose the case when a a communication has a 
CGA/HBA and a HBA only in the other side, this would probably would be 
more complex either. I mean, having a different generation for the 
generation of the HBA only case would essentially provide that all the 
iids are the same in an HBA set, but with an additional complexity in 
the implementation, do you think that it is worthy?

> of the packet. Perhaps not because it can be pre-computed.

>  But it may not be necessary

Yes,
I mean, i would do the following.
first the communication is set up, and at some moment in time the CGA 
parameters are exchanged. For now, no hash calculation.
Suddenly, an different locator needs to be used. So at this point, i 
would run the verification process, implying a hash calculation.
then as long this is the locator that is used, i don't think that 
additional verification are needed, you just need to remember that this 
locator is OK
So, i would say that for a HBA set with n prefixes, the maximum number 
of hash verifications needed is n (independently of the number of 
packets exchanged with each locator)

> I am not sure i understood the above sentence.

well as it is stated it is impossible to understand (i am sorry for 
that)

What i wanted to say was:

HBAs are mainly used to prevent hijacking attacks.
We will need reachability tests to prevent flooding
attacks.

However, an additional consideration about this...
Note that if HBAs are used, flooding a specific target host is very 
difficult, since i would need to find an HBA set that contains an 
address with the attacker prefix and that the address of the victim is 
included in the HBA set, agree?

this is very difficult (O^(59+(16*Sec)) difficult

However, the flooding attack can be easily directed to the access link 
or access router of the victim, since the attacker only need to include 
the prefix of the victim's network in the prefix set.

This means that the resulting HBA set won't contain any address of a 
real host within the victim's network, but in any case the flood will 
be routed to the access router of the victim's network flooding the 
access link and the access router.

So even if the flooding attack is slightly different, i guess that it 
would still make sense to provide some protection from it, agree?

regards, marcelo

>  First you say that HBA can

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Nov 2004 21:26:45 +0200

Hi Mohan, and thanks for your comments. Some discussion

> issue ? Could you elaborate on that ?

Actually, I believe the intent is to have just one address
format, basically according to the SEND CGA draft with some
optional data that is going to make things easier in some
cases. So the cases that we have are:

   - CGA format + pure CGA: all rehoming events require a PK operation
   - CGA format + pure HBA: a set of fixed prefixes is included and
     no other addresses than the fixed ones are expected:
     all rehoming events can be done with a symmetric
     crypto
   - CGA format + HBA + CGA: as above, but if you need to
     go beyond the originally listed address set you can
     switch to using the public key

As for the interoperability problem -- at least my
main issue is that IPv6 components such as SEND or MULTI6
do not require you to allocate different addresses; that
you can actually use both features at the same time. You
could of course do this so that MULTI6 module decides to
use the CGA format if it also wants to do SEND or does
not know the set of prefixes beforehand, and HBA format
otherwise. But using a single format seems simpler. Plus
I actually like the fact that the IIDs are different :-)

> with the cached value. Does that make sense ?

I think we need to treat fast path for payload packets and
signaling differently. Either at the beginning or at a
rehoming event there's going to be some signaling. I don't
believe fast pathing this signaling is going to be necessary.
However, once you have determined that an address belongs to
the peer (either through HBA or CGA proof), presumably you
should be able to set up whatever processing of fast path
mechanism you need for packets arriving with any of the legal
address pairs. And in the worst case all of these pairs are
going to need a mapping from the on-the-wire address pairs to
the ULID pairs. So, conceptually, if you receive the "M6 header"
then you do the mapping. This should be fast too, I think.
But if you receive an indication of a problem or some message
from the peer claiming that it has changed its address, that
is going to need at least a hash operation as well as some
amount of data structure modifications in the stack.

> reachaility tests to prevent flooding attacks. 

Reachability tests are needed to prevent flooding attacks,
because HBA and CGA techniques can only show that you generated
the address, not that you actually are on the link. HBA/CGA
on the other hand is needed to ensure that you can't hijack
any else's address. The "victims" in these two cases are
different: in the first case its third parties, in the
second case it is an "owner" of an address.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Nov 2004 21:38:34 +0200

Hi Marcelo,

> packets exchanged with each locator)

I agree that you do not wish to verify HBA or CGA on a per-packet
basis. (If that were the case, it would be horrible.)

As for the number of hash verifications, it would seem that
you only have to verify those addresses that you actually use
for exchanging packets with the peer. That is, if there is no
problem you don't necessarily have to verify anything. And
if you have a problem, it suffices to test the addresses
that you actually end up switching to instead. (I'm still
wondering whether the test packets sent to address X need
verification of X; there may be some denial-of-service issues
if we don't do that.)

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 16 Nov 2004 13:19:46 -0800

> I actually like the fact that the IIDs are different :-)
I don't have any problems with IIDs being different :-) But i was more
trying to understand the compatibility problem.  Multi6 module anyway
has to do different processing if the address is a HBA address or
if it is a CGA/HBA address. Now you can still use the same format for
generating a single IID for all the prefixes e.g. using all zeroes or all
ones for the subnet prefix field of the CGA parameters data structure.
(but including the multi-prefix extension at the end as specified now)
Assuming we can find such a thing, would it be considered simpler ?

Agreed.

> second case it is an "owner" of an address.
This flooding attack is slightly different from the one mentioned in the
threats document because there is no real victim invovled. Just the
routers and links which still needs to be prevented.

-mohan

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Nov 2004 14:53:33 -0800

> Assuming we can find such a thing, would it be considered simpler ?

But then the IID(s) needed for SeND would be different than the IID(s) 
needed for multi6, right?

Then which of the addresses (with which IDD) would a host which wants to 
take advantage of both SeND and multi6 at the same time use?
Which addresses would it put in the DNS for itself?

     Erik

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 16 Nov 2004 17:34:03 -0800 (PST)

Erik,

> Which addresses would it put in the DNS for itself?
If you want to have an address that can be used both
by SEND and Multi6, then you would generate an address
that includes both the public key and multi-prefix
extension as defined now. But my original question
was more specific to HBA addresses that can be
generated for all prefixes with the same identifier.
HBA only addresses anyway requires slightly
different processing. So, i don't know what
the issue is with generating the same identifier,
if needed or someone finds a use for it.

I realize that if a node wants to use SEND and multi6,
then the easy way to do is to generate a CGA/HBA
address. Otherwise the issues that you raise above
needs to be solved.

-mohan

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 17 Nov 2004 17:10:55 +0100

> routers and links which still needs to be prevented.

perhaps it would make sense to mention explicitly in the threats 
document that the target of a flooding attack may not be a host but an 
access link or an access router?

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 17 Nov 2004 17:13:49 +0100

Hi Jari,

> verification of X; there may be some denial-of-service issues

The question would be: do we do the reachanility test first or the HBA 
verification first? is this what you have in mind?

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 17 Nov 2004 17:06:41 +0100

Hi all,

With respect to the HBA format i guess that we can comment that:
- It is clear that it is valuable to support hybrid HBA/CGA format, in 
order to be able to do SeND and multi6 with the same address.
- In order to do this we need to define the HBA as a CGa extension, at 
least in this particular case
- This implies that the iids of the addresses of an HBA set will be 
different
    - This is good because it provides enhanced privacy
    - This may imply a more difficult management and would preclude
      solutions based on source address rewriting by the site exit
      router

Now w.r.t. HBA only addresses.
I guess we could define a different format for these, so that the same 
iid is maintained though the different addresses of an HBA, but this 
would imply an additional complexity. the cause of this complexity is 
that a node would need to support BOTH formats. This is so becuase it 
is difficutl to say that for instance fixed hosts won't need CGA 
features, since they are usefull to support renumbering events. 
Moreover, a given node may choose to use only HBA, but its peers may 
choose to use HBA/CGA addresses, so any node will have to understand 
both formats.
There have been concerns about the complexity of even implementing HBAs 
as an extension, i guess that these concerns would be greater if two 
different formats are proposed.

So sumarizing, the trade off as i see it is:

one common format provides less complexity, (only one format is 
required)
two formats provides same iids in the different asddreses in the HBA 
set. Soem people not even want this, so i guess that we would need to 
define privacy extensions for this format ( i have done this and it is 
just like CGA format)

i would prefer one format, becuase imho simplicity is important

regards, marcelo

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Nov 2004 18:56:30 +0200

> verification first? is this what you have in mind?

That was the question I had. It seems that it would be best
if you could verify HBA/CGA first and only then send a packet.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Nov 2004 18:58:23 +0200

> access link or an access router?

I agree that the target can be not just a host but also a link,
router, or a network. If the threats document claims otherwise
then it needs to be corrected.

Of course there are some differences in the
threat to a host and to a network, but if you move
someone's DVD download on my GPRS link, I'm hosed whether or
not the target address is my host's address.

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Nov 2004 09:58:13 -0800

> if needed or someone finds a use for it.

OK - sorry for misunderstanding.

I think Marcelo stated the issues today.

What do you see as the benefit of having the same iid for all prefixes?

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Nov 2004 10:00:01 -0800

> access link or an access router?

What do others think? I'll send in an updated threats document later 
this week (just waiting for an answer from Rob Austein) so if folks want 
a clarification about this let me know soon.
(And text to include would be appreciated as always.)

   Erik

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 17 Nov 2004 12:42:24 -0800 (PST)

> What do you see as the benefit of having the same
None :-) I was only trying to find out the reason
as to why this can't be done or easily supported
without changing the format. I am fine with having
different IID for different prefixes. The reason
that we don't want to support same IID could be
that we don't see any use for it or that it is
simplicity or something else. I was just trying
to understand that.

-mohan

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Nov 2004 11:32:32 +0100

> (And text to include would be appreciated as always.)

I wouldn't object to this being included, but flooding attacks
on generic targets are kind of a generic Internet threat anyway.
I'd want to see text that very explicitly says why this is
a threat *made worse* by the presence of multi6.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Nov 2004 12:37:27 +0200

> a threat *made worse* by the presence of multi6.

Right. And I think we have that explanation, it relates
to amplification. There's plenty of documents that
can be referenced regarding this issue from the threats
doc. See for instance draft-ietf-mip6-ro-sec-02.txt
Section 3.2.1, draft-vogt-mipv6-credit-based-authorization-00.txt
Section 3, Aura et al: "Security of Internet Location
Management" (ACSAC), etc.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Nov 2004 14:14:40 +0100

In your previous mail you wrote:

   
   
=> no, HBA idea has two parts:
 - an instance of the extensions (for this part HBAs are a subclass of CGAs)
 - a pseudo-public key (this removes only the ownership stuff, not
   the verification, of course this is optional).
All the hash and signature stuff is exactly the same, so the IID(s).

=> HBAs with a real private/public key pair which are an extension of CGAs.

=> the HBAs.

Regards

[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 18 Nov 2004 15:03:59 +0100

El 17/11/2004, a las 17:56, Jari Arkko escribió:

>> The question would be: do we do the reachanility test first or the 
>> HBA verification first? is this what you have in mind?
>

agree

regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Nov 2004 18:14:32 +0100

> without changing the format.

There are two reasons it is good to have the same IID for different 
prefixes:

1. At some point in the future, we may want to have routers rewrite the 
prefix part in the source addresses of outgoing packets. This is a very 
good way to deal with ingress filtering. However, it is unlikely that 
routers could hold all the state necessary to match individual 
addresses rather than prefixes. (Note that we are NOT proposing router 
rewriting at this point.)

2. Easier debugging.

The reason you can't have the same IID in different prefixes for CGA is 
that in CGA the prefix is part of the data the hash is computed over. 
The reason the prefix is included is because otherwise someone could 
precompute all possible hashes.

It would be possible to include one chosen prefix rather than the 
"real" prefix, though. This way out of N addresses there would be one 
that is SEND-compatible and N-1 that aren't. The SEND-compatible 
address could be the ULID. Not having SEND for additional locators 
wouldn't be too much of a hardship, IMO.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 18 Nov 2004 16:47:22 -0800

Iljitsch van Beijnum wrote:

> routers could hold all the state necessary to match individual addresses 
> rather than prefixes. (Note that we are NOT proposing router rewriting 
> at this point.)

It's far from clear to me that, should we pursue router rewriting in the 
future, that it can operate without being aware of individual hosts 
addresses.

The issue is coordination with what the hosts thinks are their locator, 
and what host addresses the hosts can "prove" the the peers is their own.

For instance, if you have a site with 7 prefixes but some small devices 
only choose to use 3 of them, and form HBA addresses using those 3, then 
if the routers rewrite the source locator to any of the other 4 prefixes 
then it might result in a complete failure to communicate since the peer 
might ignore the "spoofed" packet coming from an invalid source locator 
of the host.

Likewise during graceful renumbering; when a site with multiple prefixes 
adds or changes a prefix, when can the router start rewriting to the new 
prefix (and must stop rewriting to the old prefix, which might happen at 
a different time).

If a router doing rewriting maintains per-host state, for instance using 
the same multi6 protocol as is used e2e, then it can stay in synch with 
the prefixes/locators that the host is actually using.

    Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Nov 2004 10:25:03 +0100

Erik Nordmark wrote:
>> 1. At some point in the future, we may want to have routers rewrite 
>> the prefix part in the source addresses of outgoing packets. This is a 
>> very good way to deal with ingress filtering. However, it is unlikely 
>> that routers could hold all the state necessary to match individual 

I agree. It also seems to me that requiring the same IID for all
interfaces is architecturally wrong, and will cause significant
difficulty anyway, for example in virtualized server networks where
there is no fixed linkage between a host's identity and the machine
or physical interface it happens to be assigned to at the moment.

     Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 19 Nov 2004 12:00:22 +0100

On 19-nov-04, at 1:47, Erik Nordmark wrote:

> It's far from clear to me that, should we pursue router rewriting in 
> the future, that it can operate without being aware of individual 
> hosts addresses.

Maybe not, but there is also the possibility that it could work 
per-prefix but not per-host.

> For instance, if you have a site with 7 prefixes but some small 
> devices only choose to use 3 of them, and form HBA addresses using 
> those 3, then if the routers rewrite the source locator to any of the 
> other 4 prefixes then it might result in a complete failure to 
> communicate since the peer might ignore the "spoofed" packet coming 
> from an invalid source locator of the host.

I think it's possible to solve this. We've been talking about a bit 
that indicates (among other things) that rewriting is allowed. For a 
long time, I've been saying that we could use the prefix in the source 
address for this. So magic prefix = rewrite, regular prefix = don't 
rewrite. We can reserve some bits in the magic prefix that indicate the 
type of rewriting that's allowed. For instance, if the prefix is 
<iana:32><x:16><subnet:16><iid:64> then we can encode permission to 
rewrite to one or more of 16 different prefixes. There is the slight 
problem of having all systems involved know which prefix corresponds to 
which bit of course, but this should be doable.

On 19-nov-04, at 10:25, Brian E Carpenter wrote:

> It also seems to me that requiring the same IID for all interfaces is 
> architecturally wrong,

I certainly wouldn't want to require this, just allow it.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Nov 2004 10:42:28 -0800

Iljitsch van Beijnum wrote:

> I think it's possible to solve this. We've been talking about a bit that 
> indicates (among other things) that rewriting is allowed. For a long 
> time, I've been saying that we could use the prefix in the source 

Such an approach would require there to be a source locator rewriting 
router in the path, right?
If the above funny prefix isn't rewritten in the path the peer will not 
be able to respond AFAIK.

Since we want to allow incremental deployment of any multi6 technology, 
such an approach would require that the host can find out
  1) whether there is a source locator rewriter out there
  2) whether the source locator rewriter is in the path to reach a
     particular destination (for instance, the path to a destinations
     within the site may or may not go through a rewriter)

If the host needs to probe the network per destination locator to answer 
#2, we might as well have the answer tell the host which is the 
preferred source locator to use so that there is no actual rewriting 
along the path. (Yes, there are some subtle differences should the path 
change.)

The above complexity combined with Geoff's observations that in real 
networks today it is hard to define which is the "site border router" 
which would do the rewriting, makes me personally think that locator 
rewriting along the path might not be worth to complexity even in the 
future.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Nov 2004 11:10:44 -0800

Since nobody suggested text, I've added the second paragraph below in 
section 4.3:
<existing paragraph>
An attacker can use the ability to perform redirection to cause
overload on an unrelated third party.  For instance, if A and B
are communicating then the attacker X might be able to convince A to
send the packets intended for B to some third node C.
While this might seem harmless at first, since X could just flood C with
packets directly, there are a few aspects of these attacks that cause
concern.

<added paragraph>
Such an attack might be against the resources of a particular host i.e., C
in the example above, or it might be against the network infrastructure
towards a particular IP address prefix, by overloading the routers or links
even though there is no host at the address being targeted.

   Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 20 Nov 2004 10:49:07 +0100

This is good for me

thanks, marcelo

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Nov 2004 16:23:14 +0200

Hi Erik,

Your text looks good.

--Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Nov 2004 13:43:00 +0100

[catching up]

Erik Nordmark wrote:
>> rewrite. We can reserve some bits in the magic prefix that indicate 
>> the type of rewriting that's allowed. For instance, if the prefix is 
>> problem of having all systems involved know which prefix corresponds 
>> to which bit of course, but this should be doable.
> 
> 

For me, encoding semantics in the address in any way is an architectural
red alert. It always comes back to bite. With multipath routing and
virtualized IP addressing common, I just don't see how to ensure
consistent behaviour (i.e. I don't see how to make it one atom better
than NAT).

    Brian