Subject: Re: (ngtrans) Re: I-D ACTION:draft-ietf-ngtrans-bgp-tunnel-04.txt

From: [email-masked]
Date: Tue, 12 Feb 2002 15:04:50 +0100

Pekka,

see inline

Pekka Savola wrote:
> 
> On Tue, 15 Jan 2002 [email-masked] wrote:
> >       Title           : Connecting IPv6 Domains across IPv4 Clouds with BGP
> >       Author(s)       : J. De Clercq, G. Gastaud, T. Nguyen,
> >                           D. Ooms, S. Prevost, F. Le Faucheur
> >       Filename        : draft-ietf-ngtrans-bgp-tunnel-04.txt
> >       Pages           : 12
> >       Date            : 14-Jan-02
> 
> I've already commented on this, but I'll add a couple of more comments as
> I read it a bit more.
> 
> 4.1. "MP-BGP over IPv4" approach
> 
>    Since MP-BGP requires that the BGP Next Hop is of the same address
>    family as the NLRI, this IPv4 address needs to be embedded in an IPv6
>    format. The IPv4-mapped IPv6 address is defined in [V6ADDR] as an
>    "address type used to represent the addresses of IPv4 nodes as IPv6
>    addresses", thus this precisely fits for the above purpose.  Encoding
>    the routable IPv4 address into a IPv4-mapped IPv6 address allows the
>    remote DS-BGP router to automatically tunnel data over the IPv4 cloud
>    to the destination IPv6 island.  Any type of encapsulation can be
>    used (IPv4, MPLS, GRE).
> 
> ==> Note: the receiving end must have been configured beforehand to be
> recipient of such encapsulated packets, like autotunnel interface, GRE
> interfaces etc.

Correct, but this can also be automated: one could allow tunneled data
from BGP peers that have announced IPv6 reachability information before.

> 
> 4.3. Characteristics Common To Both Approaches
> 
>    When the number of PEs is not too high, PEs MAY peer in a meshed
>    fashion. Otherwise Route Reflectors MAY be used.
> 
> ==> I find these statements (at least in CAPITALS) irrelevant to the
> specification.

I have no opinion on this.

> 
> 8. Security considerations
> 
>    This proposal can use the security features of BGP and any policy
>    defined in the ISP domain.
> 
> ==> rather weak.  E.g. using IPv4 encapsulation will most probably subject
> the router to all autotunnel considerations.

Would a reference to the security section of rfc2893 accomodate your
concern?

Additionally I will add a paragraph on when to discard
IP/GRE-encapsulated packets, something like:

If an IP/GRE-encapsulated packet arrives with SA4 as IPv4 source address
in the outer header and DA6 as destination address in the inner header,
the IPv4-mapped IPv6 address of the BGP next-hop for DA6 in the BGP
table MUST match SA4.  If not, the packet MUST be discarded. 

dirk

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Feb 2002 16:18:38 +0200 (EET)

> Would a reference to the security section of rfc2893 accomodate your

Not really, as autotunnel has been proven very broken from the security 
point of view and RFC2893 discussion is lacking.
 
> table MUST match SA4.  If not, the packet MUST be discarded. 

Did you mean DA6, not SA6 I suppose?

Did I understand correctly that you're forcing "RPF-like" properties here, 
often hazardous in the case of asymmetric routing or e.g. one-way route 
reflectors?

If possible, it's better to match that SA4 matches SA6 and DA4 matches 
DA6.. but if multihop scenarios have to be supported also this might not 
work?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords