Subject: Questions on draft-ietf-isis-igp-p2p-over-lan-01.txt

From: Jeff Parker <[email-masked]>
Date: Wed, 12 Mar 2003 10:58:23 -0500

> in fact they have passed the WG LC, whatever this means 
>
> Alex

So these are questions I should have asked a long time ago.  

The draft is well written, and solves a real problem. 
	
A) Are there any issues interoperating with 3-way handshake?
I would think this would be very helpful in catching
problems.  But I assume the implementations have tried this.  

B) I'm not sure what the issue is with MAC address gleening.
Is it the problem of getting the MAC address itself?  If so,
did you consider adding a TLV to the hello that include your 
MAC?   

If the problem is populating the APR cache, perhaps
that is a requirement on the implementation.   

C) Although you have ruled this out in the algorithm you describe,
someone is bound to try dynamic configuration, by sending 
both LAN and P2P packets over LAN links and prefering a P2P
response.  You might point out that, say, this is a bad 
idea as it behaves badly when two routers negotiate 
a p2p link, to be joined by a third router.

D) Does a 3rd rogue router operating on a LAN and 
"capturing" the adjacency from one or both of
the 2 'real' routers constitute a new Security 
Threat? 

- jeff parker
- axiowave networks

---

From: Alex Zinin <[email-masked]>
Date: Thu, 13 Mar 2003 19:08:29 -0800

Thanks Jeff!

Naming, et al., could you guys answer Jeff's questions
below? I'm running the draft by the RTG-DIR.

Thanks.
-- 
Alex

---

From: Naiming Shen <[email-masked]>
Date: Fri, 14 Mar 2003 17:05:28 -0800

Hi Jeff & Alex,

thanks for the good questions regarding p2p-over-lan draft.

 ] 
 ] > The draft is well written, and solves a real problem. 
 ]         
 ] > A) Are there any issues interoperating with 3-way handshake?
 ] > I would think this would be very helpful in catching
 ] > problems.  But I assume the implementations have tried this.  

there should not be any interoperability issues with 3-way handshake.
from isis point of view, this is just a "normal" p2p circuit. everything
needs to be done for p2p circuit applies here.

 ] 
 ] > B) I'm not sure what the issue is with MAC address gleening.
 ] > Is it the problem of getting the MAC address itself?  If so,
 ] > did you consider adding a TLV to the hello that include your 
 ] > MAC?   
 ] 
 ] > If the problem is populating the APR cache, perhaps
 ] > that is a requirement on the implementation.   

how to populate the local arp cache is an implementation issue,
so it should not be a requirement. regular arp mechansim works
perfectly when a data packet needs to go to this nexthop, it will
get it through the arp request/reply. even if it's a p2p-over-lan
unnumbered interface, as long as proxy arp is enabled(implementation
can put filter/policy on this proxy arp), it still works perfectly.

now in the case people want to populate the arp entry directly from
isis, that's fine too(lets avoid talking about the layering violation
here). one of the way is to gleen the mac address for the peer. since
this packet is sent with the LAN(ethernet) format, the receiver does
have the ways to "gleen" the source mac from it. how to "gleen" this
into isis, then into arp, it's completely local implementation issue.

 ] 
 ] > C) Although you have ruled this out in the algorithm you describe,
 ] > someone is bound to try dynamic configuration, by sending 
 ] > both LAN and P2P packets over LAN links and prefering a P2P
 ] > response.  You might point out that, say, this is a bad 
 ] > idea as it behaves badly when two routers negotiate 
 ] > a p2p link, to be joined by a third router.

i think this again is an implementation issue. a node is welcome
to try what you suggested: determine the p2p/lan status base on
experiment, but they have to accept the fact that it may  not be
deterministic each time a circuit is up/down. i would think, also
so far all the vendor's implementations, people want this to be
a static/configured parameter.

 ] 
 ] > D) Does a 3rd rogue router operating on a LAN and 
 ] > "capturing" the adjacency from one or both of
 ] > the 2 'real' routers constitute a new Security 
 ] > Threat? 

well, even it's a true LAN case, an additional rogue router
can send out the duplicated src mac addresses, or proxy arp
for all the packets over the LAN. this probably is not
special to p2p-over-lan here.

thanks.

 ] 
 ] > - jeff parker
 ] > - axiowave networks
 ] 

- Naiming

---

From: Russ White <[email-masked]>
Date: Sat, 15 Mar 2003 07:45:05 -0500 (Eastern Standard Time)

> A) Are there any issues interoperating with 3-way handshake? I would
> think this would be very helpful in catching problems.  But I assume the
> implementations have tried this.

There aren't any that I've seen in the work we've done with it.

> B) I'm not sure what the issue is with MAC address gleening. Is it the
> problem of getting the MAC address itself?  If so, did you consider
> adding a TLV to the hello that include your MAC?

Yes--and we did consider that. On the other hand, we decided there are so
many other good ways of getting this information, there didn't seem to be
any point in adding such a tlv.

> someone is bound to try dynamic configuration, by sending both LAN and
> P2P packets over LAN links and prefering a P2P response.  You might point
> out that, say, this is a bad idea as it behaves badly when two routers
> negotiate a p2p link, to be joined by a third router.

That could be added, I think.

> D) Does a 3rd rogue router operating on a LAN and "capturing" the
> adjacency from one or both of the 2 'real' routers constitute a new
> Security Threat?

I don't think so, any more than on a "normal" network.

:-)

Russ

--
[email-masked] CCIE <>< Grace Alone