Subject: [RAM] Re: [arch-d] Major practical decision

From: David Conrad <[email-masked]>
Date: Sat, 9 Dec 2006 20:15:39 -0200

[I've redirected this to [email-masked], bcc'ing arch-d since this is  
talking more about an implementation model than a theoretical model.   
I've gathered the feeling is that discussion about what Noel calls  
the "jack up" approach such as this should occur on ram instead of  
arch-d.]

Marcelo,

Just to be clear, my focus has been to try to come up with a model  
that would minimize the number of changes that would need to be made  
to deployed systems as I believe this significantly improves the  
chances that stuff will actually get deployed.  While I would love to  
see a clean-sheet architecture, I'll admit to being a bit too cynical  
to believe it would ever get deployed.

On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote:
> i am not sure i understand what you have in mind, but the peer that  
> is communicating with host within the multihomed site will need to  
> know the identifier and all the locators, so it can encapsulate  
> with all the different locators, right?

No.  The source "host" would only need to know about the identifier  
of the destination "host" (discoverable via DNS as normal). The  
multiple locators would be bound to the identifier later.  I think it  
is actually fairly important that the "host" _not_ know about  
locators as the alternative is a layering violation that ends up  
causing a lot of problems in the end.

In the model I've argued for, the mapping from identifier to locator  
would occur at the "edge" (where the "edge" could be anywhere from  
the source device to the first hop router to the ISP/end site  
boundary).  At this mapping device/"edge" router, the packet would be  
encapsulated with the destination address being one of the set of  
locators associated with the identifier.  At the destination mapping  
device/"edge" router, the packet would be de-encapsulated and  
forwarded on to the destination identifier.

> If this is the case, the peer (or some box near the peer) needs to  
> support whatever protocol are used to securely exchange the  
> identifier and locator set.

Yes, in the sense that the mapping needs to be propagated somehow,  
either some push mechanism (e.g., a flooding protocol or as a BGP  
attribute or whatever) or a pull mechanism (e.g., something like the  
DNS). If you use the DNS, you could have something like:

; dest identifier                            RR  dst locator pref
1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.loc.arpa. IN LOC a000::0001  100 ...
                                                  b000::0002  200 ...
                                                  c000::0003  300 ...

which could be secured with DNSSEC (assuming it ever gets deployed).

> This box needs to be deployed, hence, we need support outside the  
> multihomed site, right?

I think I see what you're saying.  So, there are 4 cases:

1) unmapped source, unmapped destination: this is what we have now.

2) mapped source, mapped destination: this would be the goal.

3) mapped source, unmapped destination: if the destination is  
reachable via the "legacy" routing system, this would work if the  
mapping service is able to determine that the destination is not  
mapped and fall back to case 1.  For this to work, the source  
identifier would have to be routable, perhaps sub-optimally, in the  
"legacy" routing system.

4) unmapped source, mapped destination: since the source knows  
nothing about mapping, the only way the destination would be  
reachable is if the destination identifier is routable, perhaps sub- 
optimally, in the "legacy" routing system.

Given this, as a transition mechanism, the existing  
"addresses" (which I'm defining to be the merged identifier/locator  
blob of bits we have in the source and destination fields of IP  
packets now) would be treated as identifiers if they are mapped and  
locators if they aren't. The mapping device/"edge" router would make  
the determination on the fly based on whether the mapping succeeded  
or failed.

So, yes, there would need to be some support outside the multi-homed  
site to take advantage of the multi-homing (etc.), but things will  
still work, perhaps sub-optimally, without it.

Rgds,
-drc

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 10 Dec 2006 11:32:49 +0200

> So, there are 4 cases:

This seems to be essentially what I tried to state in one of my  
messages at arch-d but couldn't say as nicely.

I fully agree that we will need transition mechanisms for #3/#4.  The  
details of such transition mechanisms should be designed with  
economics very much in mind, making sure that those that will benefit  
are also those that will cover the costs, either immediately or  
through a very direct and simple value chain.

> locators if they aren't. The mapping device/"edge" router would  
> make the determination on the fly based on whether the mapping  
> succeeded or failed.

I mostly agree.  One difference that I'd prefer is to consider the  
"mapped addresses" as _representations_ of or _handles_ for the  
identifiers, not as the actual identifiers themselves.  (Or,  
alternatively, if we decide to take Noel's jack-up way, the "unmapped  
addresses" would be handles for the locators.)

That is, I'd like to make the new name space genuinely distinct, and  
embed it to the existing name space only in order to make these kinds  
of transition mechanisms to work.  For example, our proposed ORCHID  
mechanisms should be considered as a medium-term transition mechanism  
that allows public keys to be embedded to the IPv6 address space.

> So, yes, there would need to be some support outside the multi- 
> homed site to take advantage of the multi-homing (etc.), but things  
> will still work, perhaps sub-optimally, without it.

I concur.

--Pekka Nikander

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 10 Dec 2006 12:24:51 +0100

El 09/12/2006, a las 23:15, David Conrad escribió:

> I've gathered the feeling is that discussion about what Noel calls the 
> "jack up" approach such as this should occur on ram instead of 
> arch-d.]
>
> Marcelo,
>

yes this is valid goal imho

>> know the identifier and all the locators, so it can encapsulate with 
>> all the different locators, right?
>
> No.  The source "host" would only need to know about the identifier of 
> the destination "host" (discoverable via DNS as normal). The multiple 
> locators would be bound to the identifier later.  I think it is 
> actually fairly important that the "host" _not_ know about locators as 
> the alternative is a layering violation that ends up causing a lot of 
> problems in the end.
>
> would occur at the "edge" (where the "edge" could be anywhere from the 
> source device to the first hop router to the ISP/end site boundary).

i can see that this approach maybe easier to deploy than other 
approaches that require updating all the routers or updating all the 
hosts. This is very clear in the case of the multihomed site, where it 
will install the new box so it can obtain multihoming support wihtout 
need to update its routers and/or hosts. but otoh, i fail to see the 
motivation for a single homed site to adopt such a box. I mean, 
wouldn't be easier in this case to wait for the OS update in the hosts 
and that the OS has build in the multihoming support?

>  At this mapping device/"edge" router, the packet would be 

imho DNSSec is not required for this. It would be nice to have but not 
a must... I mean, if we obtain the ID to locators mapping from the 
insecure DNS we wouldn't be introducing new vulnerabilities to the 
current internet, since a attacker can simply change the FQDN to IP 
address DNS reply and perform similar attacks.

> 4) unmapped source, mapped destination: since the source knows nothing 
> about mapping, the only way the destination would be reachable is if 
> the destination identifier is routable, perhaps sub-optimally, in the 
> "legacy" routing system.
>
> Given this, as a transition mechanism, the existing "addresses" (which 
> I'm defining to be the merged identifier/locator blob of bits we have 
> in the source and destination fields of IP packets now) would be 
> treated as identifiers if they are mapped and locators if they aren't. 
> The mapping device/"edge" router would make the determination on the 
> fly based on whether the mapping succeeded or failed.
>

suboptimaly meaning that it would work without the multihoming 
benefits, right?

Regards, marcelo

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 11 Dec 2006 09:39:41 -0500

> Just to be clear, my focus has been to try to come up with a 
> model that would minimize the number of changes that would 
> need to be made to deployed systems as I believe this 
> significantly improves the chances that stuff will actually 
> get deployed.  While I would love to see a clean-sheet 
> architecture, I'll admit to being a bit too cynical to 
> believe it would ever get deployed.
> 
> > i am not sure i understand what you have in mind, but the 
> peer that is 
> > communicating with host within the multihomed site will 
> need to know 
> > the identifier and all the locators, so it can encapsulate with all 
> > the different locators, right?
> 
> No.  The source "host" would only need to know about the 
> identifier of the destination "host" (discoverable via DNS as 
> normal). The multiple locators would be bound to the 
> identifier later.  I think it is actually fairly important 
> that the "host" _not_ know about locators as the alternative 
> is a layering violation that ends up causing a lot of 
> problems in the end.

