Subject: [BEHAVE] draft-chen-behave-rsnat-01

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 11:24:23 +0200

Hi,

About the stuff that was just presented: unless I'm mistaken, the  
proposal is to add NAT-related path attributes. I think that's  
inappropriate, because it's highly likely that these attributes would  
leak out to the internet routing system, which would be highly  
inappropriate.

This should be a separate address family or a separate BGP message  
type to separate this info from normal NGP routing.

---

From: Chen Gang <[email-masked]>
Date: Tue, 28 Jul 2009 22:08:29 +0800

Hello lijitsch,

Please see my reply inline.

2009/7/28 Iljitsch van Beijnum <[email-masked]>

> Hi,
>
> About the stuff that was just presented: unless I'm mistaken, the proposal
> is to add NAT-related path attributes. I think that's inappropriate, because
> it's highly likely that these attributes would leak out to the internet
> routing system, which would be highly inappropriate.

=>We have discussed to define new capability attribute in the mail-list
before. I guess this approach could avoid leaking mapping information into
interent routing system.

>
>
> This should be a separate address family or a separate BGP message type to
> separate this info from normal NGP routing.

=> Mapping information distribution could be done in the side of initiator's
network.For example, in IPv6-IPv4 translation scenario, mapping information
could be distributed based on IPv6 BGP message.

Thanks for the discussion.

Gang

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 21:12:47 +0200

I have reread the draft.

If I understand correctly, the idea is to use BGP to synchronize state  
between multiple stateful translators, where each translator handles a  
part of the address space used in translation at any time. Many people  
will argue that this deviates too far from BGP's purpose.

I can see that argument, but rather than convince you to not use BGP  
for this, I would like to explain that _if_ you're going to use BGP  
for this, you'll have to think about how to do that.

What you need is for mapping information to be exchanged that consists  
of IPv4 and IPv6 source and destination addresses and ports and the  
protocol. That's 9 items. You can probably optimize a few of them  
away, but using the normal IPv4 address family would require you to  
encode the remaining information in a new path attribute. However,  
this doesn't work: if translator A has a mapping from 2001::2001 to  
192.0.2.1 and translator B from 2002::2002 to 192.0.2.1, then if they  
both announce this to translator C, C would not combine this  
information but rather select either the info from A or from B.

(And you define the attribute as transitive, which means that it would  
be propagated in eBGP, which is unnecessary and has the potential for  
problems when the information leaks.)

What would work better here if you defined a new address family that  
consists of the concatenation of source address, source port,  
destination address, destination port. This could be either IPv4 or  
IPv6. Then the other protocol version addresses and ports plus the  
protocol number would be encoded in a path attribute. This way, each  
mapping would be a separate NLRI in the new AFI and there would be no  
problem merging the information.

---

From: Chen Gang <[email-masked]>
Date: Wed, 29 Jul 2009 22:15:49 +0800

Hello lijitsch van,

Please see my reply in line.

2009/7/29 Iljitsch van Beijnum <[email-masked]>

> between multiple stateful translators, where each translator handles a part
> of the address space used in translation at any time. Many people will argue
> that this deviates too far from BGP's purpose.

=>The intention choosing BGP is targeting to IPX Internet to IPY Internet
scenario, in which BGP is quite suitable.

>
>
> I can see that argument, but rather than convince you to not use BGP for
> this, I would like to explain that _if_ you're going to use BGP for this,
> you'll have to think about how to do that.

=>Thanks

>
>
> What you need is for mapping information to be exchanged that consists of
> IPv4 and IPv6 source and destination addresses and ports and the protocol.
> That's 9 items. You can probably optimize a few of them away, but using the
> normal IPv4 address family would require you to encode the remaining
> information in a new path attribute. However, this doesn't work: if
> translator A has a mapping from 2001::2001 to 192.0.2.1 and translator B
> from 2002::2002 to 192.0.2.1, then if they both announce this to translator
> C, C would not combine this information but rather select either the info
> from A or from B.

=>  New defined attribute processing will guarantee the synchronization work
done. Why can't translator C do the combination things?

>
>
> (And you define the attribute as transitive, which means that it would be
> propagated in eBGP, which is unnecessary and has the potential for problems
> when the information leaks.)

=> For avoiding information leaks, how about define new capability
attribute?

> consists of the concatenation of source address, source port, destination
> address, destination port. This could be either IPv4 or IPv6. Then the other
> protocol version addresses and ports plus the protocol number would be
> encoded in a path attribute. This way, each mapping would be a separate NLRI
> in the new AFI and there would be no problem merging the information.

=> Extending BGP might be a light-weight way to do mapping thing. Could you
provide more detailed explanations for defining a new address family?

BRs

Gang

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Jul 2009 16:57:51 +0200

> => For avoiding information leaks, how about define new capability  

The leaking would happen by a router that has the capability towards a  
router that presumably doesn't have the capability, the capability  
mechanism doesn't protect against that on its own.

> Could you provide more detailed explanations for defining a new  
> address family?

Have a look at RFC 2547, especially section 4.1.