This is what I have been saying too on the end-to-end part the host
transport should not be involved with the locators at all.  This would
mean some fixes to SHIM6 but minimal.  

What I do suggest we avoid is routing-name-space lookups when the
locators are determined later past the transport and will for now assume
some caching model as some have implemented IPsec SA database required
for both user and network subsystem space.  Thus source address
selection would be at the point locators are determined.

> 
> In the model I've argued for, the mapping from identifier to 
> locator would occur at the "edge" (where the "edge" could be 
> anywhere from the source device to the first hop router to 
> the ISP/end site boundary).  At this mapping device/"edge" 
> router, the packet would be encapsulated with the destination 
> address being one of the set of locators associated with the 
> identifier.  At the destination mapping device/"edge" router, 
> the packet would be de-encapsulated and forwarded on to the 
> destination identifier.

The above I don't agree with the host node must be involved with sending
the packet to a locator (routing-namespace identifier) if the edge wants
to "re-map" given our new model architecture that is fine as long as the
"destination" address stays in tact.  I also would like to see us avoid
"tunneling" wherever possible.

> Yes, in the sense that the mapping needs to be propagated 
> somehow, either some push mechanism (e.g., a flooding 
> protocol or as a BGP attribute or whatever) or a pull 
> mechanism (e.g., something like the DNS). If you use the DNS, 
> you could have something like:
> 

I do not want to use DNS. Fine as conceptual model but there are
alternatives in the market today and emerging in general for the
principle of "discovery" within networks.

> reachable via the "legacy" routing system, this would work if 
> the mapping service is able to determine that the destination 
> is not mapped and fall back to case 1.  For this to work, the 
> source identifier would have to be routable, perhaps 
> sub-optimally, in the "legacy" routing system.

Destination must be mapped from the space this is a part of the current
architecture that works and far to much to change.

> 
> 4) unmapped source, mapped destination: since the source 
> knows nothing about mapping, the only way the destination 
> would be reachable is if the destination identifier is 
> routable, perhaps sub- optimally, in the "legacy" routing system.
> 
> "addresses" (which I'm defining to be the merged 
> identifier/locator blob of bits we have in the source and 
> destination fields of IP packets now) would be treated as 
> identifiers if they are mapped and locators if they aren't. 
> The mapping device/"edge" router would make the determination 
> on the fly based on whether the mapping succeeded or failed.
> 
> So, yes, there would need to be some support outside the 
> multi-homed site to take advantage of the multi-homing 
> (etc.), but things will still work, perhaps sub-optimally, without it.

I think that can be fixed with a new architecture.  

/jim

---

From: JFCM <[email-masked]>
Date: Mon, 11 Dec 2006 16:45:31 +0100

Dear David,
I agree and documented how a global path and a global locator should 
be supported. Here, I am afraid I disagree on three grounds at least;

1. you do not permit the sender to chose the path what for legal (US 
law) and economic reasons (two-tiered offers) is a need
2. you impose two different processing at two separated places
3. you increase the intelligence in the dumb network.

Dont you fear it might make the proposition attractive enough to 
users, and possibly create scalability problems?
jfc

At 23:15 09/12/2006, David Conrad wrote:

>Architecture-discuss mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: [email-masked]
Date: Tue, 12 Dec 2006 13:48:28 +0100

Hi,

I subscribed the RAM mailing list a couple of weeks ago,
and I think you may be interested in reading the draft on
"Tunneled Interdomain Routing" that I sent to the IETF in
October. My proposal is based on the use a new transitive
BGP attribute that I have called LOCATOR.

You can find the new version of the draft-adan-idr-tidr-01.txt
in the following URL:

http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg13203.html

Regards,
Juanjo

---

From: John Leslie <[email-masked]>
Date: Tue, 12 Dec 2006 19:12:25 -0500

> causing a lot of problems in the end.

   I don't follow why this is necessarily a layering violation.

--
John Leslie <[email-masked]>

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 13 Dec 2006 15:02:59 +0200

> ... I think you may be interested in reading the draft on "Tunneled  
> Interdomain Routing" that I sent to the IETF in October. My  
> proposal is based on the use a new transitive BGP attribute that I  
> have called LOCATOR.
>
> You can find the new version of the draft-adan-idr-tidr-01.txt in  
> the following URL:
>

Interesting, though I have to admit not understanding all the details  
with one casual reading.

If I understand correctly, this is one specific example of the  
approaches that Noel has called "jack-up".

Anyway, a few questions appeared in my mind immediately:

1. How do you think that the proposed AS public keys can be  
distributed; conversely, what is the underlying trust model?

2. What's your overall vision of the configuration of the system?   
How does it differ from current configuration practises?

3. What happens if someone starts to inject maliciously "tunneled"  
packets into the network?

I guess I have to read the draft better with better time; at this  
point I'm just trying to understand if there are any open issues that  
might mean major problems for any approach like this.

--Pekka Nikander

---

From: [email-masked]
Date: Thu, 14 Dec 2006 10:40:57 +0100

Pekka,

Thank you very much for your comments. See my explanations below.

Pekka Nikander <[email-masked]> escribió el 13/12/2006
> approaches that Noel has called "jack-up".

I don't know what "jack-up" means. Can you point me to any resource
on this?.

> distributed; conversely, what is the underlying trust model?

In my opinion Internet Routing Registries should provide for
the certificates that ISPs should use. I say ISPs because, as
I show in the TIDR draft, leaf AS-s would not need to have
public AS numbers. If I am your ISP and you are a leaf AS, I
will be responsible to make sure that you are injecting valid
prefixes, namely prefixes from your assigned IP address block.
And I will include the digital signature within the LOCATOR
attribute using the certificate that I received from the IRR.

> How does it differ from current configuration practises?

As I also show in the TIDR draft, in the end, leaf AS-s would
not need to have public AS numbers and they would continue to
have backup and traffic engineering capabilities. Even more,
they could achieve deterministic incoming traffic engineering.
See section 7.2. in my draft, "Deterministic Customer Traffic
Engineering for Incoming Traffic".

> packets into the network?

If an ISP receives TIDR-tunneled packets from a stub network (i.e.
a current nontransit leaf AS) the ISP will have to discard them.
This can be easily achieved if we assign a specific IP address
range per AS (e.g. an 240.x.y.0/8, with (x,y)=AS number).
See section 7.6. in my draft, "Protection of the Inter-domain
Routing Infrastructure".

> might mean major problems for any approach like this.

Yes, please. Any further comments will be appreciated.

Regards,
Juanjo

---

From: "Sander Steffann" <[email-masked]>
Date: Thu, 14 Dec 2006 10:56:25 +0100

Hi,

> See section 7.6. in my draft, "Protection of the Inter-domain

One big problem: Since 32-bit AS numbers are currently being introduced, 
assuming that an ASN is 16-bits is not possible anymore.

- Sander

---

From: [email-masked]
Date: Thu, 14 Dec 2006 11:29:26 +0100

Sander,

> assuming that an ASN is 16-bits is not possible anymore.

Yes, AS numbers can now be 4-byte long. ("The IESG Approved
the Expansion of the AS Number Registry" on 27-November-2006).

Although what I said in my previous mail was just an "Exempli gratia"
we should not forget that multihomed leaf AS-s are far more numerous
than transit AS-s. I see some possibilities:

1- We reserve 1-64512 for ISPs.
2- We can use TIDR, because with TIDR non-transit multihomed
   AS-s will no longer need any public AS number for backup or
   traffic engineering purposes.
3- We use IPv6 addresses for "locator prefixes" to accomodate
   4-byte AS numbers.

Regards,
Juanjo

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 15 Dec 2006 11:29:56 +0200

> the certificates that ISPs should use. ...
>

These seem to assume that we have

a) a working global certification infrastructure run by the RIRs

b) that all ISPs are diligent in filtering incoming traffic.

AFAIK, neither of these are true today, even after multiple years of  
attempting to build them.

Consequently, I'd like to understand how your proposal would behave  
if you were not able to assume one of those, or either of those.   
Personally, I keep it more probable that the RIRs could establish  
cross-certified certificate infrastructures for their customers than  
that all ISPs would ever be diligent.  Hence, it may be better to  
start from pondering what happens if there are a few ISPs (say 0.1%  
of all ISPS) that are not diligent in filtering their TIDR-tunnelled  
packets, or who may have other motives (such as fraud) so that they  
themselves occasionally inject maliciously formatted TIDR-tunnelled  
packets.

--Pekka Nikander

---

From: [email-masked]
Date: Fri, 15 Dec 2006 11:10:05 +0100

Pekka,

See below.

Pekka Nikander <[email-masked]> escribió el 15/12/2006

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 10:04:06 -0500

> packets into the network?

That is what intrusion detection software and architecture is for and
why I have essential basic issues with HIP and SHIM6 bothering with this
other than due dilliegence to address core network communications
security. Ergo don't see the point of CGA at all.

/jim

---

From: "Chris L. Morrow" <[email-masked]>
Date: Mon, 18 Dec 2006 04:01:15 +0000 (GMT)

> That is what intrusion detection software and architecture is for and

in the core no one can see your traffic ( not an IDS atleast) so this
traffic would get delivered to the end-site (or end-tunnel destination)
before anyone can see it and do 'something' about it. On the other hand,
what would you do with it anyway? Stop the tunnel source? which is perhaps
also spoofed?

---

From: [email-masked]
Date: Mon, 18 Dec 2006 11:44:24 +0100

Pekka,

See below the comments I didn´t send last Friday.

> themselves occasionally inject maliciously formatted TIDR-tunnelled

Yes, some sort of certification infrastructure will be needed.

WRT filtering TIDR-tunneled packets let's assume the following:

Leaf_AS  -  ISP1  -  ISP2

- Two possible methods for ISP1 to filter TIDR-tunneled packets
coming from a Leaf_AS are: (1) discard IP packets sent to any
locator prefix the same as we do with traffic sent to 10.0.0.0/8;
(2) use uRPF to discard this incoming traffic.

- But the point still is: what if ISP1 doesn´t filter tunneled
traffic coming from Leaf_AS?. With TIDR there is no need for
Leaf_AS to use a public AS number: it's a ISP1's task to
announce prefixes residing in Leaf_AS with a LOCATOR pointing
to ISP1. Therefore ISP1 should never receive transit traffic
(i.e. tunneled traffic) from Leaf_AS. In my draft I suggest
the use of different layer-2 encapsulations for transit and
non-transit traffic, so that the layer-2 encapsulation for
transit traffic should only be valid when establishing a
BGP session with another transit AS. And this should be
enforced in some way.

Regards,
Juanjo

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 18 Dec 2006 09:37:29 -0500

> in the core no one can see your traffic ( not an IDS atleast) 
> so this traffic would get delivered to the end-site (or 
> end-tunnel destination) before anyone can see it and do 
> 'something' about it. On the other hand, what would you do 
> with it anyway? Stop the tunnel source? which is perhaps also spoofed?

Good question.  Even in the core and even if the entire payload is
encrypted, meaning a router, switch, et al cannot see anything but the
routing-namespace-identifiers (cannot see the transport layer as today
tcp/port, etc.) there are means to do Deep Packet Inspection (DPI) at
any point in the path to the destination emerging based upon
mathematical models and in-band-signaling for blockage (bad term but for
now use it) thus DOS at least can be seen for intrusion prevention.  The
implementation would use DPI on smart-aware-nodes similar to the current
IETF NSIS architecture and operational model.  This way it does not
effect the actual traffic.

But more importantly I do not believe we should try to solve many of the
security problems or attacks trying to define an architecture for a new
model its just to much to ask when the real prevention of most of what
SHIM6 is addressing and specifically CGA and HBA can be addressed by
intrusion detection/prevention.  

/jim